VPN-DNS versus DoH im Browser: Was ein Leak-Test Ihnen nicht sagen kann
Eine Leak-Test-Adresse zeigt nur, welcher Resolver geantwortet hat. Verschlüsselte Abfragen, Split-DNS und Browser-Richtlinien entscheiden, ob private Namen überhaupt noch aufgelöst werden.
Die Leak-Test-Seite sagt, Ihre DNS sei in Ordnung, das Browser-Symbol sagt sicher, und das interne Wiki lädt trotzdem nicht. Alle drei können gleichzeitig stimmen, denn die Adresse eines Resolvers ist nicht dasselbe wie die Richtlinie, die ihn ausgewählt hat, oder der Weg, den die Abfrage genommen hat. Was Leute als DNS-Leck bezeichnen, ist eigentlich eine Frage: Welcher Resolver hat den Namen erhalten, und war diese Wahl beabsichtigt? Das zu sortieren erfordert drei Prüfungen, und nur die letzte beinhaltet das Ändern einer Einstellung.
Mythos eins: Das Symbol benennt Ihren Resolver
Ein Leak-Test löst einen Sondennamen auf und meldet die Adresse, die geantwortet hat. Er meldet nicht die Richtlinie, die diesen Resolver gewählt hat, und wenn die Abfrage in DNS über HTTPS verpackt ist, kann eine Middlebox auf dem Weg den Namen überhaupt nicht sehen. Zwei sehr unterschiedliche Rechner erzeugen dasselbe beruhigende Symbol: einer, bei dem das VPN 10.8.0.1 geschickt hat und der Browser ihn nutzt, und einer, bei dem der Browser die Systemliste ignorierte und den Namen durch den Tunnel an seinen eigenen verschlüsselten Anbieter schickte.
Der Unterschied zählt in dem Moment, in dem ein privater Name scheitert. In der ersten Einrichtung antwortet der VPN-Resolver für die Unternehmenszone; in der zweiten hat der Browser ihn nie gefragt, also wird der kurze Hostname nicht aufgelöst und der Fehler sieht wie ein kaputtes VPN aus. Die Prüfung ist kein weiterer Leak-Test, sie ist ein Nachschlagen eines Namens, den nur ein Resolver kennt.
Mythos zwei: Der Browser verlässt den Tunnel
DNS wählt eine Adresse, Routing trägt die Verbindung, und das sind zwei getrennte Schichten. Eine Abfrage an einen öffentlichen DoH-Anbieter ist weiterhin TCP Port 443 zu einer routbaren Adresse. Wenn Ihre Routentabelle die Standardroute in den Tunnel schickt, geht diese Abfrage ebenfalls durch den Tunnel. Die Resolver-Marke entscheidet nicht über den Weg.
Was Browser-DoH ändert, ist der Empfänger der Namen. Das ist eine echte Datenschutzentscheidung und eine echte Richtlinienentscheidung, aber kein Routing-Bypass. Wenn Ihre Anforderung ist, dass Namen beim VPN-Betreiber bleiben, verfehlt eine verschlüsselte Abfrage an jemand anderen diese Anforderung, während sie für die eigentliche Verbindung weiterhin den Tunnel nutzt.
Mythos drei: Jedes VPN überstimmt jeden Browser
Sicheres DNS in einem Browser hat Modi, keinen Schalter: aus, ein Standardanbieter mit Fallback, eine eigene Vorlage oder eine vom Betriebssystem oder der Organisation erzwungene Richtlinie. Der Fallback-Fall ist der, der sporadische Berichte erzeugt. Wenn der verschlüsselte Endpunkt nicht erreichbar ist, kann der Browser auf den System-Resolver zurückfallen, sodass derselbe Laptop einen privaten Namen am Montag korrekt auflöst und am Dienstag nicht.
Gleichzeitig setzen die meisten VPN-Clients den System-Resolver, wenn die Verbindung steht, und stellen den vorherigen wieder her, wenn sie fällt. Ein Browser mit einem eigenen verschlüsselten Resolver bemerkt diese Wiederherstellung überhaupt nicht. Deshalb verhält sich dasselbe Profil auf zwei Laptops unterschiedlich und deshalb sieht resolv.conf korrekt aus, während der Browser noch jemand anderen fragt.
resolvectl status # per-link DNS servers and split-DNS domains
scutil --dns | head -30 # macOS resolver order for each domain
nslookup intranet.corp 10.8.0.1 # ask the VPN resolver directlyFühren Sie diese aus, während Sie verbunden sind, notieren Sie, welche Domänen jeder Resolver beansprucht, und vergleichen Sie mit dem, was der Browser über seinen eigenen Modus meldet. Mozillas DoH-Dokumentation ist eine vernünftige Beschreibung, wie Standard- und Fallback-Verhalten eines Browsers funktionieren sollen.
Die Entscheidung hat drei Eingaben, nicht eine
Private Namen, Betreibervertrauen und Erreichbarkeit entscheiden über die richtige Anordnung. Namen, die nur der VPN-Resolver kennt, erzwingen Split-DNS: Das private Suffix geht an den geschickten Resolver, alles andere folgt der Richtlinie, die Sie für öffentliche Namen gewählt haben. Betreibervertrauen entscheidet, ob öffentliche Namen auch an diesen Resolver oder an einen separaten Dienst gehen sollen. Erreichbarkeit entscheidet, ob Ihr gewählter verschlüsselter Resolver in diesem Netz überhaupt nutzbar ist.
| Condition | What it forces |
|---|---|
| Internal names must resolve | Split DNS: private suffixes to the VPN resolver, the rest to your chosen default |
| Queries must stay with one operator | Pin both the system resolver and the browser mode, and disable fallback |
| Resolver only reachable through the tunnel | Keep the pushed resolver; do not point DoH at an endpoint your routes exclude |
Keine dieser Zeilen ist eine allgemeine Empfehlung. Ein vom VPN betriebener Resolver konzentriert Beobachtungen bei diesem Betreiber; ein separater Dienst fügt einen weiteren Empfänger der abgefragten Namen hinzu. Keine der Anordnungen beweist etwas über Aufbewahrung, es sei denn, Sie lesen die Richtlinie.
Schreiben Sie die Entscheidung pro Profil auf, denn diese Einstellungen driften. Ein Profil, das letzten Monat einen Resolver geschickt hat, schickt heute vielleicht keinen, und der Browser behält gern einen alten eigenen Endpunkt, der noch antwortet. In die Notiz gehören die Resolver-Adresse, die Suffixe, die er besitzt, und der Browsermodus, nicht die Marke des Dienstes.
Testen Sie die Richtlinie, die Sie glauben konfiguriert zu haben
Testen Sie nach Namen, nicht nach Symbol. Lösen Sie einen öffentlichen und einen privaten Namen über den System-Resolver auf, und wiederholen Sie das dann im Browser mit seiner eigenen sicheren DNS-Einstellung in dem Modus, den Sie verwenden wollen. Wenn der private Name nur im Browser scheitert, haben Sie die Empfängerabweichung gefunden, ohne eine einzige VPN-Einstellung anzufassen.
Verbinden Sie sich dann neu und prüfen Sie die Wiederherstellung, denn dort leben Übergabefehler: trennen, bestätigen, dass der vorherige Resolver zurückkam, neu verbinden, bestätigen, dass der geschickte zurückkam. Prüfen Sie schließlich einen Browser mit verwalteter Richtlinie, falls Sie einen haben, denn dieser Modus kann Ihre Änderung ganz ablehnen und still den vorherigen Resolver behalten.
Beginnen Sie mit der Namespace-Frage, und Sie vermeiden das meiste davon. Wenn der Rechner interne Namen erreichen muss, ist der verschlüsselte Resolver des Browsers eine Entscheidung nur über die öffentliche Hälfte, und die private Hälfte bleibt bei dem, was das VPN geschickt hat.