WSL2 erbt das Unternehmens-VPN nicht, und genau das ist der Fehler

Das interne Wiki lädt in Edge, während git clone in der Distribution in einen Timeout läuft. Diese eine Beobachtung wird meist als «das VPN blockiert WSL2» gelesen, und die nächste Stunde geht in das Bearbeiten von /etc/resolv.conf. Die nützlichere Lesart ist, dass WSL2 den Netzwerkpfad des Hosts nie hatte: Es läuft in einer Hilfs-VM mit eigenem Adapter, eigenen Routen und einer Resolver-Datei, die Windows für sie erzeugt. Alles Weitere hängt davon ab, welches dieser drei Dinge Ihnen tatsächlich fehlt.

Die VM hat ihren eigenen Stack, eigene Metriken und einen Resolver

Im standardmäßigen NAT-Modus sitzt die Distribution hinter einem virtuellen Switch und erreicht das Internet über den Host, sieht aber dessen Adapter nicht. ip addr zeigt eine Schnittstelle mit privater Adresse, ip route zeigt eine Standardroute über diesen Switch, und /etc/resolv.conf ist eine generierte Datei, die auf einen Stub-Resolver zeigt, den Windows ausgewählt hat. Nichts davon ändert sich, weil auf der Windows-Seite ein VPN-Client gestartet ist.

Deshalb beweist «der Browser funktioniert» so wenig. Der Browser nutzt den Host-Stack, den Tunnel und die Resolver-Richtlinie des Hosts. Ihre Shell nutzt einen anderen Stack, der zufällig eine physische Netzwerkkarte teilt. Sie stimmen im guten Fall überein und weichen genau dann ab, wenn das VPN einen Filter installiert, die DNS-Liste umschreibt oder eine Route für das Subnetz des virtuellen Switches hinzufügt.

Zwei Tests entscheiden, in welcher Welt Sie sind, und sie müssen in der Distribution laufen:

getent hosts example.com
curl -sS -m 8 -o /dev/null -w "%{http_code}\n" 1.1.1.1
ip route
cat /etc/resolv.conf

Wenn Namen scheitern, während eine wörtliche Adresse antwortet, ist das ein Resolver-Problem. Wenn Namen und Adressen gemeinsam scheitern, ist das ein Pfadproblem, und keine Resolver-Bearbeitung wird es berühren. Als Nächstes kommen Belege von der Windows-Seite: Get-NetAdapter | Get-DnsClientServerAddress und route print -4 zeigen, ob der Tunnel das Subnetz beansprucht hat, in dem Ihre VM lebt.

Mythos eins: die Unternehmens-DNS-Server richten es

Das Bearbeiten der Resolver-Datei ist der klassische Rat, und er stimmt etwa die Hälfte der Zeit. Wenn er stimmt, stimmt er aus einem bestimmten Grund: Die generierte Datei zeigt auf einen Resolver, der nur öffentliche Namen kennt, sodass eine Abfrage nach intranet.example.internal als nicht existent zurückkommt, obwohl der Pfad in Ordnung ist.

Die Server des VPN festzunageln bedeutet, Windows am Neugenerieren der Datei zu hindern, denn jede von Hand geschriebene Datei wird beim nächsten Start ersetzt:

[network]
generateResolvConf = false

Speichern Sie das als /etc/wsl.conf, führen Sie wsl --shutdown unter Windows aus, starten Sie dann die Distribution und schreiben Sie /etc/resolv.conf mit den Servern des Tunnels zuerst und einem öffentlichen Resolver nur als Rückfall. Das ist eine dauerhafte Änderung mit Wartungskosten: Die Datei folgt dem Host nicht mehr, wenn sich die Unternehmens-DNS-Adressen ändern, fragt die Distribution weiter die alten. Jemand muss diese Datei besitzen.

Es hilft auch nichts, wenn der Fehler breiter ist. Wenn curl zu 1.1.1.1 in einen Timeout läuft, filtert der Tunnel-Client den virtuellen Switch oder leitet das Subnetz der VM in den Tunnel, und ein korrekter Resolver liefert Ihnen nur Namen, die weiterhin nicht erreichbar sind.

Mythos zwei: die Metrikänderung hält

