DNS über WireGuard funktioniert nicht: Drei Lösungen

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

DNS über WireGuard fällt auf drei Arten aus. Für jede gibt es eine eigene Lösung. Entweder wird überhaupt kein Name aufgelöst, oder Namen werden aufgelöst, aber die Abfragen verlassen Ihren 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 festlegt, 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 startet, und wg-quick bearbeitet dann 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 selbst 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 zuerst, 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 anzeigen, und beide Pings sollten beantwortet werden. Wenn ping 1.1.1.1 eine Zeitüberschreitung meldet, liegt wahrscheinlich ein Weiterleitungs- oder NAT-Problem (Network Address Translation) und kein DNS-Problem vor. Keine Resolver-Konfiguration kann dann helfen. Eine Firewall, die ICMP verwirft, verursacht dieselbe Zeitüberschreitung. Prüfen Sie dies daher mit curl -sI https://1.1.1.1, bevor Sie Weiterleitungsregeln ändern. Wenn die Pings beantwortet werden, aber der Durchsatz 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 Tunneladresse 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 zunächst alles zu funktionieren scheint. Namen werden aufgelöst, Seiten laden, 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 seiner eigenen Routing-Tabelle und fügt mit suppress_prefixlength 0 eine Regel hinzu. Dadurch bleiben absichtlich spezifischere lokale Routen erhalten, damit der Rechner beispielsweise weiterhin seinen Drucker erreichen kann. Der Resolver, den der Client über DHCP gelernt hat, typischerweise der Router unter 192.168.1.1, 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 innerhalb von AllowedIPs liegt, hat der Client keine Route dorthin durch den Tunnel. Die Abfrage verlässt den Rechner daher wie im ersten Fall über die lokale Verbindung.

Ermitteln Sie, welcher Resolver tatsächlich antwortet. whoami.akamai.net ist ein öffentlicher Testname. Er antwortet mit der IP-Adresse des rekursiven Resolvers, der die Abfrage gestellt hat. Dadurch können Sie seine 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 pro Verbindung einen Block 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 solchen Eintrag enthält, liegt dort das Leck vor. Wenn dig +short whoami.akamai.net Ihre private Breitbandadresse statt der Adresse Ihres Servers zurückgibt, bestätigt dies das Ergebnis von der Gegenstelle aus. Die tcpdump-Zeile liefert den eindeutigen Beleg: Bei einer funktionierenden Konfiguration wird jedes Port-53-Paket, das den Rechner verlässt, über wg0 übertragen. Bei einem Leck läuft es über wlan0 oder enp3s0. Pakete auf lo zu oder von 127.0.0.53 sind Anfragen von Anwendungen an den lokalen systemd-resolved-Stub. Sie stellen kein Leck dar.

Die Behebung besteht aus zwei Teilen. Beide sind erforderlich. Setzen Sie DNS auf eine Adresse innerhalb des Tunnels und stellen Sie 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 ihn als Hostroute hinzu: AllowedIPs = 10.8.0.0/24, 9.9.9.9/32. Die Pakete werden dann durch den Tunnel übertragen. Das lokale Netzwerk kann jedoch anhand früherer Sitzungen weiterhin 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 eingerichteten WireGuard-Konfigurationen und einem koordinierten Mesh. Sie gehört zu den Abwägungen in WireGuard im Vergleich zu Tailscale. Wenn Sie einen selbst gehosteten Headscale-Kontrollserver betreiben, erhalten Sie diese Koordination, ohne Ihr Schlüsselmaterial einem Drittanbieter zu überlassen. Falls Sie genau dieser letzte Punkt beunruhigt, beachten Sie: Tailscale besitzt niemals die Schlüssel, die Ihren Datenverkehr verschlüsseln. Die wichtigere Frage ist, was ein kompromittierter Koordinationsserver oder ein gestohlenes Identitätskonto Ihrem Netzwerk hinzufügen 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 nur selten Probleme. Unter Linux wird die Einstellung durch ein Shell-Skript angewendet, das erkennen muss, welchen von mehreren Resolver-Managern Sie verwenden.

