WSL2 arvar ikkje bedrifts-VPN-en, og det er feilen

Den interne wikien lastar i Edge, medan git clone inne i distribusjonen får tidsavbrot. Den eine observasjonen vert vanlegvis lesen som «VPN-en blokkerer WSL2», og den neste timen går med til å redigere /etc/resolv.conf. Den meir nyttige lesinga er at WSL2 aldri hadde nettverksstien til verten i utgangspunktet: det køyrer i ein hjelpe-VM med eigen adapter, eigne ruter og ei resolver-fil som Windows genererer for det. Alt som følgjer, avheng av kva av dei tre du faktisk manglar.

VM-en har eigen stakk, metrikkar og resolver

I standard NAT-modus sit distribusjonen bak ein virtuell svitsj og når internett via verten, men ser ikkje adapterane til verten. ip addr viser eitt grensesnitt med ei privat adresse, ip route viser ei standardrute gjennom den svitsjen, og /etc/resolv.conf er ei generert fil som peikar på ein stub-resolver Windows valde. Ingenting av dette endrar seg fordi ein VPN-klient starta på Windows-sida.

Difor beviser «nettlesaren virkar» så lite. Nettlesaren brukar stakken til verten, tunnelen og resolver-politikken til verten. Skalet ditt brukar ein annan stakk som tilfeldigvis deler eit fysisk nettverkskort. Dei er samde i det gode tilfellet og går frå kvarandre nett når VPN-en installerer eit filter, skriv om DNS-lista eller legg til ei rute for subnettet til den virtuelle svitsjen.

To testar avgjer kva verd du er i, og dei må køyrast inne i distribusjonen:

getent hosts example.com
curl -sS -m 8 -o /dev/null -w "%{http_code}\n" 1.1.1.1
ip route
cat /etc/resolv.conf

At namn feilar medan ei bokstaveleg adresse svarar, er eit resolver-problem. At namn og adresser feilar saman, er eit stiproblem, og inga mengd resolver-redigering vil røre det. Bevis frå Windows-sida kjem deretter: Get-NetAdapter | Get-DnsClientServerAddress og route print -4 viser om tunnelen har teke subnettet VM-en din bur i.

Fyrste mistyding: bedrifts-DNS-tenarane fiksar det

Å redigere resolver-fila er det klassiske rådet, og det er rett om lag halvparten av tida. Når det er rett, er det rett av ein bestemd grunn: den genererte fila peikar på ein resolver som berre kjenner offentlege namn, så ei spørjing på intranet.example.internal kjem tilbake som ikkje-eksisterande sjølv om stien er fin.

Å feste tenarane til VPN-en betyr å stoppe Windows frå å generere fila på nytt, fordi kvar fil du skriv for hand vert erstatta ved neste start:

[network]
generateResolvConf = false

Lagre det som /etc/wsl.conf, køyr wsl --shutdown frå Windows, start deretter distribusjonen og skriv /etc/resolv.conf med tenarane til tunnelen først og ein offentleg resolver berre som reserve. Dette er ei varig endring med vedlikehaldskostnad: fila følgjer ikkje lenger verten, så når bedrifts-DNS-adressene endrar seg, fortset distribusjonen å spørje etter dei gamle. Nokon må eige den fila.

Det gjer heller ingenting når feilen er breiare. Viss curl til 1.1.1.1 får tidsavbrot, filtrerer tunnelklienten den virtuelle svitsjen eller ruter subnettet til VM-en inn i tunnelen, og ein korrekt resolver gjev deg berre namn som framleis ikkje kan nåast.

Andre mistyding: metrikkendringa held

Når namn løyser seg opp, men trafikken går ut via den fysiske adapteren, er grensesnittmetrikkar spaken. Gjev VPN-adapteren høg kostnad og WSL-svitsjen låg:

Get-NetAdapter | Where-Object InterfaceDescription -Match "AnyConnect" | Set-NetIPInterface -InterfaceMetric 4000
Get-NetIPInterface -InterfaceAlias "vEthernet (WSL)" | Set-NetIPInterface -InterfaceMetric 1

Hugs så at tunneladapteren i mange klientbygg vert gjenoppretta ved kvar tilkopling, og at metrikken går tilbake til standarden. Ein eingongskommando er ein reparasjon som går ut stille, vanlegvis i løpet av ei helg, og saka kjem tilbake med «det virka førre veke». Ei planlagd oppgåve som vert utløyst av VPN-hendinga, eller eit skript brukaren køyrer etter tilkopling, er den ærlege versjonen av denne reparasjonen.

Den same utløpsdatoen gjeld vertsruter som vert lagde til for eitt sta eit prefiks. Dei er verdifulle som diagnostikk, fordi dei fortel om problemet er ein destinasjon eller heile stien, men dei er ikkje ein arkitektur.

Tredje mistyding: éin reparasjon dekkjer kvar Windows-bygging

wsl-vpnkit er sidecar-mønsteret: ein liten distribusjon eig stien på vertssida og videresender for andre distribusjonar over ein virtuell socket, slik at applikasjonstrafikk sluttar å avhenge av den filtrerte svitsjen. Det krev at standardstien virkar, altså å fjerne overstyringane networkingMode og dnsTunneling frå %UserProfile%\.wslconfig, gjenopprette generateResolvConf = true i kvar fungerande distribusjon og starte tenesta ved innlogging.

Spegelmodus er det innebygde alternativet på Windows 11 22H2 og nyare, og det er éi innstilling pluss ei avslutting:

[wsl2]
networkingMode=mirrored

Inne i distribusjonen listar ip addr då adapterane til verten, tunnelen kan dukke opp blant dei, og DNS-tunnelering videresender oppslag gjennom Windows-resolveren sjølv når klienten skriv om DNS-lista. Det er ikkje universelt: nokre filterdrivarar slepp framleis spegelstien, og Hyper-V-brannmurreglar kan trenge ei eksplisitt løyve. Microsofts WSL-nettverksrettleiing er sida du bør sjekke mot bygget ditt før du brukar ein oppskrift skriven for eit nyare.

Test tre ting etter kvar endring

Vel éin mekanisme per maskin og skriv han ned, fordi dei to kombinerer dårleg. Ein sidecar oppå spegelmodus doblar videresendinga, og ein spegla vert med ein utdatert sidecar-oppføring i .wslconfig har ein tendens til å feile etter ei oppgradering, ikkje før.

Uansett kva du valde, er aksepttesten dei same tre førespurnadene inne i distribusjonen: eit internt namn, eit offentleg namn og ei rå adresse. Gjenta dei deretter etter å ha kopla frå og til tunnelen igjen, og etter wsl --shutdown. Berre det interne namnet som feilar betyr resolver-politikk; interne og offentlege namn som feilar saman med ei fungerande adresse betyr framleis resolver-politikk; alt som feilar betyr stien.

Viss ein intern vert feilar medan resten virkar, slutt å sjå på resolveren og leit etter ei manglande rute for det prefikset. Viss alt virkar til neste gjenoppkopling, har du funne ein reparasjon som avheng av køyretidstilstand, og han må brukast på nytt automatisk eller erstattast med ein av dei to mekanismane ovanfor.