DNS über WireGuard reparieren: 3 typische Fehler

Warum DNS sofort ausfällt, sobald der WireGuard-Tunnel aktiv wird

DNS über WireGuard fällt aus drei verschiedenen Gründen aus. Für jeden Grund gibt es eine eigene Lösung. Entweder werden überhaupt keine Namen aufgelöst, oder die Namen werden zwar aufgelöst, aber die Abfragen verlassen den Rechner außerhalb des Tunnels, oder der eigene Resolver-Manager des Clients überschreibt die Einstellung wenige Sekunden nach dem Start der Schnittstelle. Der Tunnel ist fast nie das Problem. Das Problem ist die eine Zeile, die dem Client mitteilt, welchen Resolver er fragen soll, sowie das Routing, das bestimmt, wie die Pakete zu diesem Resolver übertragen werden.

WireGuard überträgt IP-Pakete und kennt DNS nicht (Domain Name System, der Dienst, der Namen wie example.com in IP-Adressen umwandelt). Die Zeile DNS = in einem [Interface]-Block des Clients ist keine WireGuard-Einstellung. Sie wird von wg-quick gelesen, dem Shell-Wrapper, der die Schnittstelle aktiviert. wg-quick ändert anschließend die Resolver-Konfiguration des Clients, solange der Tunnel aktiv ist, und stellt sie bei wg-quick down wieder her. Daher ist jedes der folgenden Probleme entweder ein Routing-Problem oder ein wg-quick-Problem, niemals ein Problem der Kryptografie. Wenn der Tunnel noch nicht eingerichtet ist, beginnen Sie mit einem selbst gehosteten WireGuard-VPN auf Ihrem eigenen VPS und kehren Sie anschließend zu dieser Seite zurück.

Prüfen Sie zunächst, ob der Tunnel funktioniert, bevor Sie DNS überhaupt ändern.

sudo wg show
ping -c 3 10.8.0.1
ping -c 3 1.1.1.1

wg show sollte den Peer mit einem aktuellen latest handshake auflisten, und beide Pings sollten beantwortet werden. Wenn ping 1.1.1.1 eine Zeitüberschreitung meldet, liegt ein Forwarding- oder NAT-Problem (Network Address Translation) vor, kein DNS-Problem. Keine Resolver-Konfiguration kann das beheben. Wenn die Pings beantwortet werden, der Durchsatz aber einbricht, sobald echter Datenverkehr beginnt, handelt es sich um ein separates Problem. Langsames WireGuard ist fast immer auf die MTU zurückzuführen, nicht auf etwas, das auf dieser Seite beschrieben wird. In allen Beispielen wird 10.8.0.0/24 als Tunnel-Subnetz und 10.8.0.1 als Tunnel-Adresse des Servers verwendet. Ersetzen Sie diese Werte durch Ihre eigenen.

Fehler 1: Keine Namensauflösung, weil der Resolver nicht antwortet

Das Symptom ist eindeutig. ping 1.1.1.1 funktioniert, und curl https://example.com gibt Folgendes zurück:

curl: (6) Could not resolve host: example.com

Fragen Sie den Tunnel-Resolver direkt vom Client ab. dig stammt unter Ubuntu und Debian aus dem Paket dnsutils.

dig +short @1.1.1.1 example.com
dig +short @10.8.0.1 example.com

Der erste Befehl gibt eine Adresse zurück. Das beweist, dass Pakete über den Tunnel das Internet erreichen. Der zweite gibt nichts zurück und zeigt ;; communication timed out; no servers could be reached an. Damit ist die Diagnose vollständig: Ihr Client ist auf 10.8.0.1 eingestellt, und 10.8.0.1 antwortet nicht auf UDP-Port 53.

Dafür gibt es zwei Ursachen. Entweder läuft auf dem Server kein Resolver, oder die Server-Firewall verwirft die Anfrage, bevor sie den Server erreicht. Prüfen Sie beides auf dem Server.

