Hat das VPN mein DNS geändert? Vergleichen Sie vorher und nachher
Ein Profil kann Ihre Abfragen gezielt verlagern. Vergleichen Sie die Resolver-Richtlinie und die tatsächliche Antwort vor und nach dem Verbindungsaufbau eines VPN, und halten Sie eine Variable fest.
Sie verbinden den Tunnel, öffnen ein privates Dashboard, und der Name wird zu einer Adresse aufgelöst, die Sie noch nie gesehen haben. Oder das Gegenteil passiert: Der Browser funktioniert weiter, während ein Kommandozeilenwerkzeug plötzlich nichts mehr auflöst. Beide Ergebnisse stammen von derselben Änderung, und meist wird das mit einem Satz über das VPN erklärt, das „sein eigenes DNS verwendet“, was weder zum Debuggen noch zum Überprüfen genau genug ist. In diesem Satz stecken zwei Fragen: Welche Abfragen soll dieses Profil übernehmen, und hat Ihre Maschine sie tatsächlich an den Resolver geschickt, den sie erhalten hat? Sie getrennt zu halten ist die ganze Methode, denn ein Test, der sie vermischt, liefert in beide Richtungen eine selbstsichere falsche Antwort.
Warum ein Profil überhaupt einen Resolver bereitstellt
Innerhalb eines Tunnels werden Namen hinter dem fernen Ende meist zu Adressen aufgelöst, die nur in diesem Netz existieren. Eine private Zone wie corp.internal hat keine öffentliche Delegation, also muss der Resolver, der sie beantwortet, von innerhalb des Tunnels erreichbar sein. Derselbe Mechanismus dient einem zweiten Zweck: Wenn Abfragen sonst über Ihren Anbieter hinausgingen, hält ein Resolver auf der fernen Seite die Abfrage im verschlüsselten Pfad. Deshalb kommt die DNS-Serveradresse als Teil der Verbindungsrichtlinie und nicht als globale Einstellung, die Sie einmal für die Maschine gewählt haben.
Die Adresse allein entscheidet nichts. Ein Resolver kann nur antworten, wenn es eine Route zu ihm gibt, und der häufigste Fehler ist ein Resolver, der nur erreichbar ist, solange der Tunnel steht. Wenn der Tunnel wegfällt und die Richtlinie bleibt, gehen Abfragen an eine Adresse ohne Pfad, und das Symptom ist ein Timeout statt eines sauberen Fehlers. Dieser Unterschied zählt, wenn Sie das nächste Testergebnis lesen, denn ein Timeout schickt Leute in Transporteinstellungen, die nie beteiligt waren.
Vergleichen Sie die beiden Designs, bevor Sie Antworten vergleichen
Volltunnel und Split-DNS erzeugen gegensätzliche Erwartungen, und keines von beiden ist eine Fehlfunktion. Unter einem Volltunnel kann jede Abfrage zum Anbieter oder zum Unternehmens-Resolver wandern, daher ist es zu erwarten, dass öffentliche Namen nach dem Verbinden anders antworten. Unter Split-DNS gehen nur gelistete Domains zum privaten Resolver, während alles andere lokal bleibt; unter Windows lebt die Domainliste in der Name Resolution Policy Table, unter macOS in den Match-Domains der DNS-Einstellungen und auf einem systemd-resolved-Host in den Routing-Domains pro Link.
Dieser Vergleich ist zuerst zu ziehen, denn er entscheidet, was als Fehler gilt. Bei Split-DNS ist ein öffentlicher Name, der von einem neuen Resolver antwortet, das, was eine Untersuchung wert ist, während ein interner Name, der korrekt antwortet, das System bei der Arbeit ist. Bei einem Volltunnel ist die Anomalie ein öffentlicher Name, der weiterhin vom Resolver Ihres Anbieters antwortet. Microsofts Dokumentation zur VPN-Namensauflösung beschreibt die Windows-Reihenfolge dieser Regeln, einschließlich der Frage, wie ein passender Richtlinieneintrag vor den eigenen Servern des Adapters herangezogen wird.
Es gibt einen dritten Resolver im Raum, den man leicht vergisst. Das sichere DNS des Browsers löst Namen selbst auf und kann weiter antworten, nachdem der Tunnel die Richtlinie des Betriebssystems geändert hat, sodass eine ladende Seite beweist, dass der Resolver des Browsers funktioniert hat, nicht dass das Profil angewendet wurde. Wenn Sie nur vergleichen, was der Browser zeigt, testen Sie die Hälfte der Zeit die falsche Schicht.
Zeichnen Sie eine Basislinie mit nur einer Variablen auf
Ändern Sie den Tunnel. Ändern Sie nicht zugleich den Namen, das Werkzeug oder das Suchsuffix im selben Schritt. Wählen Sie einen Namen, den Sie abfragen dürfen, notieren Sie, welche Anwendung Sie verwendet haben, und schreiben Sie entweder die zurückgekommene Adresse oder den genauen Fehler auf. Unter Windows gibt Get-DnsClientServerAddress -AddressFamily IPv4 die Server pro Adapter aus und Get-DnsClientNrptPolicy die Richtlinieneinträge; unter Linux mit systemd-resolved zeigt resolvectl status DNS-Server und Routing-Domains pro Link; unter macOS gibt scutil --dns die Resolver-Reihenfolge aus, die das System tatsächlich befolgt.
Verbinden Sie dann über die normalen Bedienelemente des Clients und wiederholen Sie exakt dieselben Befehle. Behalten Sie die erste Ausgabe statt einer Erinnerung daran, denn der Vergleich ist der ganze Punkt, und eine zweite Messung nach dem Leeren des Caches ist bereits eine andere Messung. Wenn die Basislinie mit dem Browser im Vordergrund genommen wurde und der Lauf nach dem Verbinden in einem Terminal stattfindet, vergleichen Sie zwei Resolver, nicht zwei Zustände eines Resolvers.
Eine explizite Abfrage und eine Anwendungssuche sind verschiedene Tests
Einen bestimmten Server zu fragen, mit nslookup name 10.20.0.1 oder dig @10.20.0.1 name, beweist eine einzige Sache: dass der genannte Server antwortet, wenn Sie ihn erreichen können. Es umgeht die Auswahllogik vollständig, kann also nicht sagen, ob das System diesen Server für diesen Namen gewählt hätte. Verwenden Sie es, um zu prüfen, ob der zugewiesene Resolver erreichbar ist, und verwenden Sie es nicht, um die Richtlinie zu prüfen.
Eine Suche über den lokalen Resolver übt die Auswahl tatsächlich aus. resolvectl query name geht dieselben Routing-Domain-Regeln durch und meldet, welches Protokoll geantwortet hat, Resolve-DnsName unter Windows geht über die Richtlinientabelle und den Client-Cache, und scutil --dns zeigt die Reihenfolge, die eine Suche befolgen würde. Führen Sie beide Arten aus und halten Sie sie in getrennten Spalten Ihrer Notizen. Eine erfolgreiche explizite Abfrage neben einer fehlgeschlagenen Anwendungssuche ist ein Routing- oder Auswahlproblem, kein Resolver, der die Arbeit verweigert.
Der Cache steht zwischen Ihnen und der Antwort. Betriebssystem, lokaler Stub-Resolver, Browser und negatives Caching halten alle Ergebnisse, sodass eine Suche gelingen kann, ohne dass ein einziges Paket die Maschine verlässt. Notieren Sie das Ergebnis, bevor Sie irgendetwas leeren: ipconfig /flushdns, resolvectl flush-caches oder sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder unter macOS. Überspringen Sie den breiten Netzwerk-Reset in dieser Phase, denn er zerstört die Beweise, die Sie noch sammeln.
Was der Unterschied bedeutet
Vergleichen Sie die beiden aufgezeichneten Zeilen und ordnen Sie die Änderung ein, bevor Sie eine einzige Einstellung anfassen.
| Observation after connect | Most likely cause | Next step |
|---|---|---|
| Answer moves to a private address range | Expected under split DNS or a private zone | Confirm the suffix is in the effective policy, then test the service |
| Lookup times out while connected, works after disconnect | The assigned resolver has no route from this machine | Probe it with an explicit query, then re-read the policy |
| Internal name fails, public names work | Wrong namespace or a suffix missing from the policy | Query the fully qualified name and check the domain list per platform |
| Internal name returns a public address | Split DNS not applied; a public resolver answered | Check browser secure DNS first, then the per-link domain list |
Eine Zeile verdient Betonung. Ein Name, der aufgelöst wird, ist kein Dienst, der funktioniert, und DNS-Erfolg sagt nur, dass eine Adresse gefunden wurde. Er sagt nichts über Weiterleitung, Firewall-Regeln oder darüber, ob Ihr Konto den Dienst überhaupt nutzen darf, also schließen Sie mit dem Test der tatsächlichen Anwendung ab, statt anzunehmen, der Fehler habe sich von selbst verabschiedet.
Stellen Sie die Basislinie wieder her und prüfen Sie sie
Trennen Sie die Verbindung über die eigenen Bedienelemente des Clients, statt den Prozess zu killen, und lesen Sie dann dieselben drei Befehle erneut. Die Server pro Link, die Richtlinieneinträge und die Antwort für Ihren Testnamen sollten zur zuvor notierten Basislinie zurückkehren. Ein übrig gebliebener Richtlinieneintrag nach einem sauberen Trennen ist ein echter Defekt, der festgehalten werden sollte, und genau deshalb sind Handbearbeitungen einer generierten Resolver-Datei eine schlechte Angewohnheit: Die Datei wird neu geschrieben und die Änderung verschwindet, oder die Änderung überlebt und nagelt einen Resolver fest, der keine Route mehr hat.
Gehen Sie diese Liste einmal in der Reihenfolge durch. Entscheiden Sie, welches Design das Profil umsetzt, bevor Sie irgendein Ergebnis beurteilen. Halten Sie Name, Werkzeug und Suffix über beide Läufe fest. Trennen Sie die explizite Abfrage von der Anwendungssuche. Lesen Sie die effektive Richtlinie, nicht nur die Antwort. Leeren Sie Caches zuletzt, nachdem der Vergleich notiert ist. Prüfen Sie mit der echten Anwendung, starten Sie dann einmal neu und bestätigen Sie, dass der getrennte Zustand weiterhin sauber ist.