Falscher DNS-Server bei Windows VPN: Metrik, Bindungsreihenfolge oder Suffix

Ein Windows-Client kann einen funktionierenden Tunnel haben, den Firmen-Resolver mitbringen und trotzdem interne Namen an den Heimrouter schicken. Drei verschiedene Mechanismen entscheiden, welcher Server antwortet, und sie versagen unterschiedlich. Sie müssen nicht alle drei reparieren: Das Symptom sagt Ihnen, welcher im Spiel ist. Der Entscheidungsbaum unten dauert ein paar Minuten und verhindert das übliche Ergebnis, bei dem eine Metrikänderung, eine Umsortierung der Registrierung und eine NRPT-Regel gemeinsam landen und niemand weiß, welche davon etwas bewirkt hat.

Drei Mechanismen entscheiden, und meist ist einer falsch

Die Schnittstellenmetrik ordnet Adapter für eine Adressfamilie. Die Bindungsreihenfolge unter Tcpip\Linkage ist eine maschinenweite Liste von Schnittstellenkennungen, die ältere Codepfade noch heranziehen. Die Richtlinientabelle für Namensauflösung (NRPT) bindet einen Namensraum an bestimmte Server, und die Suffixliste entscheidet, ob ein Kurzname überhaupt erweitert wird. Sie sind unabhängig, und deshalb verliert ein korrekter Resolver am VPN-Adapter gegen eine veraltete Präferenz anderswo.

Keiner dieser Mechanismen ist die Gegenseite des Tunnels. Kann der vom VPN ausgelieferte Server den Namen nicht auflösen, ist jede Einstellung auf Clientseite Dekoration, also lautet die erste Entscheidung, ob der Resolver selbst antworten kann, wenn man ihn direkt fragt.

Entscheidung eins: Kann der ausgelieferte Resolver überhaupt antworten?

Fragen Sie den Server ausdrücklich und vergleichen Sie das mit einer gewöhnlichen Abfrage. Die Lücke zwischen den Antworten trennt ein Auswahlproblem von einem Erreichbarkeitsproblem, und das ist hier die schnellste Gabelung:

Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type A

Gelingt die erste und scheitert die zweite, ist der Resolver erreichbar und Windows wählt schlecht; gehen Sie zu den Entscheidungen zu Namensraum und Reihenfolge unten. Scheitert auch die erste, hilft nichts auf dem Client: prüfen Sie, ob UDP und TCP 53 den Server durch den Tunnel erreichen, ob eine Host-Firewall auf dem Server den Pool verwirft und ob die eigenen Weiterleiter des Servers gesund sind.

Halten Sie an dieser Gabelung an. Eine NRPT-Regel auf einen Resolver anzuwenden, den Sie nicht erreichen, erzeugt denselben Fehler mit mehr Konfiguration zum Zurücknehmen, und sie verdeckt den eigentlichen Defekt hinter einer Regel, die autoritativ aussieht.

Entscheidung zwei: ein Namensraum oder jede Abfrage?

Der Umfang entscheidet über das Werkzeug. Wenn nur Firmennamen scheitern, binden Sie den Namensraum, statt die Maschine umzusortieren: Eine NRPT-Regel schickt dieses Suffix an den Resolver des Tunnels und lässt alles andere in Ruhe. Wenn jede Abfrage betroffen ist, ist das Problem die globale Adapterpräferenz, und die Metrik ist der richtige Anfang, weil sie keine Servereinstellung ändert.

Setzen Sie die Metrik je Adressfamilie, auf beiden Schnittstellen, und bestätigen Sie die Reihenfolge danach:

Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv6

Ersetzen Sie 11 durch den ifIndex des Tunneladapters aus der Zeile oben; ist 11 der LAN-Adapter, senkt derselbe Befehl den falschen Pfad. Den LAN-Adapter stattdessen anzuheben erreicht dieselbe Reihenfolge von der anderen Seite: netsh int ip set interface interface="Ethernet" metric=15, und netsh int ipv6 set interface interface="Ethernet" metric=15 für die zweite Familie, weil int ip nur IPv4 betrifft.

