Warum verliert WSL den Arbeits-Hostnamen, wenn die VPN-Verbindung steht?

Windows löst den internen Host ohne Beschwerden auf, und derselbe Name schlägt in WSL in dem Moment fehl, in dem der Tunnel steht. Die übliche Reparatur besteht darin, einen öffentlichen Resolver in die Distribution zu schreiben, was normales Surfen wiederherstellt und den Arbeits-Hostnamen unauflösbar macht. Das tauscht einen Fehler gegen einen anderen und verdeckt die Schicht, die tatsächlich kaputtgegangen ist. Bevor Sie eine Resolver-Zeile hinzufügen oder entfernen, finden Sie heraus, welche der drei Schichten ausfällt.

Schließen Sie zuerst einen Routingfehler aus

Fragen Sie denselben vollqualifizierten Namen auf beiden Seiten ab, nicht zwei Namen, die ähnlich aussehen. Ein Erfolg unter Windows und ein Fehlschlag in WSL für dieselbe Zeichenkette ist die Signatur zweier Auflösungswege, und kaum etwas anderes erzeugt dieses Muster so sauber. Wenn WSL den Dienst auch unter seiner bekannten numerischen Adresse nicht erreicht, liegt zusätzlich ein Routing- oder Filterproblem vor. In diesem Fall wird DNS-Arbeit es nicht aufdecken, und der Nachmittag geht an die falsche Schicht.

Drei Symptome decken die meisten dieser Fälle ab, und jedes weist woandershin. Lesen Sie die passende Zeile, bevor Sie eine Konfigurationsdatei öffnen:

Die mittlere Zeile wird oft falsch gelesen, weil die Änderung, die sie kaputt gemacht hat, Wochen früher erfolgte und damals erfolgreich aussah. Die dritte Zeile wird oft falsch diagnostiziert, weil ein Name, der aufgelöst wird, wie ein Beweis wirkt, dass das Netzwerk gesund ist. Beide Zeilen schicken Sie in einen anderen Abschnitt weiter unten.

DNS-Tunneling hat eine Versionsuntergrenze

Microsoft dokumentiert einen WSL-Netzwerkmodus, der DNS-Anfragen über einen Virtualisierungskanal an den Windows-Resolver tunnelt. Auf unterstützten Windows 11-Builds ist er standardmäßig aktiviert, weshalb sich zwei Rechner im selben Firmennetz unterschiedlich verhalten. Die Variable ist die Build-Nummer, nicht die Firmenrichtlinie.

Der WSL-Netzwerkleitfaden beschreibt diesen Modus und die Versionen, die ihn unterstützen. Die Funktion ist wichtig, weil die DNS-Richtlinie von Unternehmen normalerweise im Windows-Resolver lebt, und eine Distribution, die den Windows-Pfad erbt, erbt die Richtlinie mit. Eine Distribution, die einen öffentlichen Resolver fragt, hat keine Route zu einem privaten Namen, so ordentlich ihre eigene Konfiguration auch aussieht. Dieser Mechanismus erklärt das gesamte Symptom und erklärt, warum der Workaround mit öffentlichem Resolver scheitert.

Lesen Sie die Build-Nummer, bevor Sie etwas ändern. Eine aus einer neueren Installation kopierte Einstellung ist kein Beweis dafür, dass eine ältere sie umsetzt. Notieren Sie die Build-Nummer neben der Änderung, denn der Unterschied zwischen zwei Rechnern ist fast immer eine Version und keine Richtlinie.

Alte Überschreibungen überleben das Problem, das sie gelöst haben

Ältere Rezepte deaktivierten generierte Resolver-Dateien, schrieben einen Nameserver fest oder sperrten die Datei mit einem Immutable-Attribut. Diese Änderungen bleiben lange bestehen, nachdem das Konnektivitätsproblem, das sie ausgelöst hat, verschwunden ist, und meist sind sie der Grund, warum eine neuere Einstellung wirkungslos erscheint. Sie überleben auch eine Neuinstallation der Distribution in Form eines Shell-Profils, das die Datei bei jeder Anmeldung neu schreibt. Letzteres ist am schwersten zu finden, weil es aus der Datei unsichtbar ist, die alle prüfen.