sudo ss -ulnp | grep ':53'
sudo nft list ruleset

Ein korrekt laufender und gebundener Resolver zeigt eine Zeile mit 10.8.0.1:53 oder 0.0.0.0:53. Unter Ubuntu ist meistens 127.0.0.53:53 die Ursache für die Überraschung: Dabei handelt es sich um den Stub-Listener von systemd-resolved. Er bindet eine Loopback-Adresse und ist absichtlich von anderen Rechnern aus nicht erreichbar. Wenn ein VPN-Client auf einen Server zeigt, dessen einziger Resolver dieser Stub ist, entsteht genau dieser Timeout.

Die Lösung ist ein Resolver, der auf der Tunneladresse lauscht, sowie eine Firewall-Regel, die den Zugriff der Peers erlaubt.

sudo apt update && sudo apt install -y unbound
printf 'server:\n  interface: 10.8.0.1\n  access-control: 10.8.0.0/24 allow\n' \
  | sudo tee /etc/unbound/unbound.conf.d/wireguard.conf
sudo systemctl restart unbound
sudo ss -ulnp | grep '10.8.0.1:53'

Öffnen Sie anschließend den Port ausschließlich für Tunnelverkehr. Fügen Sie bei nftables diese beiden Zeilen zur Kette input in /etc/nftables.conf hinzu und laden Sie die Konfiguration mit sudo systemctl reload nftables neu.

udp dport 53 iifname "wg0" accept
tcp dport 53 iifname "wg0" accept

Bei ufw erledigt sudo ufw allow in on wg0 to any port 53 dieselbe Aufgabe. Öffnen Sie Port 53 niemals für das öffentliche Internet. Einen offenen rekursiven Resolver finden Scanner innerhalb weniger Tage und nutzen ihn zur Verstärkung von Denial-of-Service-Angriffen. Ihr Provider bemerkt diesen Datenverkehr, bevor Sie es tun.

Führen Sie dig +short @10.8.0.1 example.com erneut auf dem Client aus. Eine Adresse in der Ausgabe bedeutet, dass der Resolverpfad funktioniert. Der Client muss ihn jetzt nur noch verwenden. Fügen Sie die Zeile zum [Interface]-Block des Clients hinzu und starten Sie die Schnittstelle mit sudo wg-quick down wg0 && sudo wg-quick up wg0 neu.

[Interface]
PrivateKey = <client private key>
Address = 10.8.0.2/32
DNS = 10.8.0.1

Fehler zwei: DNS-Leaks, weil ein Split-Tunnel den Resolver nicht routet

Dieser Fehler ist schwerwiegender, weil scheinbar alles funktioniert. Namen werden aufgelöst, Seiten werden geladen, und die Abfragen werden unverschlüsselt über das lokale Netzwerk übertragen, dem Sie nicht vertrauen wollten.

Zwei Konfigurationen verursachen den Fehler. Die erste ist ein Client mit AllowedIPs = 0.0.0.0/0, ::/0 und ohne DNS =-Zeile. wg-quick installiert die Standardroute in seiner eigenen Routing-Tabelle und fügt mit suppress_prefixlength 0 eine Regel hinzu. Dadurch bleiben absichtlich spezifischere lokale Routen aktiv, damit der Rechner beispielsweise weiterhin seinen Drucker erreichen kann. Der Resolver, den der Client per DHCP gelernt hat, ist typischerweise der Router unter 192.168.1.1, und entspricht einer dieser lokalen Routen. Ihr Datenverkehr läuft durch den Tunnel. Das lokale Netzwerk erhält weiterhin die vollständige Liste der von Ihnen abgefragten Namen.

Die zweite Konfiguration ist ein Split-Tunnel: AllowedIPs = 10.8.0.0/24 mit DNS = 9.9.9.9. Da 9.9.9.9 nicht in AllowedIPs enthalten ist, hat der Client keine Route durch den Tunnel dorthin. Die Abfrage verlässt den Rechner daher genau wie im ersten Fall über die lokale Verbindung.

