WSL2 når ikke VPN-undernettet: les vertens rute

Inne fra distribusjonen går en ping til en intern server ut på tid, mens samme adresse svarer fra Windows. VPN er tilkoblet og Windows-ruten er riktig, så gapet er WSL-grensen. Gå veien fra kommandoen som feilet tilbake til vertens grensesnitt. Løsningen er ikke en fast CIDR i en konfigurasjonsfil; den er å lese gjeldende adresse og legge den til der distribusjonen kan bruke den.

Bekreft hvor veien stopper

Kjør samme test på begge sider: slå opp og koble til én intern vert fra Windows, og gjenta det deretter i distribusjonen. En suksess i Windows pluss en tidsavbrudd i distribusjonen plasserer feilen mellom de to, ikke i VPN-klienten eller den interne serveren. Gjør dette før du endrer noen rute, slik at de to resultatene beskriver samme mål.

Inne i distribusjonen viser ip -4 addr en virtuell adapter med en adresse fra WSL NAT-området, og ip route viser en standardrute mot WSL-gatewayen. Det finnes ingen rute for bedriftsprefikset, fordi vertens tunneladapter ikke har noen motpart inne i distribusjonen. Standardgatewayen fører til WSL NAT, ikke til bedriftsnettet.

Å legge til bedriftsruten uten først å legge til en lokal adresse på en nåbar lenke gir en tidsavbrudd eller en network-unreachable-feil. Adressen er den delen som gjør ruten brukbar, så les den først og behandle ruten som andre trinn.

Velg speilet nettverk eller en skriptet rute

Speilet nettverk gir distribusjonen vertens egne grensesnitt, slik at tunnelen og rutene dens vises uten kopiering. Funksjonen avhenger av en nyere Windows-build og av networkingMode=mirrored i .wslconfig, og å aktivere den endrer uavhengig atferd som localhost-videresending. Behandle det som en plattformendring, ikke en rutejustering. Hvis builden støtter det og bivirkningene er akseptable, er det den korteste veien.

Den smalere tilnærmingen beholder standard-NAT og kopierer tunneladressen og ruten inn i distribusjonen hver gang tunnelen kommer opp. Den fungerer på flere builds, endrer ikke localhost-atferd, og den feiler synlig når VPN er nede. Prisen er et lite skript som må kjøres ved hver tilkobling.

Velg én og skriv den ned. Å blande en speilet konfigurasjon med manuelle ruter gir en distribusjon med to veier til samme prefiks og ingen klar eier for noen av dem. Én dokumentert metode er lettere å feilsøke enn to halvkonfigurerte.

Hent gjeldende tunneldetaljer fra verten

Match adapteren på MAC-adresse fremfor navn, fordi navn endres med VPN-klienten og tilkoblingsrekkefølgen. List adapterne én gang, noter tunneladapterens MAC, og spør deretter etter adressen og prefikset. MAC blir hos den virtuelle adapteren gjennom gjenoppkoblinger, mens navnet og grensesnittindeksen ikke gjø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 fra grensesnittkonfigurasjonen. Hent grensesnittindeksen først, og les deretter neste hopp. Indeksen kan endres etter en omstart eller en adapter-tilbakestilling, og derfor bør skriptet lese den i stedet for å lagre den:

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

Send utdata gjennom tr -d '\r' før du tildeler det til en variabel. PowerShell avslutter linjer med en carriage return, og uten strippingen bærer det siste feltet et skjult tegn som får en rutekommando til å feile med en forvirrende parse-feil.

Bruk adressen og ruten inne i distribusjonen

Installer tunneladressen som en prefikskvalifisert adresse på distribusjonens grensesnitt, og rut deretter bedriftsblokken gjennom vertens 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 slipper en manuelt konfigurert adresse når tilkoblingen sykler, og ingen DHCP-klient ber om en erstatning. Sett metoden til automatisk slik at hver gjenoppkobling oppdaterer adressen, og bring deretter tilkoblingen opp igjen. En manuell metode ser stabil ut til den første gjenoppkoblingen:

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

Kjør begge trinnene fra kroken som starter VPN, ikke fra et interaktivt skall. Et skript som leser adressen, legger den til, legger til ruten og logger verdiene, gjør en tilbakevendende manuell reparasjon til en repeterbar, og loggen er det første du leser når prefikset endres.

Fest navnet og bevis veien

Kjernen kan gi distribusjonens grensesnitt nytt navn mellom eth1 og eth2 etter et nettverksbytte, og et skript skrevet mot et navn redigerer da feil enhet. En udev-regel knyttet til MAC gir grensesnittet en stabil etikett:

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

Verifiser deretter med adressen, ruten og en ekte TCP-tilkobling: ip -4 addr show dev vpn, ip route get 172.20.4.10 og en tilkobling til en kjent intern port. Ruteoppslaget bør navngi vpn-enheten og kildeadressen du la til.

Hvis alle tre består inne i distribusjonen og tilkoblingen fortsatt feiler, forlater pakken WSL og blir droppet på Windows-siden. Kontroller vertens brannmur og VPN-klientens egen filtrering før du endrer skriptet, for enda en ruteendring retter ikke en pakke som allerede når verten.