Der erste Fehler ist sofort sichtbar. 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. Unter Debian 12 und Ubuntu 24.04 oder höher ist der resolvconf-Befehl für die Kommunikation mit systemd-resolved im Paket systemd-resolved enthalten. Installieren Sie dieses Paket und aktivieren Sie die Schnittstelle anschließend erneut. Ubuntu 22.04 enthält dafür kein separates Paket. Erstellen Sie dort den Kompatibilitäts-Link mit sudo ln -s /usr/bin/resolvectl /usr/local/bin/resolvconf selbst und lassen Sie die Installationszeile weg.

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

Der zweite Fehler bleibt unbemerkt und kostet häufig einen ganzen Abend. Die Schnittstelle wird aktiviert, resolvectl status wg0 zeigt korrekt DNS Servers: 10.8.0.1 an, und DNS-Abfragen erreichen trotzdem weiterhin den alten Resolver. systemd-resolved ignoriert wg0 nicht. Ein Name, der zu keiner Routing-Domain passt, wird an die DNS-Server jedes Links gesendet, der als Standardroute gilt. Ein Link mit DNS-Servern und ohne Route-only-Domain gilt standardmäßig als Standardroute. Die Abfrage geht daher gleichzeitig an 10.8.0.1 und an den Router der WLAN-Schnittstelle. Die erste erfolgreiche Antwort wird verwendet. Der Router ist nur einen Hop entfernt und antwortet normalerweise zuerst. In beiden Fällen hat die Abfrage das System bereits im Klartext verlassen. Namen unter der eigenen Such-Domain der WLAN-Schnittstelle, beispielsweise lan, werden nur an diesen Link gesendet, weil die spezifischste Routing-Domain Vorrang hat.

Wenn wg-quick DNS = über den systemeigenen resolvconf-Wrapper anwendet, fordert es bereits eine Catch-all-Routing-Domain an. Dieser Fehler tritt daher hauptsächlich auf, wenn eine andere resolvconf-Implementierung oder ein Network Manager die Einstellung angewendet hat. Durch eine explizite Konfiguration entfällt diese Unsicherheit.

Setzen Sie den Resolver und beanspruchen Sie die Catch-all-Routing-Domain im selben Schritt. %i wird zum Namen der Schnittstelle erweitert. Dieser Block funktioniert daher unverändert auf 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 dabei die entscheidende Hälfte: Es macht wg0 zur Route-only-Domain für jeden Namen. Dadurch sendet systemd-resolved Namen, auf die keine spezifischere Domain passt, nicht mehr an die anderen Links. Namen unter der eigenen Domain eines anderen Links, beispielsweise lan, werden weiterhin an diesen Link gesendet. Für lokale Hosts ist das normalerweise erwünscht. Überprüfen Sie die Konfiguration.

resolvectl status wg0

Eine funktionierende Ausgabe enthält DNS Servers: 10.8.0.1 und DNS Domain: ~.. Fehlt ~., wurde der Teil resolvectl domain nicht ausgeführt. wg0 konkurriert dann wieder mit den anderen Links. Verwenden Sie für die Prüfung nicht das Flag für die Standardroute: Es zeigt auch ohne ~. yes an, beziehungsweise +DefaultRoute in der Protocols-Zeile, abhängig von der systemd-Version. Ein Link ohne Route-only-Domain gilt ohnehin als Standardroute.

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 sie von einer anderen Komponente verwaltet, normalerweise 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 Kontrollinstanz. Wenn Sie dort AdGuard Home betreiben, erhält jedes verbundene Gerät eine Filterung anhand von Blocklisten und ein Abfrageprotokoll. Dafür sind keine Clientsoftware und keine Konfiguration pro Gerät erforderlich. Das offizielle Installationsskript, geprüft im October 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. Setzen Sie im Assistenten sowohl die DNS- als auch die Admin-Listening-Adresse auf 10.8.0.1. Wenn unbound aus dem ersten Fehler weiterhin dieselbe Adresse verwendet, beenden Sie ihn zuerst mit sudo systemctl disable --now unbound, weil beide auf einer Adresse um UDP-Port 53 konkurrieren würden und AdGuard Home mit listen udp 10.8.0.1:53: bind: address already in use beendet wird.