Ermitteln Sie, welcher Resolver tatsächlich antwortet. whoami.akamai.net ist ein öffentlicher Testname, der mit der IP-Adresse des rekursiven Resolvers antwortet, der die Abfrage gestellt hat. Dadurch können Sie die Antwort mit der öffentlichen Adresse Ihres Servers vergleichen.

resolvectl status
dig +short whoami.akamai.net
sudo tcpdump -ni any -c 10 port 53

resolvectl status gibt einen Block pro Verbindung aus. Wenn der Block für Ihre Ethernet- oder WLAN-Verbindung weiterhin Current DNS Server: 192.168.1.1 anzeigt, während der Block wg0 keinen Eintrag enthält, liegt ein Leak vor. Wenn dig +short whoami.akamai.net Ihre private Breitbandadresse statt der Adresse Ihres Servers zurückgibt, bestätigt dies den Leak von der Gegenseite. Die tcpdump-Zeile liefert den eindeutigen Nachweis: Bei einer funktionierenden Konfiguration läuft jedes Paket an Port 53 über wg0. Bei einem Leak läuft es über wlan0 oder enp3s0.

Die Lösung besteht aus zwei Teilen. Beide sind erforderlich. Setzen Sie DNS auf eine Adresse innerhalb des Tunnels und stellen Sie sicher, dass diese Adresse in AllowedIPs enthalten ist.

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.com:51820
AllowedIPs = 10.8.0.0/24, 10.20.0.0/16

10.8.0.1 liegt innerhalb von 10.8.0.0/24. Daher wird die Abfrage verschlüsselt an den Server gesendet. Wenn Sie in einem Split-Tunnel unbedingt einen öffentlichen Resolver verwenden müssen, fügen Sie dafür eine Hostroute hinzu: AllowedIPs = 10.8.0.0/24, 9.9.9.9/32. Die Pakete laufen dann durch den Tunnel. Das lokale Netzwerk kann jedoch weiterhin erkennen, dass Sie diesen Anbieter bereits in früheren Sitzungen ausgewählt haben. Ein eigener Resolver vermeidet dieses Problem.

Die Zuweisung des Resolvers ist einer der sichtbaren Unterschiede zwischen manuell eingerichtetem WireGuard und einem koordinierten Mesh. Das ist Teil des Zielkonflikts bei WireGuard im Vergleich zu Tailscale. Mit einem selbst gehosteten Headscale-Steuerungsserver erhalten Sie diese Koordination, ohne Ihr Schlüsselmaterial einem Drittanbieter zu überlassen. Wenn Sie genau dieser letzte Punkt beunruhigt, beachten Sie: Tailscale hält niemals die Schlüssel, die Ihren Datenverkehr verschlüsseln. Die wichtigere Frage lautet daher, welchen zusätzlichen Zugriff ein kompromittierter Koordinationsserver oder ein gestohlenes Identitätskonto auf Ihr Netzwerk ermöglichen könnte.

Fehler drei: resolvconf und systemd-resolved konkurrieren auf Linux-Clients

macOS-, Windows-, iOS- und Android-Clients wenden DNS = über die offizielle App an und verursachen kaum Probleme. Unter Linux wird diese Einstellung von einem Shell-Skript angewendet, das erkennen muss, welchen von mehreren Resolver-Managern Sie verwenden.

Der erste Fehler ist offensichtlich. sudo wg-quick up wg0 bricht mit folgender Meldung ab:

resolvconf: command not found

wg-quick ruft resolvconf auf, aber diese Binärdatei ist nicht installiert. Installieren Sie die Implementierung, die mit systemd-resolved kommuniziert, und aktivieren Sie die Schnittstelle anschließend erneut.

sudo apt install -y openresolv
sudo systemctl restart systemd-resolved
sudo wg-quick down wg0 && sudo wg-quick up wg0
resolvectl status wg0

