DNS löst nicht mehr auf, wenn der VPN-Kill-Switch Port 53 blockiert
Ein Kill-Switch kann DNS absichtlich blockieren. Vergleichen Sie die Auflösung nur im Tunnel mit einer Ausnahme für einen lokalen Resolver und klären Sie dann, welche Schicht tatsächlich versagt hat.
Wenn der Kill-Switch den Tunnel kappt, nimmt er den DNS-Pfad mit, und der zurückbleibende Resolver ist selten der, den man erwartet. Zwei Entwürfe gehen mit diesem Moment sehr unterschiedlich um: jedes DNS-Paket blockieren, das nicht im Tunnel liegt, odereinen Resolver als Ausnahme stehen lassen. Beides ist vertretbar. Aus einem Browser-Tab sehen die Symptome fast identisch aus, deshalb besteht die erste Aufgabe darin, herauszufinden, welchen Entwurf Sie tatsächlich ausgerollt haben.
Ich halte diesen Unterschied präsent, weil die Korrektur in jedem Fall entgegengesetzt ist. Der eine Entwurf braucht eine breitere Ausnahme, der andere eine engere. Raten kostet Sie entweder Privatsphäre oder einen Nachmittag.
Zwei DNS-Entwürfe für denselben Ausfall
Entwurf A behandelt den Resolver als einen Dienst wie jeden anderen hinter dem Tunnel. Firewall-Regeln erlauben UDP und TCP 53 nur auf der Tunnel-Schnittstelle, und die Adresse, die der Client erhält, ist ein Resolver innerhalb des Tunnels. Fällt der Tunnel aus, hören die Abfragen auf, und das ist das beabsichtigte Ergebnis, kein Fehler.
Entwurf B hält einen Resolver im lokalen Netz erreichbar, meist den Router auf 192.168.1.1 oder den System-Stub auf 127.0.0.53, mit der Begründung, Namensauflösung dürfe nicht mit dem Tunnel sterben. In einem Heim-LAN, in dem der Router für das ganze Haus auflöst, ist das bequem. Im WLAN eines Hotels oder Flughafens zeigt dieselbe Ausnahme auf einen fremden Server, und jeder Name, den Sie eintippen, wird offengelegt, obwohl Ihr Webverkehr blockiert bleibt.
Die Grenze ist, wem der Resolver gehört. Vertrauen Sie dem lokalen, ist eine Ausnahme ein kleines, ehrliches Loch. Tun Sie es nicht, ist der reine Tunnel-Entwurf der einzige, der hält, und der Preis ist, dass ein ausgefallener Tunnel alle Namen mitnimmt.
Warum die eigene Auflösung des VPN-Clients weiter funktioniert
Der Client muss den Hostnamen des Gateways auflösen, bevor ein Tunnel existiert, deshalb darf eine strenge Sperre den Bootstrap-Pfad des Clients nicht erfassen. Die meisten Clients cachen entweder die Endpunktadresse oder liefern eine dokumentierte Bootstrap-Ausnahme für genau diesen Host. Blockiert Ihr Regelwerk diese Abfrage, kommt der Tunnel nie zurück, und die Logs zeigen einen Client, der seinen eigenen Server nicht erreicht, was ein Politikfehler und kein DNS-Fehler ist.
Split-DNS ist der andere Ort, an dem das auftaucht. Der Client schiebt eine interne Zone zu einem privaten Resolver und lässt alles andere beim System-Resolver. Nach einem Ausfall lösen öffentliche Namen womöglich noch auf, während interne in einen Timeout laufen, weil die private Zone keine Route mehr hat. Für den Nutzer ist das "das VPN hat das Internet kaputtgemacht"; für das Resolver-Log ist es eine Abfrage, die nie ankam.
Unter systemd-resolved lässt sich die Aufteilung direkt sehen.resolvectl statuslistet die DNS-Server pro Link und die Routing-Domains auf, und nach dem Ausfall des Tunnels zeigt die interne Domain weiter auf einen Server auf einem Link, den es nicht mehr gibt. Der Stub auf 127.0.0.53 nimmt die Abfrage noch an und wartet dann auf ein Upstream, das nicht antworten wird, weshalb der Fehler Sekunden dauert, statt sofort zurückzukehren.
Verschlüsseltes DNS umgeht keinen Paketfilter
DNS over HTTPS und DNS over TLS laufen über 443 und 853, eine Regel, die Port 53 blockiert, hat dazu also nichts gesagt. "DNS" nach Port zu blockieren ist eine Politik über einen Port, nicht über Namensauflösung. Blockiert Ihr Kill-Switch den gesamten Verkehr außerhalb des Tunnels, ist DoH zufällig mit abgedeckt. Haben Sie eine Ausnahme für ein Captive Portal oder einen öffentlichen Resolver eingeräumt, dann nicht.
Client-seitige Steuerungen sind der billigere Hebel. Firefox gibt seinen DoH-Resolver auf, wenn der Kanarienvogel-Nameuse-application-dns.netnicht auflöst, weshalb verwaltete Netze diese Domain als NXDOMAIN veröffentlichen; Unternehmensrichtlinien können ihn zusätzlich fest abschalten. Android Private DNS und Chromes sicheres DNS haben eigene Schalter und eigene Vorgaben. Sie abzuschalten ist verlässlicher, als Resolver-Adressen nachzujagen, denn die Adressliste ändert sich und Ihr Regelwerk nicht.
Es gibt eine Variante davon, bei der es überhaupt nicht um Lecks geht. Eine Anwendung mit festgelegtem Resolver braucht trotzdem einen Netzwerkpfad dorthin. Verschlüsselung ändert, wer die Abfrage lesen kann, nicht ob das Paket den Rechner verlassen darf, deshalb besiegt eine Sperre für das ganze Gerät die Einstellung, ohne sie anzufassen.
Ordnen Sie das Symptom der Schicht zu
Die meisten Meldungen erreichen Sie als ein Satz, und dieser Satz nennt meist schon die Schicht. Die Tabelle unten ist das, was ich durchgehe, bevor ich eine Regel anfasse; der Punkt ist zu entscheiden, ob die Abfrage blockiert, fehlgeleitet oder nie gesendet wurde.
| Symptom | Likely layer | First check |
|---|---|---|
| Every name fails at once, instantly | Resolver answering with a refusal | Query the resolver by address, not by name |
| Lookups hang for seconds, then time out | Packets dropped with no response | Watch port 53 on the physical link |
| Public names resolve, internal ones do not | Split-DNS routing domain | Per-link DNS servers on the tunnel |
| Names resolve, the page still fails | Not DNS: routing or MTU | Connect to the IP directly |
| Only one application fails | Pinned resolver or cached answer | Check that app's DNS setting |
Die ersten beiden Zeilen sind die, die Leute falsch diagnostizieren. Ein stiller Drop und eine Ablehnung sehen im Browser beide nach "DNS ist kaputt" aus, aber nur eines davon bedeutet, dass Ihr Kill-Switch seine Arbeit tut. Eine Ablehnung heißt, dass etwas geantwortet hat, die Sperre liegt also nicht dort, wo Sie denken.
Stellen Sie die Resolver-Richtlinie wieder her und beweisen Sie sie
Beheben Sie den Entwurf, nicht das Symptom. Für Auflösung nur im Tunnel erlauben Sie 53 auf der Tunnel-Schnittstelle, schieben den internen Resolver mit der Tunnelkonfiguration mit und lassen den physischen Link ohne jede DNS-Freigabe. Bei wg-quick ist es die ZeileDNS =, die den Resolver in die Schnittstellenkonfiguration schreibt, ein Tunnel, der sie weglässt, lässt also den alten Resolver stehen und jede Abfrage auf dem falschen Pfad.wg-quick-Handbuchdokumentiert dieses Verhalten je Plattform.
Prüfen Sie dann in dieser Reihenfolge. Unter Linux zeigtresolvectl statusden aktiven Link,dig +short example.comtestet einen öffentlichen Namen,dig @10.8.0.1 internal.example.comtestet den privaten, undsudo tcpdump -ni any port 53zeigt, welche Schnittstelle die Pakete nutzen, während Sie beides ausführen. Unter Windows liefernGet-DnsClientServerAddress -AddressFamily IPv4undResolve-DnsName example.comdieselben zwei Fakten: wer konfiguriert ist und wer antwortet.
Schließen Sie mit dem Negativtest ab. Trennen Sie den Tunnel, bestätigen Sie, dass ein frischer öffentlicher Name scheitert, bestätigen Sie, dass der private Name scheitert, undbestätigen Sie, dass kein Port-53-Paket den physischen Adapter verlassen hat. Eine Sperre, die nur für gecachte Antworten hält, hält überhaupt nicht.
Checkliste, bevor Sie das Ticket schließen:
- Der während des Ausfalls genutzte Resolver ist der, den die Richtlinie vorsieht.
- Die eigene Endpunkt-Auflösung des Clients ist weiter erlaubt, per Cache oder per Ausnahme.
- DoH und DoT sind entweder von der Sperre erfasst oder per Richtlinie deaktiviert.
- Private Zonen scheitern geschlossen, nicht offen, sobald der Tunnel weg ist.