Suchen Sie eine handgeschriebene Resolver-Datei, ein Immutable-Attribut darauf und ein Startskript, das sie neu schreibt. Prüfen Sie das Immutable-Flag vor dem Bearbeiten, denn ein Schreibzugriff auf eine gesperrte Datei scheitert auf eine Weise, die wie ein Berechtigungsproblem klingt. Prüfen Sie danach das Shell-Profil, denn ein Skript dort stellt den alten Inhalt binnen Sekunden nach Ihrer Korrektur wieder her.

Das Entfernen einer Überschreibung hat Folgen, also notieren Sie, was Sie entfernt haben und warum. Eine Distribution, die für einen anderen Zweck wirklich einen statischen Resolver braucht, bricht, wenn die generierte Datei zurückkehrt.

Zwei Dateien, zwei verschiedene Rollen

Die beiden Konfigurationsdateien liegen an verschiedenen Orten und steuern verschiedene Dinge, und ihre Verwechslung führt zu Änderungen an der falschen Schicht. Die Datei auf der Windows-Seite setzt Eigenschaften der virtuellen Maschine, während die Datei auf der Distributionsseite festlegt, wie diese Distribution ihre eigene Resolver-Konfiguration aufbaut. Keine überschreibt die andere, deshalb müssen beide übereinstimmen.

Für eine Installation, die die Funktion unterstützt, ist das Fragment auf der Windows-Seite kurz. Es ist die gesamte Änderung auf dieser Seite:

[wsl2]
dnsTunneling=true

Dieses Fragment gehört in das Windows-Benutzerprofil und gilt für die virtuelle Maschine statt für eine einzelne Distribution. Tunneling setzt außerdem voraus, dass die Distribution die Resolver-Generierung nicht deaktiviert hat, also muss die Datei auf der Distributionsseite dieses Verhalten in Ruhe lassen. Ändern Sie eines ohne das andere, und der Modus tut stillschweigend nichts, was die häufigste Art ist, wie diese Reparatur als defekt gemeldet wird. Prüfen Sie beide Dateien in derselben Sitzung, denn zwei Wochen auseinanderliegende Änderungen sind zwei Änderungen, die niemand zuordnen kann.

Neu starten, dann von beiden Seiten abfragen

Diese Einstellungen werden beim Start der Umgebung gelesen, eine neue Shell in einer laufenden Distribution lädt sie also nicht neu. Fahren Sie die Umgebung herunter, statt die Shell neu zu starten, und speichern Sie zuerst laufende Arbeit, weil jede Distribution damit stoppt. Allein diese Auslassung erklärt die meisten Berichte, eine Änderung habe keine Wirkung.

Stellen Sie dann von beiden Seiten dieselbe Frage. Die Ausgabe zeigt außerdem, bei welchem Resolver die Distribution tatsächlich gelandet ist:

wsl.exe --shutdown
wsl.exe -e sh -c 'cat /etc/resolv.conf'
wsl.exe -e sh -c 'getent hosts files.corp.example'
wsl.exe -e powershell -Command 'Resolve-DnsName files.corp.example'

Der erste Befehl beendet die Umgebung, der zweite zeigt, welchen Resolver die Distribution jetzt verwendet, und die letzten beiden stellen jeder Seite dieselbe Frage. Vergleichen Sie die Antworten statt den Status der Einstellung. Eine Abfrage, die nach einem sauberen Neustart mit beiden korrekten Dateien weiterhin fehlschlägt, weist auf die Resolver-Richtlinie des Unternehmens hin, und dieses Gespräch hat einen anderen Besitzer.