Die Bindungsreihenfolge ist das letzte Mittel und nicht der erste Schritt. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage enthält eine Bind-Liste von Gerätekennungen, und die Tunnelkennung nach vorn zu ziehen ändert tatsächlich, welcher Adapter zuerst gefragt wird, aber es ist ein maschinenweiter Registrierungswert ohne Geltung je Namensraum. Exportieren Sie ihn vor dem Bearbeiten und verbinden Sie den Tunnel danach neu, damit die Reihenfolge in dem Zustand gilt, den der Client erwartet.

Für einen einzelnen Namensraum nehmen Sie das schmalere Werkzeug:

Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServers

Entscheidung drei: Überlebt die Korrektur eine Neuverbindung?

Eine Metrik, die bis zur nächsten Einwahlverbindung hält, wurde nie gespeichert. L2TP/IPsec und andere Verbindungsprofile werden beim Verbindungsaufbau neu erzeugt, deshalb lebt der gespeicherte Wert im Telefonbucheintrag als IpInterfaceMetric, nicht nur auf der aktiven Schnittstelle. Manche Umgebungen skripten dieses Feld aus genau diesem Grund; andere schieben die Präferenz aus einer Verwaltungsrichtlinie und lassen den Endpunkt in Ruhe.

Cache und Registrierung sind eine eigene Schicht. Diese Befehle nach dem Hochfahren des Tunnels auszuführen, repariert veraltete Einträge und registriert den Client neu, aber keiner von beiden ordnet einen Adapter um:

ipconfig /registerdns
ipconfig /flushdns

In derselben Schicht gibt es einen Ausschalter. Die dynamische Registrierung am physischen Adapter abzuschalten, hindert den Client daran, seine VPN-seitige Adresse unter dem falschen Namen anzukündigen, was eine andere Reparatur ist als die Aktualisierung oben.

IPv6 verdient eine eigene Zeile in der Entscheidung. Hat der physische Adapter eine globale IPv6-Adresse, während der Tunnel nur IPv4 trägt, kann Windows für die Namensauflösung den ungetunnelten Pfad bevorzugen. Prüfen Sie diese Familie getrennt, denn eine für IPv4 gesetzte Metrik sagt nichts über sie aus:

Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetric

IPv6 am LAN-Adapter abzuschalten entfernt diesen Pfad und das Protokoll mit ihm; eine Metrikänderung an der IPv6-Schnittstelle oder eine NRPT-Regel für den Firmennamensraum behält die Familie und korrigiert die Präferenz. Nehmen Sie die schmalere Variante, sofern Sie nicht entschieden haben, dass dieser Link kein IPv6 haben soll.

Mit benannter Quelle prüfen, und einen Verantwortlichen behalten

Prüfen Sie mit Werkzeugen, die melden, welche Quelle gilt, nicht nur, ob eine Seite lädt:

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type A

Trennen Sie dann Filtern von Auswählen, denn aus einer Anwendung sehen sie identisch aus. block-outside-dns von OpenVPN blockiert Port 53 auf anderen Adaptern; es wählt keinen Resolver. Scheitert nun jede Abfrage, blockiert womöglich ein Filter den einzigen erreichbaren Server; wird der konfigurierte Resolver ignoriert, ist die Reihenfolge oder die Namensraumregel falsch. Beides gleichzeitig zu ändern macht eine blockierte Abfrage und eine ignorierte Abfrage ununterscheidbar.

Behalten Sie einen Verantwortlichen für die DNS-Richtlinie: das VPN-Profil, eine Verwaltungsrichtlinie oder eine NRPT-Regel, nicht zwei davon. Bevor Sie abschließen:

• Der ausgelieferte Resolver antwortet, wenn man ihn ausdrücklich nennt, und eine gewöhnliche Abfrage nutzt ihn.
• Die geänderte Regel oder Metrik deckt die Adressfamilie ab, die die Abfragen tatsächlich trägt.
• Die Einstellung überlebt Trennen und Neuverbinden, oder Sie haben sie ins gespeicherte Profil verschoben.
• Genau ein Mechanismus ist maßgeblich, und die anderen wurden belassen, wie sie waren.

Behandeln Sie die Reihenfolge als Umgebungszustand und nicht als etwas, das man abschließt. Prüfen Sie sie nach einer Neuverbindung und nach einem Windows-Update, das den Netzwerkstapel berührt, denn beides kann den physischen Adapter wieder nach vorn bringen.