VPN verbunden, aber Namensauflösung scheitert: Wo DNS wirklich bricht

Tunnel steht, Symbol grün, und jeder Browser-Tab meldet einen Fehler bei der Namensauflösung. Drei verschiedene Mechanismen erzeugen dieses Bild: Der Resolver ist vielleicht nicht erreichbar, der Client fragt vielleicht einen Resolver ab, den Sie nicht erwartet haben, oder nur die privaten Namen scheitern. Trennen Sie diese Fälle, bevor Sie irgendetwas am Tunnelprotokoll ändern, denn jeder wird an einer anderen Stelle repariert. Die folgende Reihenfolge beginnt mit den Beobachtungen, die die drei voneinander scheiden.

Was eine Abfrage wirklich braucht

Eine Abfrage braucht drei Dinge: eine Resolver-Adresse, eine Route zu dieser Adresse und eine Antwort, die zur Frage passt. Jedes davon kann für sich scheitern, und das sichtbare Symptom ist dieselbe Seite, die nicht lädt. Deshalb verrät Ihnen die Fehlerseite fast nichts, solange Sie nicht wissen, welches der drei Dinge ausgefallen ist.

Der Client erfährt seinen Resolver aus dem VPN-Profil, per DHCP am Tunnel oder aus seiner eigenen Konfiguration, und welche Quelle sich durchsetzt, hängt von der Plattform ab. Unter Windows listet ipconfig /all die DNS-Server pro Adapter auf, sodass Sie sehen, ob der übertragene Wert tatsächlich angekommen ist. Ein übertragener Wert, der das Betriebssystem nie erreicht hat, ist ein stiller und häufiger Fehler. Lesen Sie den konfigurierten Wert, bevor Sie das Profil anfassen.

Linux und macOS beantworten dieselbe Frage mit anderen Befehlen, und die Antwort verdient dieselbe Aufmerksamkeit: resolvectl status und scutil --dns listen beide die Server pro Schnittstelle auf. Vergleichen Sie diese Liste mit der Adresse, die das Profil angeblich überträgt. Eine Abweichung an dieser Stelle erklärt alles Weitere, also klären Sie sie, bevor Sie Namen testen.

Einen öffentlichen und einen privaten Namen testen

Fragen Sie einen gewöhnlichen öffentlichen Hostnamen und den dokumentierten privaten Hostnamen von derselben Maschine ab und notieren Sie, welcher Server jeweils geantwortet hat. Scheitern beide, ist der Resolver oder seine Route defekt. Scheitert nur der private Name, hat der Resolver geantwortet, und die Frage verlagert sich auf die Zone oder das Routing. Führen Sie die beiden Abfragen innerhalb einer Minute aus, damit ein Routenwechsel den Unterschied nicht erklären kann.

Halten Sie interne Namen aus öffentlichen Screenshots und aus öffentlichen Resolvern heraus. Ein Timeout und die Antwort „nicht existierende Domain“ sind unterschiedliche Beobachtungen: Die erste sagt, dass nichts zurückkam, die zweite, dass eine Autorität geantwortet hat, der Name existiere nicht. Behandelt man beides als einen Fehler, landet man auf der falschen Ebene, und eine Zertifikatswarnung ist wiederum etwas Drittes und kein DNS-Fehler.

nslookup zeigt sowohl den abgefragten Server als auch die erhaltene Antwort an, und genau dieses Paar brauchen Sie. Führen Sie den Befehl zweimal in derselben Shell aus und schreiben Sie die antwortende Adresse neben jede Antwort.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Prüfen, ob der Client diesen Server überhaupt erreicht

Ein vom Profil übertragener privater Resolver nützt nur, wenn der Client ihn bei bestehendem Tunnel erreichen kann. Eine korrekt aussehende Adresse ohne Route erzeugt einen Timeout, und der verbundene Zustand des Tunnels sagt nichts über diese Route aus. Der Test ist eine Routenabfrage auf den Resolver selbst, nicht auf den VPN-Endpunkt.

Jede Plattform beantwortet das in einer Zeile, und die in der Ausgabe genannte Schnittstelle ist die ganze Antwort. Zeigt sie auf den physischen Adapter, während der Resolver hinter dem Tunnel liegt, überträgt das Profil kein Präfix, das ihn abdeckt.

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

Bei einem Split-Tunnel-Profil kann der Resolver außerhalb der übertragenen Routen liegen, was ein Profilproblem und kein Serverproblem ist. Vergleichen Sie die Resolver-Adresse mit den übertragenen Präfixen und bestätigen Sie, dass eines davon sie abdeckt. Dieselbe Abweichung erklärt, warum DNS in einem Netz funktioniert und in einem anderen mit identischem Profil scheitert.

Bedenken Sie, dass Browser den System-Resolver umgehen können

Ein Browser mit aktiviertem Secure DNS kann Abfragen per HTTPS an einen Anbieter seiner Wahl senden und den Resolver des Betriebssystems völlig ignorieren. Dann sieht das System korrekt aus, während der Browser scheitert, oder umgekehrt. Das ist eine Richtlinienfrage für den Browser, nicht für den Tunnel.

Prüfen Sie die Secure-DNS-Einstellung des Browsers und jede verwaltete Richtlinie, die sie steuert, und versuchen Sie dann eine zweite Anwendung oder einen zweiten Browser bei unverändertem Tunnel. Scheitert nur eine Anwendung, gehört die Korrektur in diese Anwendung. Ein privates Fenster ist kein sauberer Vergleich, weil es in einem Browser standardmäßig Erweiterungen deaktivieren kann und in einem anderen nicht, und es umgeht nie verwaltete Richtlinien. Verwenden Sie stattdessen ein zweites Browserprofil oder eine andere Anwendung.

Cache leeren und die eigentliche Aufgabe erneut testen

Leeren Sie nach der Korrektur einer Einstellung den lokalen Resolver-Cache, damit eine alte Antwort die Lösung nicht überlebt. Eine kurze Erholung, gefolgt von einem erneuten Fehler, bedeutet, dass die Ursache noch vorhanden ist, und nicht, dass das Leeren fehlgeschlagen ist. Wählen Sie die Zeile, die zu Ihrer Maschine passt, denn die drei Caches sind getrennt.

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

Wiederholen Sie dann die ursprüngliche Aufgabe statt einer synthetischen Abfrage, denn die Aufgabe ist, was den Nutzer interessiert. Verbinden Sie sich außerdem einmal neu, damit der erneute Test den Zustand abdeckt, in dem der Nutzer tatsächlich sein wird. Microsofts nslookup-Referenz ist die Seite, die Sie für die Abfrageargumente behalten sollten.

Wenn Namen erst nach dem Trennen scheitern, hat der Client die vorherige Konfiguration nicht wiederhergestellt, was ein Fehler im Lebenszyklus ist, den Sie melden sollten, statt einen DNS-Server zu ersetzen. Eine funktionierende Abfrage ist außerdem kein Leak-Test, denn das Ausgangsland sagt Ihnen nichts darüber, welcher Resolver geantwortet hat.