An den Clientkonfigurationen sind keine Änderungen erforderlich, wenn sie bereits DNS = 10.8.0.1 enthalten. Im Abfrageprotokoll wird nun jede Abfrage angezeigt, die von jedem Peer dort eintrifft, sofern Sie keinen Client von der Protokollierung ausnehmen. Das ist eine echte Datenschutzentscheidung und kein kostenloser Vorteil: Sie verlagern das Vertrauen von Ihrem Internetanbieter auf sich selbst, und Sie müssen dafür sorgen, dass dieser Rechner mit Sicherheitsupdates versorgt wird. Ein Server, der dem Internet ausgesetzt ist, benötigt zunächst die grundlegenden Schutzmaßnahmen. Die ersten zehn Minuten auf einem neuen VPS behandelt diese Maßnahmen.

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 konfigurierte 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, oder dass die Stub-Implementierung von systemd-resolved nur an 127.0.0.53 gebunden ist. Möglich ist auch, dass die Server-Firewall eingehende UDP-Pakete auf Port 53 über wg0 verwirft. Beheben Sie zuerst den Listener und öffnen Sie den Port anschließend nur für wg0.

Wie prüfe ich, ob DNS-Anfragen über WireGuard durchsickern?

Führen Sie auf dem Client sudo tcpdump -ni any -c 10 port 53 aus und beobachten Sie beim Aufrufen von Webseiten die Spalte für das Interface. Jedes Paket, das den Rechner verlässt, sollte über wg0 übertragen werden. Pakete über lo zu oder von 127.0.0.53 gehören zum lokalen systemd-resolved-Stub und sind unproblematisch. Wenn sie über Ihr WLAN- oder Ethernet-Interface erscheinen, werden die Anfragen unverschlüsselt übertragen. dig +short whoami.akamai.net liefert eine zusätzliche Prüfung. Der Befehl antwortet mit der öffentlichen Adresse des rekursiven Resolvers, der die Anfrage verarbeitet hat. Eine Antwort, die nicht der Adresse Ihres Servers entspricht, bestätigt daher das Leck.

Benötige ich die Zeile DNS = bei einem Split-Tunnel?

Ja. Die Resolver-Adresse 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 Anfrage wird verschlüsselt übertragen. Ein öffentlicher Resolver wie 9.9.9.9 ist nicht abgedeckt. Die Anfrage verlässt den Rechner daher über die lokale Verbindung, auch wenn die Zeile DNS korrekt aussieht.

Warum zeigt resolvectl den richtigen Server an, obwohl die Namensauflösung weiterhin woanders erfolgt?

systemd-resolved sendet einen Namen, der zu keiner Routing-Domain passt, gleichzeitig an alle Links mit einer Standardroute, einschließlich wg0. Anschließend wird die erste erfolgreiche Antwort zurückgegeben. Diese stammt normalerweise vom lokalen Router. 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 DNS Domain: ~. melden. Jeder Name, den kein anderer Link mit einer spezifischeren Domain beansprucht, wird dann ausschließlich an wg0 gesendet.

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

Reparieren Sie zuerst einen Linux-Client, weil nur diese Plattform den Mechanismus sichtbar macht. resolvectl status und tcpdump zeigen, welcher Resolver geantwortet hat und welches Interface das Paket übertragen hat. Telefon- und Desktop-Anwendungen verwenden dieselben Werte für DNS und AllowedIPs, ohne die zugrunde liegenden Abläufe anzuzeigen. Sobald der Linux-Client korrekt funktioniert, übernehmen Sie daher eine Konfiguration, die Sie bereits überprüft haben.