WSL2 bereikt het VPN-subnet niet: lees de route van de host

Vanuit de distributie loopt een ping naar een interne server vast, terwijl hetzelfde adres vanuit Windows antwoordt. De VPN is verbonden en de Windows-route is correct, dus de kloof is de WSL-grens. Loop het pad van de mislukte opdracht terug naar de hostinterface. De oplossing is geen vast CIDR in een configuratiebestand; het is het huidige adres lezen en het toevoegen waar de distributie het kan gebruiken.

Bevestig waar het pad stopt

Voer dezelfde test aan beide kanten uit: los één interne host op en verbind ermee vanuit Windows, en herhaal dat in de distributie. Een succes in Windows plus een time-out in de distributie lokaliseert de fout tussen beide, niet in de VPN-client of de interne server. Doe dit voordat u een route wijzigt, zodat de twee resultaten dezelfde bestemming beschrijven.

In de distributie toont ip -4 addr een virtuele adapter met een adres uit het WSL NAT-bereik, en ip route toont een standaardroute naar de WSL-gateway. Er is geen route voor het bedrijfsprefix, omdat de tunneladapter van de host geen tegenhanger in de distributie heeft. De standaardgateway leidt naar de WSL NAT, niet naar het bedrijfsnetwerk.

De bedrijfsroute toevoegen zonder eerst een lokaal adres op een bereikbare verbinding toe te voegen, levert een time-out of een fout netwerk onbereikbaar op. Het adres is het deel dat de route bruikbaar maakt, dus lees het eerst en behandel de route als tweede stap.

Kies gespiegeld netwerk of een gescripte route

Gespiegeld netwerk geeft de distributie de eigen interfaces van de host, zodat de tunnel en zijn routes verschijnen zonder kopiëren. De functie is afhankelijk van een recente Windows-build en van networkingMode=mirrored in .wslconfig, en het inschakelen ervan verandert ongerelateerd gedrag zoals localhost-doorsturen. Behandel het als een platformwijziging, niet als een route-aanpassing. Als de build het ondersteunt en de bijwerkingen acceptabel zijn, is het de kortste weg.

De smallere aanpak behoudt de standaard-NAT en kopieert het tunneladres en de route naar de distributie telkens wanneer de tunnel omhoog komt. Het werkt op meer builds, verandert het localhost-gedrag niet en faalt zichtbaar wanneer de VPN uit staat. De prijs is een klein script dat bij elke verbinding moet draaien.

Kies er één en schrijf het op. Een gespiegelde configuratie met handmatige routes mengen levert een distributie op met twee paden naar hetzelfde prefix en geen duidelijke eigenaar voor beide. Eén gedocumenteerde methode is makkelijker te debuggen dan twee half geconfigureerde.

Haal de huidige tunneldetails van de host

Koppel de adapter aan de MAC in plaats van de naam, want namen veranderen met de VPN-client en de verbindingsvolgorde. Lijst de adapters één keer op, noteer de MAC van de tunneladapter en vraag dan het adres en prefix op. De MAC blijft bij de virtuele adapter over herverbindingen, de naam en de interface-index niet:

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

De gateway komt uit de interfaceconfiguratie. Haal eerst de interface-index op en lees dan de volgende hop. De index kan veranderen na een herstart of een adapter-reset, daarom moet het script hem lezen in plaats van opslaan:

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

Leid de uitvoer door tr -d '\r' voordat u hem aan een variabele toewijst. PowerShell beëindigt regels met een carriage return, en zonder het strippen draagt het laatste veld een verborgen teken dat een routecommando laat mislukken met een verwarrende parse-fout.

Pas het adres en de route toe in de distributie

Installeer het tunneladres als een prefixgekwalificeerd adres op de interface van de distributie en routeer vervolgens het bedrijfsblok via de gateway van de host:

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 gooit een handmatig geconfigureerd adres weg wanneer de verbinding opnieuw cyclust, en geen enkele DHCP-client vraagt om een vervanging. Zet de methode op automatisch zodat elke herverbinding het adres ververst, en breng de verbinding daarna weer omhoog. Een handmatige methode lijkt stabiel tot de eerste herverbinding:

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

Voer beide stappen uit vanuit de hook die de VPN start, niet vanuit een interactieve shell. Een script dat het adres leest, toevoegt, de route toevoegt en de waarden logt, maakt een terugkerende handmatige reparatie herhaalbaar, en de log is het eerste dat u leest wanneer het prefix verandert.

Zet de naam vast en bewijs het pad

De kernel kan de interface van de distributie na een netwerkwissel hernoemen tussen eth1 en eth2, en een script dat op een naam is geschreven bewerkt dan het verkeerde apparaat. Een udev-regel gekoppeld aan de MAC geeft de interface een stabiel label:

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

Verifieer daarna met het adres, de route en een echte TCP-verbinding: ip -4 addr show dev vpn, ip route get 172.20.4.10 en een verbinding naar een bekende interne poort. De route-opzoeking zou het vpn-apparaat en het bronadres dat u hebt toegevoegd moeten noemen.

Als alle drie binnen de distributie slagen en de verbinding nog steeds mislukt, verlaat het pakket WSL en wordt het aan de Windows-kant weggegooid. Controleer de host-firewall en de eigen filtering van de VPN-client voordat u het script wijzigt, want nog een routebewerking lost een pakket dat de host al bereikt niet op.