Wenn Namen aufgelöst werden, der Verkehr aber über den physischen Adapter abgeht, sind Schnittstellenmetriken der Hebel. Geben Sie dem VPN-Adapter hohe Kosten und dem WSL-Switch niedrige:

Get-NetAdapter | Where-Object InterfaceDescription -Match "AnyConnect" | Set-NetIPInterface -InterfaceMetric 4000
Get-NetIPInterface -InterfaceAlias "vEthernet (WSL)" | Set-NetIPInterface -InterfaceMetric 1

Denken Sie dann daran, dass in vielen Client-Builds der Tunneladapter bei jeder Verbindung neu erstellt wird und die Metrik zu ihrem Standard zurückkehrt. Ein einmaliger Befehl ist eine Reparatur, die still abläuft, meist über ein Wochenende, und das Ticket kommt mit «letzte Woche ging es» zurück. Eine geplante Aufgabe, die vom VPN-Ereignis ausgelöst wird, oder ein Skript, das der Benutzer nach dem Verbinden ausführt, ist die ehrliche Version dieser Reparatur.

Dieselbe Ablauffrist gilt für Host-Routen, die für ein einzelnes hartnäckiges Präfix hinzugefügt wurden. Sie sind als Diagnose wertvoll, weil sie sagen, ob das Problem ein Ziel oder der ganze Pfad ist, aber sie sind keine Architektur.

Mythos drei: eine Reparatur deckt jeden Windows-Build ab

wsl-vpnkit ist das Sidecar-Muster: Eine kleine Distribution besitzt den Pfad auf der Host-Seite und leitet für andere Distributionen über einen virtuellen Socket weiter, sodass Anwendungsverkehr nicht mehr vom gefilterten Switch abhängt. Es braucht den Standardpfad, was bedeutet, die Überschreibungen networkingMode und dnsTunneling aus %UserProfile%\.wslconfig zu entfernen, generateResolvConf = true in jeder funktionierenden Distribution wiederherzustellen und den Dienst bei der Anmeldung zu starten.

Der gespiegelte Modus ist die eingebaute Alternative unter Windows 11 22H2 und neuer, und er ist eine Einstellung plus ein Herunterfahren:

[wsl2]
networkingMode=mirrored

In der Distribution listet ip addr dann die Adapter des Hosts, der Tunnel kann darunter erscheinen, und DNS-Tunneling leitet Abfragen durch den Windows-Resolver weiter, selbst wenn der Client die DNS-Liste umschreibt. Es ist nicht universell: Manche Filtertreiber verwerfen den gespiegelten Pfad weiterhin, und Hyper-V-Firewallregeln können eine ausdrückliche Freigabe erfordern. Microsofts WSL-Netzwerkanleitung ist die Seite, die Sie gegen Ihren Build prüfen sollten, bevor Sie ein Rezept anwenden, das für ein neueres geschrieben wurde.

Testen Sie nach jeder Änderung drei Dinge

Wählen Sie einen Mechanismus pro Rechner und schreiben Sie ihn auf, denn die beiden kombinieren sich schlecht. Ein Sidecar über dem gespiegelten Modus verdoppelt die Weiterleitung, und ein gespiegelter Host mit einem veralteten Sidecar-Eintrag in .wslconfig neigt dazu, nach einem Upgrade zu scheitern statt davor.

Was auch immer Sie gewählt haben, der Abnahmetest sind dieselben drei Anfragen in der Distribution: ein interner Name, ein öffentlicher Name und eine rohe Adresse. Wiederholen Sie sie dann nach dem Trennen und erneuten Verbinden des Tunnels und nach wsl --shutdown. Schlägt nur der interne Name fehl, ist es Resolver-Richtlinie; schlagen interner und öffentlicher Name zusammen bei funktionierender Adresse fehl, ist es weiterhin Resolver-Richtlinie; schlägt alles fehl, ist es der Pfad.

Wenn ein interner Host fehlschlägt, während der Rest funktioniert, hören Sie auf, den Resolver anzusehen, und suchen Sie eine fehlende Route für dieses Präfix. Wenn alles bis zur nächsten Wiederverbindung funktioniert, haben Sie eine Reparatur gefunden, die von Laufzeitzustand abhängt, und sie muss automatisch erneut angewendet oder durch einen der beiden oben genannten Mechanismen ersetzt werden.