Warum nslookup über das VPN auflöst, der Browser aber nicht

nslookup sendet eine Anfrage an den von Ihnen genannten Server und druckt die Antwort, deshalb kann es gelingen, während jeder Browsertab scheitert. Ein Browser bittet das Betriebssystem aufzulösen, und das Betriebssystem wägt Resolver je Schnittstelle, Regeln für die Namensauflösungsrichtlinie und den Netzwerkstandort des Adapters ab. Danach kann der Browser sein eigenes verschlüsseltes DNS darüberlegen. Drei verschiedene Pfade, ein Symptom, und der Tunnel ist meist nicht der defekte Teil.

Die folgenden Prüfungen folgen diesen Pfaden vom System nach außen. Ändern Sie das VPN-Profil erst, wenn Sie wissen, welcher Pfad geantwortet hat und welcher fehlgeschlagen ist.

Drei Richtlinien entscheiden die Antwort

Jede Schnittstelle trägt ihre eigene Resolverliste und Suchsuffixe. Ein VPN-Adapter fügt Server hinzu, während der physische Adapter seine eigenen behält, und das System kann den nehmen, der zuerst antwortet, sodass eine Auflösung außerhalb des Tunnels bedient werden kann, ohne dass jemand das gewählt hat. Regeln der Namensauflösungsrichtlinien-Tabelle können ausgewählte Domänen an ausgewählte Server schicken, und so wird Split-DNS unter Windows üblicherweise ausgedrückt. Und der VPN-Client oder das Gateway kann eine Resolveradresse durchreichen, die nur innerhalb des privaten Netzes existiert.

Diese drei wirken auf eine Weise zusammen, die aus dem Browser willkürlich aussieht. Ein durchgereichter Resolver an einer privaten Adresse ohne Route durch den Split-Tunnel lässt jede Auflösung hängen und dann scheitern. Eine Richtlinienregel, die das interne Suffix abdeckt und auf einen ausgefallenen Server zeigt, erzeugt denselben sichtbaren Fehler wie eine fehlende Route. Ein am VPN-Adapter fehlendes Suchsuffix macht aus einem kurzen Namen eine öffentliche Abfrage für die falsche Domäne. Jeder davon braucht eine andere Reparatur.

Warum der Browser eine andere Frage stellt

nslookup stellt seine eigene Abfrage an den Server, den es auswählt, und folgt weder der Namensraumrichtlinie noch der Einstellung des Browsers für verschlüsseltes DNS. Deshalb antwortet eine manuelle Abfrage an einen öffentlichen Resolver, während der Browser meldet, die Seite existiere nicht. Sie vergleichen zwei Programme, nicht zwei Zustände eines Programms.

Die Adressfamilien-Präferenz erklärt Verzögerung und nicht Fehlschlag. Ein Browser, der auf einem nur IPv4 führenden Tunnel zuerst IPv6-Einträge anfragt, wartet auf ein Zeitlimit, bevor er zurückfällt. Firefox hat genau dafür eine Präferenz getragen, und sie abzuschalten ist ein Diagnoseschritt und keine Reparatur.

Lesen Sie die Resolverliste und die Regeln

Dumpen Sie unter Windows, was das System hält, bevor Sie theoretisieren. Get-DnsClientServerAddress zeigt die Server je Schnittstelle, Get-DnsClientNrptRule listet die Namensraumregeln, und Resolve-DnsName beantwortet den genauen Namen über den Systempfad. Vergleichen Sie diese Antwort mit einer direkten Abfrage an den Server des VPN per Adresse. Wenn Resolve-DnsName scheitert und die direkte Abfrage gelingt, sind die Resolverliste oder eine Namensraumregel verdächtig.

Prüfen Sie auch den Namen selbst. Ein interner kurzer Name braucht vielleicht das private Suffix, das nur der VPN-Adapter liefert, während der vollqualifizierte Name sauber auflöst. Eine Zertifikatswarnung nach erfolgreicher Auflösung gehört zu einem anderen Problem.

Der unerreichbare durchgereichte Resolver

Ein Gateway oder Client kann eine Resolveradresse durchreichen, und diese Adresse muss durch den Tunnel erreichbar sein. Bei einem Split-Tunnel ist der private Bereich, der den Resolver enthält, vielleicht nicht in den eingeschlossenen Routen, was eine Auflösung ergibt, die nie eine Antwort erhält. Bestätigen Sie, dass die Route existiert, und fragen Sie dann genau diese Adresse durch den Tunnel ab. Das ist der Fehler hinter einem Browser-Domänenfehler, während ein öffentlicher Resolver noch antwortet.

Ist der Resolver unerreichbar, ist die Reparatur eine Route oder ein eingeschlossenes Subnetz, kein anderer DNS-Server.

Verschlüsseltes DNS umgeht den ganzen Pfad

Browser mit DNS-over-HTTPS lösen Namen selbst über eine HTTPS-Verbindung zu einem gewählten Anbieter auf. Ist das an, werden der Systemresolver und die Split-DNS-Regeln für diese Auflösungen völlig umgangen, sodass interne Namen im Browser scheitern, während das Betriebssystem sie korrekt auflöst. Auch das Umgekehrte passiert: interne Namen gelingen im Browser über einen Anbieter, der sie nie sehen dürfte, und das ist ein Richtlinienproblem und kein Konnektivitätsproblem.

Entscheiden Sie bewusst, ob verschlüsseltes DNS auf verwalteten Geräten erlaubt ist, und konfigurieren Sie es dann über die Verwaltungsoberfläche des Browsers, damit die Wahl sichtbar ist. Es der individuellen Vorliebe zu überlassen, erzeugt einen Bestand, in dem dasselbe VPN auf jedem Laptop anders arbeitet.

Reparaturen, die zum Fehler passen

Wenn das VPN seinen Resolver durchreicht, sorgen Sie dafür, dass der Tunnel Verkehr dorthin führt und dieselbe Einstellung auf den Adaptern sichtbar ist, die an der Auflösung teilnehmen. Wenn lokale Seiten bei bestehender Verbindung nicht mehr auflösen, fügen Sie ausdrückliche Namensraum-Ausnahmen oder einen bedingten Weiterleiter hinzu, statt den Resolver pauschal zu ersetzen. Wenn das verschlüsselte DNS des Browsers die Richtlinie umgeht, ist das die Einstellung, die geändert werden muss. Fügen Sie niemals einen öffentlichen Resolver hinzu, um einen internen Namen zu reparieren: er leakt private Abfragen und löst den Namen nicht auf.

Trennen Sie dann die Auflösung von der Verbindung. Ein Name, der zur richtigen Adresse auflöst, aber eine Verbindung verweigert, ist ein Dienst-, Firewall- oder Zertifikatsproblem, und DNS-Änderungen beheben es nicht.

Notieren Sie, welcher Pfad geantwortet hat, welcher fehlgeschlagen ist und was Sie geändert haben. Der nächste Bericht über dasselbe Symptom kostet dann einen Befehl statt eines Nachmittags.