WireGuard-DNS: Drei Fehler und die passende Lösung

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

DNS über WireGuard fällt auf drei Arten aus. Für jede gibt es eine eigene Lösung. Entweder wird überhaupt nichts aufgelöst, oder Namen werden aufgelöst, aber die Abfragen verlassen Ihr Gerät 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 abfragen soll, sowie das Routing, das festlegt, wie 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 Client-Block [Interface] ist keine WireGuard-Einstellung. Sie wird von wg-quick gelesen, dem Shell-Wrapper, der die Schnittstelle aktiviert. wg-quick ändert dann die Resolver-Konfiguration des Clients, solange der Tunnel aktiv ist, und stellt sie bei wg-quick down wieder her. Daher ist jedes nachfolgende Problem entweder ein Routing-Problem oder ein wg-quick-Problem, niemals ein Kryptografieproblem. Wenn der Tunnel noch nicht eingerichtet ist, beginnen Sie mit einem selbst gehosteten WireGuard-VPN auf Ihrem eigenen VPS und kehren Sie danach zu dieser Seite zurück.

Überprü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 Ping-Anfragen sollten beantwortet werden. Wenn ping 1.1.1.1 eine Zeitüberschreitung meldet, liegt ein Weiterleitungs- oder NAT-Problem (Network Address Translation) und kein DNS-Problem vor. Keine Resolver-Konfiguration kann dieses Problem beheben. 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 aus ab. dig stammt auf 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 Befehl gibt nichts zurück und zeigt ;; communication timed out; no servers could be reached an. Damit ist die Ursache eindeutig: Ihr Client ist auf 10.8.0.1 konfiguriert, 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 Resolver erreicht. Prüfen Sie beides auf dem Server.

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

Ein laufender und korrekt gebundener Resolver zeigt eine Zeile mit 10.8.0.1:53 oder 0.0.0.0:53. Auf Ubuntu ist die Ursache meist 127.0.0.53:53. 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 dieses Timeout.

Die Lösung ist ein Resolver, der auf der Tunneladresse lauscht, sowie eine Firewall-Regel, die den Zugriff der Peers darauf 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

Mit 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 verwenden 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 schlimmer, weil alles zu funktionieren scheint. Namen werden aufgelöst, Seiten werden geladen, und die Abfragen werden im Klartext über das lokale Netzwerk übertragen, dem Sie nicht vertrauen wollten.

Zwei Konfigurationen verursachen ihn. Die erste ist ein Client mit AllowedIPs = 0.0.0.0/0, ::/0 und ohne DNS =-Zeile. wg-quick installiert die Standardroute in der eigenen Routingtabelle und fügt mit suppress_prefixlength 0 eine Regel hinzu. Dadurch bleiben absichtlich spezifischere lokale Routen aktiv, sodass der Rechner weiterhin seinen Drucker erreichen kann. Der Resolver, den der Client per DHCP gelernt hat, normalerweise der Router unter 192.168.1.1, entspricht einer dieser lokalen Routen. Ihr Datenverkehr läuft durch den Tunnel. Das lokale Netzwerk empfängt weiterhin die vollständige Liste der Namen, die Sie abfragen.

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 innerhalb von AllowedIPs liegt, hat der Client keine Route dorthin durch den Tunnel. Die Abfrage verlässt das System daher 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. So 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 wg0-Block keinen Eintrag enthält, liegt dort das Leak vor. Wenn dig +short whoami.akamai.net Ihre private Breitbandadresse statt der Adresse Ihres Servers zurückgibt, bestätigt das den Leak auch auf der Gegenseite. Die tcpdump-Zeile liefert den eindeutigen Beleg: Bei einer funktionierenden Konfiguration läuft jedes Paket zu Port 53 über wg0. Bei einem Leak läuft es über wlan0 oder enp3s0.

Die Behebung besteht aus zwei Teilen. Beide sind erforderlich. Setzen Sie DNS auf eine Adresse innerhalb des Tunnels. Stellen Sie außerdem sicher, dass diese Adresse innerhalb von AllowedIPs liegt.