Der zweite Fehler bleibt unbemerkt. Er kostet jedoch oft einen ganzen Abend. Die Schnittstelle wird aktiviert, resolvectl status wg0 zeigt korrekt DNS Servers: 10.8.0.1 an, und Abfragen werden trotzdem weiterhin an den alten Resolver gesendet. systemd-resolved verwaltet für jedes Netzwerk-Interface eine eigene Resolver-Liste und wählt für jede Abfrage ein Interface aus. Wenn kein Interface als Standardroute für Namen markiert ist, verwendet systemd-resolved weiterhin den Resolver des WLAN-Interfaces, weil dieses eine Suchdomain führt und Ihr Interface nicht.

Setzen Sie den Resolver und beanspruchen Sie die Standardroute im selben Schritt. %i wird zum Namen der Schnittstelle erweitert. Dieser Block funktioniert daher unverändert mit jeder Schnittstelle.

[Interface]
Address = 10.8.0.2/32
PostUp = resolvectl dns %i 10.8.0.1; resolvectl domain %i ~.
PostDown = resolvectl revert %i

Löschen Sie die Zeile DNS =, wenn Sie PostUp auf diese Weise verwenden. Andernfalls schreiben zwei Mechanismen den Resolver-Status, und nur einer bereinigt ihn anschließend. Das Argument ~. ist die entscheidende Hälfte: Es markiert wg0 als Routing-Domain für jeden Namen. Dadurch sendet systemd-resolved alle Abfragen dorthin, statt für jede Abfrage ein Interface auszuwählen. Überprüfen Sie das Ergebnis.

resolvectl status wg0

Eine korrekte Ausgabe enthält DNS Servers: 10.8.0.1 und Default Route: yes. Wenn Default Route no ausgibt, wurde der Teil resolvectl domain nicht ausgeführt. Dann wird wieder anhand des Interfaces ausgewählt.

Ein weiterer Fall ist erwähnenswert. Wenn /etc/resolv.conf eine reguläre Datei und kein Symlink auf /run/systemd/resolve/stub-resolv.conf ist, wird sie von einer anderen Komponente verwaltet, meist von NetworkManager oder einer Container-Laufzeitumgebung. Führen Sie ls -l /etc/resolv.conf aus, bevor Sie etwas anderes untersuchen. Ein Tool, das diese Datei bei jeder Netzwerkänderung neu schreibt, macht Ihre Änderungen sonst im ungünstigsten Moment rückgängig.

Das Upgrade: Ihr eigener filternder Resolver über den Tunnel

Sobald Anfragen zuverlässig durch den Tunnel übertragen werden, wird der Resolver am anderen Ende zu einer zentralen Kontrollinstanz. Wenn Sie dort AdGuard Home betreiben, erhalten alle verbundenen Geräte Blocklistenfilterung und ein Abfrageprotokoll, ohne Client-Software und ohne gerätespezifische Konfiguration. Das offizielle Installationsskript, geprüft im Juli 2026, besteht aus einer Zeile.

curl -s -S -L https://raw.githubusercontent.com/AdguardTeam/AdGuardHome/master/scripts/install.sh | sh -s -- -v

Der Einrichtungsassistent lauscht beim ersten Start auf Port 3000. Rufen Sie ihn über den Tunnel unter http://10.8.0.1:3000 auf, anstatt diesen Port öffentlich zu öffnen, und setzen Sie im Assistenten sowohl die DNS-Listening-Adresse als auch die Admin-Listening-Adresse auf 10.8.0.1. Falls unbound aus dem ersten Fehler weiterhin dieselbe Adresse verwendet, beenden Sie den Prozess zunächst mit sudo systemctl disable --now unbound, weil zwei Prozesse nicht gleichzeitig UDP-Port 53 an dieselbe Adresse binden können und der zweite Prozess mit listen udp 10.8.0.1:53: bind: address already in use beendet wird.

