Warum Windows Ihre VPN-Namen an einen DNS-Server schickt, den Sie nie eingerichtet haben

Sie tragen den DNS-Server am VPN-Adapter ein, verbinden sich neu, und der private Name kommt weiterhin vom Büro-Resolver, den niemand auf diesem Laptop eingerichtet hat. Das Ergebnis sieht aus, als wäre die Einstellung ignoriert worden, und in gewissem Sinn wurde sie das, denn die Adapterliste ist eine Kandidatenmenge und keine Entscheidung. Windows löst Namen über eine Namespace-Richtlinie auf, die für ein bestimmtes Suffix einen anderen Server benennen kann, und diese Richtlinie wird angewendet, bevor die Adaptereinstellung herangezogen wird. Die Regel zu finden, die gewonnen hat, ist eine Sache von fünf Minuten, sobald man weiß, welche Tabelle man lesen muss.

Was Sie geändert haben und was tatsächlich entscheidet

Die DNS-Adresse an einem Adapter sagt dem Client, wohin diese Schnittstelle Abfragen schicken könnte. Die Name Resolution Policy Table sagt dem Client, wohin er Abfragen für einen bestimmten Namespace schicken muss, und sie wird pro Name ausgewertet, nicht pro Adapter. Wenn eine Regel zum eingegebenen Suffix passt, gelten die Server der Regel, und die Adapterliste spielt für diese Auflösung keine Rolle mehr.

Deshalb können zwei Namen auf demselben Laptop im selben Moment verschiedene Wege nehmen. Ein Host unter dem Firmensuffix folgt seiner Regel; ein öffentlicher Name folgt dem Standardweg, was meist den Adapter bedeutet, der zuerst antwortet.

Wie die Tabelle einen Namen zuordnet

Regeln sind nach Namespace geschlüsselt, und die genaueste Übereinstimmung gewinnt. Eine Regel für corp.example gilt für vpn.corp.example und nicht für example.net. Eine Regel mit dem Namespace . deckt alles ab, was die anderen Regeln nicht abdecken, was sie zum gefährlichsten Eintrag der Liste macht und zu dem, der sich zu prüfen lohnt, wenn eine unabhängige Website über den Tunnel aufgelöst wird.

Eine Regel kann außerdem einen Kommentar tragen, eine Richtlinie, die den Eintrag deaktiviert, und Sicherheitseinstellungen, die nichts mit DNS-Adressen zu tun haben. Eine deaktivierte Regel bleibt in der Konfiguration sichtbar, hat aber keine Wirkung, sodass ein auf dem Papier richtiger Eintrag nach einem Profilwechsel immer noch wirkungslos sein kann.

Lesen Sie die wirksame Tabelle, nicht die Wunschliste

Konfigurierte Regeln und wirksame Regeln sind zwei verschiedene Fragen. Get-DnsClientNrptRule listet auf, was auf dem Rechner existiert. Get-DnsClientNrptPolicy -Effective zeigt, was der Client tatsächlich anwenden wird, mit den aus Richtlinie und lokalen Einstellungen zusammengeführten Werten.

Vergleichen Sie das Suffix in dieser Ausgabe Zeichen für Zeichen mit dem Namen, den Sie testen. Eine Regel für corp.example erfasst keinen Namen, der auf corp.example.com endet, und ein Punkt am Ende an einer Stelle und nicht an der anderen reicht aus, um die Übereinstimmung zu ändern.

Ohne Regel fragt Windows mehr als einen Adapter

Wenn nichts in der Tabelle den Namen beansprucht, kann der Client die Abfrage über mehrere Schnittstellen senden und die erste eintreffende Antwort nehmen. Das Ergebnis hängt vom Zeitpunkt ab: derselbe Name kann montags über den kabelgebundenen Adapter und dienstags über den Tunnel aufgelöst werden, und nichts in der Konfiguration eines der Adapter erklärt den Unterschied.

Es gibt zwei Auswege. Fügen Sie eine Regel für den Namespace hinzu, damit die Entscheidung kein Wettrennen mehr ist, oder schalten Sie das parallele Verhalten über die DNS-Clientrichtlinie ab und akzeptieren Sie die langsamere, deterministische Auflösung. Ersteres passt meist besser zu einem VPN mit geteiltem Tunnel, weil es die Absicht dokumentiert, statt sich auf die Reihenfolge zu verlassen.

Wege, die den Resolver völlig überspringen

Ein Browser mit aktiviertem sicheren DNS löst selbst auf und übergibt Windows nur die Adresse, sodass die Regeltabelle den Namen nie sieht. Clients, die auf Laufzeitumgebungen mit eigenem Resolver aufbauen, können sich genauso verhalten. Wenn ein Name in einer Anwendung aufgelöst wird und in einer anderen auf demselben Rechner scheitert, vergleichen Sie die beiden Auflösungswege, bevor Sie die Richtlinie anfassen.

Prüfen Sie außerdem, ob die App sich mit einer zwischengespeicherten Adresse aus einer früheren Sitzung verbindet. Clear-DnsClientCache und dann dieselbe Suche ergibt eine sauberere Antwort, als sie aus einem veralteten Ergebnis zu schließen.

Testen Sie mit dem Namen, der fehlgeschlagen ist

Lösen Sie den genauen Hostnamen aus dem Bericht auf, nicht eine öffentliche Domain für Geschwindigkeitstests, und notieren Sie, welcher Server geantwortet hat. Ändern Sie dann eine Sache: die Regel, die Adapterliste oder die Richtlinienzuweisung, und wiederholen Sie dieselbe Suche nach einem erneuten Verbinden, damit der angewendete Zustand neu aufgebaut wird.

Wenn der Name aufgelöst wird und der Dienst weiterhin ablehnt, hören Sie auf, DNS zu bearbeiten. Der nächste sinnvolle Schritt ist die Adresse und die Route dorthin, denn die Namensauflösung hat ihre Aufgabe bereits erledigt.