[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 bei einem Split-Tunnel unbedingt einen öffentlichen Resolver verwenden möchten, fügen Sie dafür eine Hostroute hinzu: AllowedIPs = 10.8.0.0/24, 9.9.9.9/32. Die Pakete werden dann durch den Tunnel geleitet. Das lokale Netzwerk kann jedoch weiterhin anhand früherer Sitzungen erkennen, dass Sie diesen Anbieter ausgewählt haben. Ein eigener Resolver vermeidet dieses Problem.

Die Zuweisung des Resolvers ist einer der sichtbaren Unterschiede zwischen manuell erstelltem WireGuard und einem koordinierten Mesh. Sie ist Teil des Kompromisses in WireGuard im Vergleich zu Tailscale. Wenn Sie einen selbst gehosteten Headscale-Steuerserver betreiben, erhalten Sie diese Koordination, ohne Ihr Schlüsselmaterial einem Drittanbieter zu überlassen.

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 nur wenige Probleme. Unter Linux wird die Einstellung durch ein Shell-Skript angewendet. Dieses muss erkennen, welchen von mehreren Resolver-Managern Sie verwenden.

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

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. Aktivieren Sie die Schnittstelle danach 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 oft einen ganzen Abend. Die Schnittstelle wird aktiviert, resolvectl status wg0 zeigt korrekt DNS Servers: 10.8.0.1 an, aber Abfragen gehen weiterhin an den alten Resolver. systemd-resolved verwaltet für jeden Link eine separate Resolver-Liste und wählt für jede Abfrage einen Link aus. Solange kein Link als Standardroute für Namen markiert ist, verwendet systemd-resolved weiterhin den Resolver des WLAN-Links. Dieser Link führt eine Suchdomäne, Ihre Schnittstelle jedoch 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 davon bereinigt ihn anschließend. Das Argument ~. ist der entscheidende Teil. Es markiert wg0 als Routingdomäne für jeden Namen. Dadurch sendet systemd-resolved alle Abfragen dorthin, statt für jede Abfrage einen Link auszuwählen. Überprüfen Sie die Einstellung.

resolvectl status wg0

Eine funktionierende Ausgabe enthält DNS Servers: 10.8.0.1 und Default Route: yes. Wenn Default Route den Wert no ausgibt, wurde der Teil resolvectl domain nicht ausgeführt. Dann verwendet das System wieder die Link-Auswahl.

Ein weiterer Fall ist erwähnenswert. Wenn /etc/resolv.conf eine echte Datei und kein symbolischer Link auf /run/systemd/resolve/stub-resolv.conf ist, wird die Datei von einem anderen Dienst 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 Abfragen zuverlässig durch den Tunnel übertragen werden, wird der Resolver am anderen Ende zu einem Kontrollpunkt. Wenn Sie dort AdGuard Home betreiben, erhalten alle verbundenen Geräte eine Filterung anhand von Blocklisten und ein Abfrageprotokoll. Dafür ist keine Clientsoftware und keine Konfiguration auf den einzelnen Geräten erforderlich. 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, statt diesen Port öffentlich zu öffnen. Legen Sie im Assistenten sowohl die DNS-Listening-Adresse als auch die Listening-Adresse der Administration auf 10.8.0.1 fest. Wenn unbound aus dem ersten Fehler weiterhin dieselbe Adresse verwendet, beenden Sie den Prozess zuerst mit sudo systemctl disable --now unbound. Zwei Prozesse können nicht gleichzeitig UDP-Port 53 an dieselbe Adresse binden. Der zweite Prozess wird mit listen udp 10.8.0.1:53: bind: address already in use beendet.

An den Clientkonfigurationen ist keine Änderung erforderlich, wenn sie bereits DNS = 10.8.0.1 enthalten. Im Abfrageprotokoll wird nun jede Abfrage von jedem Peer angezeigt. Das ist eine echte Datenschutzentscheidung und kein kostenloser Vorteil: Sie verlagern das Vertrauen von Ihrem Internetanbieter auf sich selbst. Sie müssen dafür sorgen, dass dieses System aktuell bleibt. Ein Server, der aus dem Internet erreichbar ist, benötigt zuerst die grundlegenden Sicherheitsmaßnahmen. Die ersten zehn Minuten auf einem neuen VPS behandelt diese Maßnahmen.

FAQ

Warum stellt mein WireGuard-Tunnel eine Verbindung her, aber Namen werden nicht aufgelöst?

Der Tunnel überträgt Pakete und verarbeitet Namen überhaupt nicht. Ein funktionierender Tunnel mit fehlerhaften Abfragen bedeutet daher, dass der von Ihnen 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 auf Verbindungen wartet, häufig weil der Stub von systemd-resolved nur an 127.0.0.53 gebunden ist, oder dass die Server-Firewall eingehenden UDP-Port 53 auf wg0 verwirft. Beheben Sie zuerst den Listener. Öffnen Sie den Port anschließend nur für wg0.

Wie prüfe ich, ob DNS-Abfragen über WireGuard nach außen gelangen?

Führen Sie auf dem Client sudo tcpdump -ni any -c 10 port 53 aus und beobachten Sie beim Aufrufen von Webseiten die Schnittstellenspalte. Jedes Paket sollte über wg0 übertragen werden. Wenn die Pakete auf Ihrer WLAN- oder Ethernet-Schnittstelle erscheinen, werden die Abfragen im Klartext übertragen. dig +short whoami.akamai.net liefert eine zusätzliche Prüfung. Der Befehl antwortet mit der öffentlichen Adresse des rekursiven Resolvers, der die Abfrage gestellt 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. Die Resolveradresse muss außerdem innerhalb von AllowedIPs liegen, sonst hat der Client keine Route zu ihr. 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. Die Abfrage verlässt das System daher über die lokale Verbindung, obwohl die Zeile DNS korrekt aussieht.

Warum zeigt resolvectl den richtigen Server an, aber Abfragen werden trotzdem an anderer Stelle ausgeführt?

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

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

Reparieren Sie zuerst einen Linux-Client. Nur diese Plattform zeigt Ihnen den Mechanismus. resolvectl status und tcpdump zeigen, welcher Resolver geantwortet hat und welche Schnittstelle das Paket übertragen hat. Telefon- und Desktop-Apps verwenden dieselben Werte für DNS und AllowedIPs, zeigen die zugrunde liegende Konfiguration jedoch nicht an. Sobald der Linux-Client korrekt funktioniert, übernehmen Sie eine Konfiguration, die Sie bereits überprüft haben.