VPN hat DNS übernommen und lokale Namen zerstört: Liste reparieren

Der Tunnel kommt hoch, das Intranet lädt, und der Name des Druckers wird nicht mehr aufgelöst. Oder umgekehrt: lokale Namen funktionieren noch, während alles im Firmennetz in eine Zeitüberschreitung läuft. Beide Symptome stammen von derselben Stelle, einer Resolver-Liste, die der VPN-Client beim Verbinden neu geschrieben hat.

Reparieren Sie die Liste gezielt und behandeln Sie danach den Push-Mechanismus getrennt. Routen sind ein drittes Thema und nicht das, was hier repariert wird.

Welche Liste Anwendungen tatsächlich verwenden

Windows löst über Einstellungen auf Schnittstellenebene auf und nicht über das, was ein Dialog anzeigt, beginnen Sie also mit den effektiven Listen je Schnittstelle. Der Alias zählt mehr als der Anzeigename, weil jeder Befehl unten eine Schnittstelle anspricht. Vertun Sie den Alias, landet die Reparatur auf dem falschen Adapter. Es sieht so aus, als würde es funktionieren, bis zum nächsten Verbindungsaufbau, wenn der eigene Eintrag des Tunnels zurückkehrt.

Die Frage ist, welche Server nach vorn gerutscht sind und ob sie als statische Einträge oder als DHCP-Lease kamen. Beide Tatsachen entscheiden, welche Reparatur Ihnen offensteht.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Lesen Sie die Ausgabe für den Tunneladapter und für den physischen Adapter und notieren Sie jede Adresse auf beiden. Ein statischer Eintrag lässt sich per Richtlinie oder Skript entfernen; ein per DHCP bezogener Eintrag hängt am Lease und kommt zurück, was die passende Reparatur ändert. Namen im entfernten Netz löst der angekündigte Resolver auf, Namen im lokalen LAN der physische Adapter, und die Abfrage geht an die Liste, die zuerst herangezogen wird.

Die gepushten Server entfernen oder niedriger einordnen

Löschen Sie die gepushten Server, wenn innerhalb des Tunnels nichts sie braucht, denn die eigenen Resolver des physischen Adapters übernehmen wieder. Behalten Sie sie nur, wenn das entfernte Netz Zonen besitzt, die allein seine Server beantworten können, und setzen Sie in diesem Fall einen lokalen Resolver davor. Die beiden Befehle unten decken beide Möglichkeiten ab, wählen Sie also den, der zur Situation passt, statt beide auszuführen.

netsh interface ipv4 delete dnsservers name="Corp VPN" address=all validate=no
netsh interface ipv4 add dnsservers name="Corp VPN" address=172.16.20.1 index=1 validate=no

Index 1 wird zuerst herangezogen, die gepushten Adressen bleiben also verfügbar, sind aber nicht mehr die Standardantwort auf jede Abfrage. Das Flag validate=no überspringt eine Erreichbarkeitsprüfung, die häufig fehlschlägt, während sich der Tunnel noch einpendelt, bestätigen Sie das Ergebnis also mit dem show-Befehl, statt dem Exit-Code zu trauen.

Zwei Grenzen sollte man kennen, bevor man sich darauf verlässt. Windows löscht keine Server, die per DHCP über netsh kamen, und diese Werte bleiben als DhcpNameServer unter dem Registrierungsschlüssel der Schnittstelle bestehen, eine Registry-Änderung ist also letztes Mittel und muss nach dem nächsten Lease erneut geprüft werden. Auch die Bindungsreihenfolge der Adapter ist kein verlässlicher Rangmechanismus, weil ein VPN-Client seinen eigenen Eintrag oben in die Liste einfügen kann.

Wo sich der Push filtern lässt

Eine bessere Reparatur entfernt die Option, bevor sie angewendet wird. Der Community-OpenVPN-Client kann eine gepushte Direktive nach Namen filtern, was die Konfiguration des Servers unangetastet lässt.

pull-filter ignore "dhcp-option DNS "

Das abschließende Leerzeichen gehört zum Abgleich, und der Filter benennt die Option statt einer Serveradresse. Enthält das Profil zusätzlich eine Direktive block-outside-dns, ändert deren Entfernung den Leak-Schutz und nicht die Namensauflösung, entscheiden Sie das also getrennt, statt beide Änderungen zu bündeln.

Für einen einzelnen hartnäckigen Hostnamen ist eine Zeile in der Windows-hosts-Datei stabiler, als Resolver für die ganze Maschine umzusortieren. Sie ist auch für den Nächsten unsichtbar, notieren Sie sie also dort, wo die Konfiguration der Maschine dokumentiert ist.

Die Reparatur einen Verbindungsaufbau überstehen lassen

Die Auflösung muss zweimal getestet werden, einmal gegen einen gewählten Server und einmal in der Form, die eine Anwendung nutzt. Dieses Paar trennt ein Resolver-Reihenfolgeproblem von einem Server, der überhaupt nicht antwortet. Wird der erste Test übersprungen, bleiben die beiden Ursachen verfilzt.

Resolve-DnsName intranet.corp.example -Server 172.16.20.1
Resolve-DnsName printer.lan

Verbinden Sie den Tunnel erneut und wiederholen Sie beide Befehle. Was Sie von Hand geändert haben, hält nur bis zur nächsten Verbindung, weil der Client seinen Resolver-Zustand neu aufbaut, während er den Adapter hochzieht. Setzen Sie die Zeilen netsh in das unterstützte Verbindungsskript Ihres Clients, lassen Sie das Skript erfolgreich beenden und fügen Sie eine kurze Wartezeit hinzu, bevor es läuft. Ein Client, der DNS nach dem Skript anwendet, überschreibt das Ergebnis ohnehin.

Wenn öffentliche Namen aufgelöst werden und interne nach der Reparatur weiterhin fehlschlagen, ist die Resolver-Liste nicht mehr der Verdächtige. Die Abfrage erreicht den Server wahrscheinlich überhaupt nicht, was auf Routing oder eine Firewall-Regel deutet und nicht auf eine weitere DNS-Einstellung. Notieren Sie den Schnittstellen-Alias und die Adressen, auf die Sie sich festgelegt haben, weil beide sich zwischen Maschinen unterscheiden und keine einen Neuaufbau allein übersteht.