WSL2 kan ikke nå VPN-undernettet: læs værtens rute

Inde fra distributionen udløber en ping til en intern server, mens den samme adresse svarer fra Windows. VPN er forbundet, og Windows-ruten er korrekt, så hullet er WSL-grænsen. Gå vejen fra den fejlende kommando tilbage til værtens interface. Løsningen er ikke et fast CIDR i en konfigurationsfil; den er at læse den aktuelle adresse og tilføje den, hvor distributionen kan bruge den.

Bekræft, hvor vejen stopper

Kør den samme test på begge sider: slå en intern vært op, og opret forbindelse fra Windows, og gentag det derefter i distributionen. En succes i Windows plus en timeout i distributionen placerer fejlen mellem de to, ikke i VPN-klienten eller den interne server. Gør dette, før du ændrer nogen rute, så de to resultater beskriver samme destination.

Inde i distributionen viser ip -4 addr en virtuel adapter med en adresse fra WSL NAT-området, og ip route viser en standardrute, der peger på WSL-gatewayen. Der er ingen rute til det virksomhedspræfiks, fordi værtens tunneladapter ikke har nogen modpart inde i distributionen. Standardgatewayen fører til WSL NAT, ikke til virksomhedsnetværket.

At tilføje virksomhedsruten uden først at tilføje en lokal adresse på et nåbart link giver en timeout eller en network-unreachable-fejl. Adressen er den del, der gør ruten brugbar, så læs den først, og behandl ruten som andet trin.

Vælg spejlet netværk eller en scriptet rute

Spejlet netværk giver distributionen værtens egne interfaces, så tunnelen og dens ruter vises uden kopiering. Funktionen afhænger af et nyere Windows-build og af networkingMode=mirrored i .wslconfig, og aktivering ændrer uafhængig adfærd som localhost-videresendelse. Behandl det som en platformændring, ikke en rutejustering. Hvis buildet understøtter det, og bivirkningerne er acceptable, er det den korteste vej.

Den smallere tilgang beholder standard-NAT og kopierer tunneladressen og ruten ind i distributionen, hver gang tunnelen kommer op. Den virker på flere builds, ændrer ikke localhost-adfærd, og den fejler synligt, når VPN er nede. Prisen er et lille script, der skal køre ved hver forbindelse.

Vælg én, og skriv den ned. At blande en spejlet konfiguration med manuelle ruter giver en distribution med to veje til samme præfiks og ingen klar ejer af nogen af dem. Én dokumenteret metode er lettere at fejlfinde end to halvkonfigurerede.

Hent de aktuelle tunneloplysninger fra værten

Match adapteren på MAC-adresse frem for navn, fordi navne ændrer sig med VPN-klienten og tilslutningsrækkefølgen. List adapterne én gang, noter tunneladapterens MAC, og forespørg derefter dens adresse og præfiks. MAC bliver hos den virtuelle adapter gennem genforbindelser, mens navnet og interfaceindekset ikke gør:

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 interface-konfigurationen. Hent interfaceindekset først, og læs derefter næste hop. Indekset kan ændre sig efter en genstart eller en adapter-nulstilling, og derfor skal scriptet læse det i stedet for at gemme det:

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

Send output gennem tr -d '\r', før du tildeler det til en variabel. PowerShell afslutter linjer med et carriage return, og uden stripningen bærer det sidste felt et skjult tegn, der får en rutekommando til at fejle med en forvirrende parse-fejl.

Anvend adressen og ruten inde i distributionen

Installer tunneladressen som en præfikskvalificeret adresse på distributionens interface, og rut derefter virksomhedsblokken gennem værtens 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 dropper en manuelt konfigureret adresse, når forbindelsen cykler, og ingen DHCP-klient beder om en erstatning. Sæt metoden til automatisk, så hver genforbindelse opdaterer adressen, og bring derefter forbindelsen op igen. En manuel metode ser stabil ud indtil den første genforbindelse:

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

Kør begge trin fra det hook, der starter VPN, ikke fra en interaktiv shell. Et script, der læser adressen, tilføjer den, tilføjer ruten og logger værdierne, gør en tilbagevendende manuel reparation til en gentagelig, og loggen er det første, man læser, når præfikset ændrer sig.

Fastlås navnet, og bevis vejen

Kernen kan omdøbe distributionens interface mellem eth1 og eth2 efter et netværksskift, og et script skrevet mod et navn redigerer så det forkerte device. En udev-regel, der er knyttet til MAC, giver interfacet et stabilt label:

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

Bekræft derefter med adressen, ruten og en rigtig TCP-forbindelse: ip -4 addr show dev vpn, ip route get 172.20.4.10 og en forbindelse til en kendt intern port. Ruteopslaget bør navngive vpn-device og den kilde-adresse, du tilføjede.

Hvis alle tre består inde i distributionen, og forbindelsen stadig fejler, forlader pakken WSL og bliver droppet på Windows-siden. Kontroller værtens firewall og VPN-klientens egen filtrering, før du ændrer scriptet, for endnu en ruteændring retter ikke en pakke, der allerede når værten.