WSL2 erreicht das VPN-Subnetz nicht: Lesen Sie die Host-Route

Aus der Distribution heraus läuft ein Ping zu einem internen Server in einen Timeout, während dieselbe Adresse von Windows aus antwortet. Das VPN ist verbunden und die Windows-Route ist korrekt, die Lücke ist also die WSL-Grenze. Gehen Sie den Weg vom fehlgeschlagenen Befehl zurück zur Host-Schnittstelle. Die Lösung ist kein festes CIDR in einer Konfigurationsdatei, sondern die aktuelle Adresse zu lesen und sie dort hinzuzufügen, wo die Distribution sie nutzen kann.

Bestätigen Sie, wo der Weg endet

Führen Sie denselben Test auf beiden Seiten durch: einen internen Host von Windows auflösen und verbinden, dann in der Distribution wiederholen. Ein Erfolg unter Windows plus ein Timeout in der Distribution lokalisiert den Fehler zwischen beiden, nicht im VPN-Client oder im internen Server. Tun Sie dies, bevor Sie eine Route ändern, damit beide Ergebnisse dasselbe Ziel beschreiben.

In der Distribution zeigt ip -4 addr einen virtuellen Adapter mit einer Adresse aus dem WSL-NAT-Bereich, und ip route zeigt eine Standardroute zum WSL-Gateway. Für das Unternehmenspräfix gibt es keine Route, weil der Tunneladapter des Hosts kein Gegenstück in der Distribution hat. Das Standard-Gateway führt zum WSL-NAT, nicht zum Unternehmensnetz.

Die Unternehmensroute hinzuzufügen, ohne zuerst eine lokale Adresse auf einer erreichbaren Verbindung hinzuzufügen, erzeugt einen Timeout oder einen Fehler der Art Netzwerk nicht erreichbar. Die Adresse ist der Teil, der die Route nutzbar macht, lesen Sie sie daher zuerst und behandeln Sie die Route als zweiten Schritt.

Wählen Sie gespiegeltes Netzwerk oder eine geskriptete Route

Gespiegeltes Netzwerk gibt der Distribution die Schnittstellen des Hosts selbst, sodass Tunnel und Routen ohne Kopieren erscheinen. Die Funktion hängt von einem neueren Windows-Build und von networkingMode=mirrored in .wslconfig ab, und ihr Aktivieren ändert unabhängiges Verhalten wie die localhost-Weiterleitung. Behandeln Sie es als Plattformänderung, nicht als Routenfeinjustierung. Wenn der Build es unterstützt und die Nebenwirkungen akzeptabel sind, ist es der kürzeste Weg.

Der engere Ansatz behält das Standard-NAT und kopiert Tunneladresse und Route in die Distribution, sobald der Tunnel hochkommt. Er funktioniert auf mehr Builds, ändert das localhost-Verhalten nicht und scheitert sichtbar, wenn das VPN aus ist. Der Preis ist ein kleines Skript, das bei jeder Verbindung laufen muss.

Wählen Sie eine und schreiben Sie sie auf. Eine gespiegelte Konfiguration mit manuellen Routen zu mischen, erzeugt eine Distribution mit zwei Wegen zum selben Präfix und ohne klaren Eigentümer für beide. Eine dokumentierte Methode ist leichter zu debuggen als zwei halbkonfigurierte.

Holen Sie die aktuellen Tunnelangaben vom Host

Gleichen Sie den Adapter über die MAC-Adresse ab, nicht über den Namen, denn Namen ändern sich mit dem VPN-Client und der Verbindungsreihenfolge. Listen Sie die Adapter einmal auf, notieren Sie die MAC des Tunneladapters und fragen Sie dann Adresse und Präfix ab. Die MAC bleibt bei Wiederherstellungen beim virtuellen Adapter, der Name und der Schnittstellenindex nicht:

powershell.exe 'Get-NetAdapter | Where-Object { $_.MacAddress -eq "3C-52-82-0A-1B-7C" } | Get-NetIPAddress -AddressFamily IPv4 | Select-Object IPAddress, PrefixLength'

Das Gateway stammt aus der Schnittstellenkonfiguration. Holen Sie zuerst den Schnittstellenindex und lesen Sie dann den nächsten Hop. Der Index kann sich nach einem Neustart oder einem Adapter-Reset ändern, deshalb sollte das Skript ihn lesen statt ihn zu speichern:

powershell.exe '(Get-NetAdapter | Where-Object { $_.MacAddress -eq "3C-52-82-0A-1B-7C" }).InterfaceIndex'
powershell.exe '(Get-NetIPConfiguration -InterfaceIndex 27).IPv4DefaultGateway.NextHop'

Leiten Sie die Ausgabe durch tr -d '\r', bevor Sie sie einer Variablen zuweisen. PowerShell beendet Zeilen mit einem Wagenrücklauf, und ohne das Entfernen trägt das letzte Feld ein verborgenes Zeichen, das einen Routenbefehl mit einem verwirrenden Parse-Fehler scheitern lässt.

Wenden Sie Adresse und Route in der Distribution an

Installieren Sie die Tunneladresse als präfixqualifizierte Adresse auf der Schnittstelle der Distribution und routen Sie dann den Unternehmensblock über das Gateway des Hosts:

sudo ip addr add 172.20.14.37/22 dev vpn
sudo ip route add 172.20.0.0/16 via 172.20.12.1 dev vpn

NetworkManager verwirft eine manuell konfigurierte Adresse, wenn die Verbindung neu aufgebaut wird, und kein DHCP-Client fragt nach einem Ersatz. Stellen Sie die Methode auf automatisch, damit jede Wiederverbindung die Adresse erneuert, und bringen Sie die Verbindung dann erneut hoch. Eine manuelle Methode wirkt stabil bis zur ersten Wiederverbindung:

nmcli con show vpn
sudo nmcli con mod vpn ipv4.method auto
sudo nmcli con up vpn

Führen Sie beide Schritte aus dem Hook aus, der das VPN startet, nicht aus einer interaktiven Shell. Ein Skript, das die Adresse liest, sie hinzufügt, die Route hinzufügt und die Werte protokolliert, macht eine wiederkehrende manuelle Reparatur wiederholbar, und das Protokoll ist das Erste, was man liest, wenn sich das Präfix ändert.

Fixieren Sie den Namen und beweisen Sie den Weg

Der Kernel kann die Schnittstelle der Distribution nach einem Netzwerkwechsel zwischen eth1 und eth2 umbenennen, und ein auf einen Namen geschriebenes Skript bearbeitet dann das falsche Gerät. Eine an die MAC gebundene udev-Regel gibt der Schnittstelle eine stabile Bezeichnung:

SUBSYSTEM=="net", ACTION=="add", ATTRS{address}=="3c:52:82:0a:1b:7c", NAME="vpn"

Prüfen Sie dann mit Adresse, Route und einer echten TCP-Verbindung: ip -4 addr show dev vpn, ip route get 172.20.4.10 und einer Verbindung zu einem bekannten internen Port. Die Routensuche sollte das vpn-Gerät und die von Ihnen hinzugefügte Quelladresse nennen.

Wenn alle drei in der Distribution bestehen und die Verbindung weiterhin scheitert, verlässt das Paket WSL und wird auf der Windows-Seite verworfen. Prüfen Sie die Host-Firewall und die eigene Filterung des VPN-Clients, bevor Sie das Skript ändern, denn eine weitere Routenänderung behebt kein Paket, das den Host bereits erreicht.