WSL2 når ikkje VPN-undernettet: les ruta til verten

Distribusjonen sit bak sin eigen NAT og ser aldri Windows-tunnelen. Les gjeldande adresse og prefiks frå verten, og legg dei deretter til i WSL.

Inne frå distribusjonen går ein ping til ein intern server ut på tid, medan same adresse svarar frå Windows. VPN er tilkopla og Windows-ruta er rett, så gapet er WSL-grensa. Gå vegen frå kommandoen som feila tilbake til grensesnittet til verten. Løysinga er ikkje ein fast CIDR i ei konfigurasjonsfil; ho er å lese gjeldande adresse og leggje henne til der distribusjonen kan bruke henne.

Stadfest kvar vegen stoggar

Køyr same test på begge sider: slå opp og kople til éin intern vert frå Windows, og gjenta det deretter i distribusjonen. Ein suksess i Windows pluss ein tidsavbrot i distribusjonen plasserer feilen mellom dei to, ikkje i VPN-klienten eller den interne serveren. Gjer dette før du endrar noka rute, slik at dei to resultata skildrar same mål.

Inne i distribusjonen viser ip -4 addr ein virtuell adapter med ei adresse frå WSL NAT-området, og ip route viser ei standardrute mot WSL-gatewayen. Det finst inga rute for bedriftsprefikset, fordi tunneladapteren til verten ikkje har nokon motpart inne i distribusjonen. Standardgatewayen fører til WSL NAT, ikkje til bedriftsnettet.

Å leggje til bedriftsruta utan først å leggje til ei lokal adresse på ei nåbar lenkje gjev eit tidsavbrot eller ein network-unreachable-feil. Adressa er den delen som gjer ruta brukbar, så les henne først og handsam ruta som andre trinn.

Vel spegla nettverk eller ei skripta rute

Spegla nettverk gjev distribusjonen grensesnitta til verten sjølv, slik at tunnelen og rutene hans viser seg utan kopiering. Funksjonen avheng av ein nyare Windows-build og av networkingMode=mirrored i .wslconfig, og å slå han på endrar uavhengig åtferd som localhost-vidaresending. Handsama det som ei plattformendring, ikkje ei rutejustering. Viss builden støttar det og biverknadene er akseptable, er det den kortaste vegen.

Den smalare tilnærminga held på standard-NAT og kopierer tunneladressa og ruta inn i distribusjonen kvar gong tunnelen kjem opp. Ho fungerer på fleire builds, endrar ikkje localhost-åtferd, og ho feilar synleg når VPN er nede. Prisen er eit lite skript som må køyrast ved kvar tilkopling.

Vel éi og skriv henne ned. Å blande ein spegla konfigurasjon med manuelle ruter gjev ein distribusjon med to vegar til same prefiks og ingen klar eigar for nokon av dei. Éin dokumentert metode er lettare å feilsøkje enn to halvkonfigurerte.

Hent gjeldande tunneldetaljar frå verten

Match adapteren på MAC-adresse framfor namn, fordi namn endrar seg med VPN-klienten og tilkoplingsrekkjefølgja. List adapterane éin gong, noter MAC-en til tunneladapteren, og spør deretter etter adressa og prefikset. MAC-en blir hjå den virtuelle adapteren gjennom gjenoppkoplingar, medan namnet og grensesnittindeksen ikkje gjer det:

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

Gatewayen kjem frå grensesnittkonfigurasjonen. Hent grensesnittindeksen først, og les deretter neste hopp. Indeksen kan endre seg etter ein omstart eller ein adapter-tilbakestilling, og difor bør skriptet lese han i staden for å lagre han:

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 ein variabel. PowerShell avsluttar linjer med ein carriage return, og utan strippinga ber det siste feltet eit skjult teikn som får ein rutekommando til å feile med ein forvirrande parse-feil.

Bruk adressa og ruta inne i distribusjonen

Installer tunneladressa som ei prefikskvalifisert adresse på grensesnittet til distribusjonen, og rut deretter bedriftsblokka gjennom gatewayen til verten:

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 slepp ei manuelt konfigurert adresse når tilkoplinga syklar, og ingen DHCP-klient ber om ei erstatning. Set metoden til automatisk slik at kvar gjenoppkopling oppdaterer adressa, og ta deretter tilkoplinga opp att. Ein manuell metode ser stabil ut til den første gjenoppkoplinga:

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

Køyr båe trinna frå kroken som startar VPN, ikkje frå eit interaktivt skal. Eit skript som les adressa, legg henne til, legg til ruta og loggar verdiane, gjer ein tilbakevendande manuell reparasjon til ein repeterbar, og loggen er det første du les når prefikset endrar seg.

Fest namnet og prov vegen

Kjernen kan gje grensesnittet til distribusjonen nytt namn mellom eth1 og eth2 etter eit nettverksbyte, og eit skript skrive mot eit namn redigerer då feil eining. Ei udev-regel knytt til MAC-en gjev grensesnittet ei stabil etikett:

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

Stadfest deretter med adressa, ruta og ei ekte TCP-tilkopling: ip -4 addr show dev vpn, ip route get 172.20.4.10 og ei tilkopling til ein kjend intern port. Ruteoppslaget bør namngje vpn-eininga og kjeldeadressa du la til.

Viss alle tre består inne i distribusjonen og tilkoplinga framleis feilar, forlèt pakken WSL og blir droppa på Windows-sida. Kontroller brannmuren til verten og filtreringa til VPN-klienten sjølv før du endrar skriptet, for endå ei ruteendring rettar ikkje ein pakke som allereie når verten.

Relaterte artiklar