WSL2 når inte VPN-undernätet: läs värdens rutt

Inifrån distributionen tar en ping till en intern server timeout, medan samma adress svarar från Windows. VPN är anslutet och Windows-rutten är korrekt, så gapet är WSL-gränsen. Gå vägen från kommandot som misslyckades tillbaka till värdens gränssnitt. Lösningen är inte en fast CIDR i en konfigurationsfil; det är att läsa den aktuella adressen och lägga till den där distributionen kan använda den.

Bekräfta var vägen stannar

Kör samma test på båda sidor: slå upp och anslut till en intern värd från Windows och upprepa sedan i distributionen. En framgång i Windows plus en timeout i distributionen lokaliserar felet mellan de två, inte i VPN-klienten eller den interna servern. Gör detta innan du ändrar någon rutt, så att de två resultaten beskriver samma mål.

Inuti distributionen visar ip -4 addr en virtuell adapter med en adress från WSL NAT-området, och ip route visar en standardrutt mot WSL-gatewayen. Det finns ingen rutt för företagsprefixet, eftersom värdens tunneladapter inte har någon motsvarighet i distributionen. Standardgatewayen leder till WSL NAT, inte till företagsnätet.

Att lägga till företagsrutten utan att först lägga till en lokal adress på en nåbar länk ger en timeout eller ett nätverk otillgängligt-fel. Adressen är den del som gör rutten användbar, så läs den först och behandla rutten som det andra steget.

Välj speglat nätverk eller en skriptad rutt

Speglat nätverk ger distributionen värdens egna gränssnitt, så tunneln och dess rutter dyker upp utan kopiering. Funktionen beror på en nyare Windows-version och på networkingMode=mirrored i .wslconfig, och att aktivera den ändrar orelaterat beteende som localhost-vidarebefordran. Behandla det som en plattformsändring, inte en ruttjustering. Om versionen stöder det och bieffekterna är acceptabla är det den kortaste vägen.

Den smalare metoden behåller standard-NAT och kopierar tunnelns adress och rutt till distributionen varje gång tunneln kommer upp. Den fungerar på fler versioner, ändrar inte localhost-beteendet och misslyckas synligt när VPN är nere. Kostnaden är ett litet skript som måste köras vid varje anslutning.

Välj en och skriv ned den. Att blanda en speglad konfiguration med manuella rutter ger en distribution med två vägar till samma prefix och ingen tydlig ägare för någon av dem. En dokumenterad metod är lättare att felsöka än två halvkonfigurerade.

Hämta aktuella tunneldetaljer från värden

Matcha adaptern på MAC-adress i stället för namn, eftersom namn ändras med VPN-klienten och anslutningsordningen. Lista adaptrarna en gång, notera tunneladapterns MAC och fråga sedan efter dess adress och prefix. MAC stannar hos den virtuella adaptern mellan återanslutningar, medan namnet och gränssnittsindexet inte gör det:

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

Gatewayen kommer från gränssnittskonfigurationen. Hämta gränssnittsindexet först och läs sedan nästa hopp. Indexet kan ändras efter en omstart eller en adapteråterställning, därför bör skriptet läsa det i stället för att lagra det:

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

Skicka utdata genom tr -d '\r' innan du tilldelar det till en variabel. PowerShell avslutar rader med en carriage return, och utan strippningen bär det sista fältet ett dolt tecken som får ett ruttkommando att misslyckas med ett förvirrande tolkningsfel.

Använd adressen och rutten inuti distributionen

Installera tunneladressen som en prefixkvalificerad adress på distributionens gränssnitt och routa sedan företagsblocket genom värdens gateway:

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 slänger en manuellt konfigurerad adress när anslutningen cyklar, och ingen DHCP-klient begär en ersättning. Sätt metoden till automatisk så att varje återanslutning uppdaterar adressen och ta sedan upp anslutningen igen. En manuell metod ser stabil ut till den första återanslutningen:

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

Kör båda stegen från kroken som startar VPN, inte från ett interaktivt skal. Ett skript som läser adressen, lägger till den, lägger till rutten och loggar värdena gör en återkommande manuell reparation till en repeterbar, och loggen är det första man läser när prefixet ändras.

Fäst namnet och bevisa vägen

Kärnan kan byta namn på distributionens gränssnitt mellan eth1 och eth2 efter ett nätverksbyte, och ett skript skrivet mot ett namn redigerar då fel enhet. En udev-regel knuten till MAC ger gränssnittet en stabil etikett:

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

Verifiera sedan med adressen, rutten och en riktig TCP-anslutning: ip -4 addr show dev vpn, ip route get 172.20.4.10 och en anslutning till en känd intern port. Ruttuppslagningen bör namnge vpn-enheten och källadressen du lade till.

Om alla tre passerar inuti distributionen och anslutningen fortfarande misslyckas, lämnar paketet WSL och släpps på Windows-sidan. Kontrollera värdens brandvägg och VPN-klientens egen filtrering innan du ändrar skriptet, för ännu en ruttändring åtgärdar inte ett paket som redan når värden.