An den Client-Konfigurationen sind keine Änderungen erforderlich, wenn sie bereits DNS = 10.8.0.1 enthalten. Das Abfrageprotokoll zeigt nun jede Namensauflösung von jedem Peer. Das ist eine echte Datenschutzentscheidung und kein kostenloser Vorteil: Sie verlagern das Vertrauen von Ihrem Internetanbieter auf sich selbst und müssen dafür sorgen, dass dieses System stets mit Sicherheitsupdates versorgt wird. Ein Server, der aus dem Internet erreichbar ist, benötigt zunächst eine grundlegende Absicherung. Die ersten zehn Minuten auf einem neuen VPS behandelt diese Schritte.

FAQ

Warum stellt mein WireGuard-Tunnel eine Verbindung her, löst aber keine Namen auf?

Der Tunnel überträgt Pakete und verarbeitet Namen überhaupt nicht. Ein funktionierender Tunnel mit fehlerhaften Namensauflösungen bedeutet daher, dass der angegebene Resolver nicht antwortet. Testen Sie dies auf dem Client mit dig +short @10.8.0.1 example.com. Eine communication timed out-Antwort bedeutet entweder, dass an dieser Tunneladresse kein Resolver lauscht, häufig weil der Stub von systemd-resolved nur an 127.0.0.53 gebunden ist, oder dass die Server-Firewall UDP-Port 53 auf wg0 verwirft. Korrigieren Sie zuerst den Listener. Öffnen Sie den Port anschließend ausschließlich für wg0.

Wie prüfe ich, ob mein DNS über WireGuard durchsickert?

Führen Sie auf dem Client sudo tcpdump -ni any -c 10 port 53 aus und beobachten Sie beim Aufrufen von Websites die Spalte für das Interface. Jedes Paket sollte über wg0 laufen. Wenn die Pakete auf Ihrem WLAN- oder Ethernet-Interface erscheinen, verlassen die Abfragen das System im Klartext. dig +short whoami.akamai.net liefert eine zweite Prüfung, weil der Befehl die öffentliche Adresse des rekursiven Resolvers zurückgibt, der die Abfrage verarbeitet hat. Eine Antwort, die nicht der Adresse Ihres Servers entspricht, bestätigt das Leck.

Benötige ich die Zeile DNS =, wenn ich einen Split-Tunnel verwende?

Ja. Außerdem muss sich die Resolver-Adresse innerhalb von AllowedIPs befinden. Andernfalls hat der Client keine Route zu dieser Adresse. Mit AllowedIPs = 10.8.0.0/24 ist ein Resolver unter 10.8.0.1 abgedeckt und die Abfrage wird verschlüsselt. Ein öffentlicher Resolver wie 9.9.9.9 ist nicht abgedeckt. Daher verlässt die Abfrage das System über die lokale Verbindung, auch wenn die Zeile DNS korrekt aussieht.

Warum zeigt resolvectl den richtigen Server an, obwohl die Abfragen weiterhin an einen anderen Resolver gehen?

systemd-resolved führt für jedes Link eine eigene Resolver-Liste und wählt für jede Abfrage ein Link aus. Daher wird ein korrekter Eintrag unter wg0 ignoriert, wenn ein anderes Link die Standardroute für Namen enthält. Fügen Sie PostUp = resolvectl dns %i 10.8.0.1; resolvectl domain %i ~. zum Block [Interface] des Clients hinzu und entfernen Sie die Zeile DNS =. resolvectl status wg0 sollte anschließend Default Route: yes melden.

Welchen Client sollte ich zuerst korrigieren, wenn mehrere Clients betroffen sind?

Korrigieren Sie zuerst einen Linux-Client, weil nur diese Plattform den Mechanismus sichtbar macht. resolvectl status und tcpdump zeigen, welcher Resolver geantwortet hat und über welches Interface das Paket übertragen wurde. Telefon- und Desktop-Anwendungen verwenden dieselben Werte für DNS und AllowedIPs, zeigen die zugrunde liegende Konfiguration jedoch nicht an. Sobald der Linux-Client korrekt funktioniert, kopieren Sie eine bereits überprüfte Konfiguration.