WSL2 arver ikke bedrifts-VPN-en, og det er feilen

Den interne wikien lastes i Edge, mens git clone inne i distribusjonen timer ut. Den ene observasjonen leses vanligvis som «VPN-en blokkerer WSL2», og den neste timen går med til å redigere /etc/resolv.conf. Den mer nyttige lesningen er at WSL2 aldri hadde vertens nettverkssti i utgangspunktet: den kjører i en hjelpe-VM med egen adapter, egne ruter og en resolver-fil som Windows genererer for den. Alt som følger avhenger av hvilken av de tre du faktisk mangler.

VM-en har sin egen stakk, metrikker og resolver

I standard NAT-modus sitter distribusjonen bak en virtuell svitsj og når internett via verten, men ser ikke vertens adaptere. ip addr viser ett grensesnitt med en privat adresse, ip route viser en standardrute gjennom den svitsjen, og /etc/resolv.conf er en generert fil som peker på en stub-resolver Windows valgte. Ingenting av dette endres fordi en VPN-klient startet på Windows-siden.

Derfor beviser «nettleseren virker» så lite. Nettleseren bruker vertens stakk, tunnelen og vertens resolver-policy. Skallet ditt bruker en annen stakk som tilfeldigvis deler et fysisk nettverkskort. De er enige i det gode tilfellet og divergerer nøyaktig når VPN-en installerer et filter, skriver om DNS-listen eller legger til en rute for den virtuelle svitsjens subnett.

To tester avgjør hvilken verden du er i, og de må kjøres 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 navn feiler mens en bokstavelig adresse svarer, er et resolver-problem. At navn og adresser feiler sammen, er et stiproblem, og ingen mengde resolver-redigering vil berøre det. Bevis fra Windows-siden kommer deretter: Get-NetAdapter | Get-DnsClientServerAddress og route print -4 viser om tunnelen har tatt subnettet VM-en din bor i.

Myte én: bedriftens DNS-tjenere fikser det

Å redigere resolver-filen er det klassiske rådet, og det er riktig omtrent halvparten av tiden. Når det er riktig, er det riktig av en bestemt grunn: den genererte filen peker på en resolver som bare kjenner offentlige navn, så en spørring på intranet.example.internal kommer tilbake som ikke-eksisterende selv om stien er fin.

Å feste VPN-ens tjenere betyr å stoppe Windows fra å regenerere filen, fordi enhver fil du skriver for hånd erstattes ved neste start:

[network]
generateResolvConf = false

Lagre det som /etc/wsl.conf, kjør wsl --shutdown fra Windows, start deretter distribusjonen og skriv /etc/resolv.conf med tunnelens tjenere først og en offentlig resolver bare som reserve. Dette er en varig endring med vedlikeholdskostnad: filen følger ikke lenger verten, så når bedriftens DNS-adresser endres, fortsetter distribusjonen å spørre etter de gamle. Noen må eie den filen.

Det gjør heller ingenting når feilen er bredere. Hvis curl til 1.1.1.1 timer ut, filtrerer tunnelklienten den virtuelle svitsjen eller ruter VM-ens subnett inn i tunnelen, og en korrekt resolver gir deg bare navn som fortsatt ikke kan nås.

Myte to: metrikkendringen holder

Når navn løses opp, men trafikken går ut via den fysiske adapteren, er grensesnittmetrikker spaken. Gi VPN-adapteren høy kostnad og WSL-svitsjen lav:

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

Husk så at tunneladapteren i mange klientbygg gjenskapes ved hver tilkobling, og at metrikken går tilbake til standarden. En engangskommando er en reparasjon som utløper stille, vanligvis i løpet av en helg, og saken kommer tilbake med «det virket i forrige uke». En planlagt oppgave som utløses av VPN-hendelsen, eller et skript brukeren kjører etter tilkobling, er den ærlige versjonen av denne reparasjonen.

Den samme utløpsdatoen gjelder vertsruter som legges til for ett sta prefiks. De er verdt å ha som diagnostikk, fordi de forteller om problemet er én destinasjon eller hele stien, men de er ikke en arkitektur.

Myte tre: én reparasjon dekker hvert Windows-bygg

wsl-vpnkit er sidecar-mønsteret: en liten distribusjon eier stien på vertssiden og videresender for andre distribusjoner over en virtuell socket, slik at applikasjonstrafikk slutter å avhenge av den filtrerte svitsjen. Det krever at standardstien virker, altså å fjerne overstyringene networkingMode og dnsTunneling fra %UserProfile%\.wslconfig, gjenopprette generateResolvConf = true i hver fungerende distribusjon og starte tjenesten ved innlogging.

Speilmodus er det innebygde alternativet på Windows 11 22H2 og nyere, og det er én innstilling pluss en avslutning:

[wsl2]
networkingMode=mirrored

Inne i distribusjonen lister ip addr da vertens adaptere, tunnelen kan dukke opp blant dem, og DNS-tunnelering videresender oppslag gjennom Windows-resolveren selv når klienten skriver om DNS-listen. Det er ikke universelt: noen filterdrivere slipper fortsatt speilstien, og Hyper-V-brannmurregler kan trenge en eksplisitt tillatelse. Microsofts WSL-nettverksveiledning er siden du bør sjekke mot bygget ditt før du bruker en oppskrift skrevet for et nyere.

Test tre ting etter hver endring

Velg én mekanisme per maskin og skriv den ned, fordi de to kombineres dårlig. En sidecar oppå speilmodus dobler videresendingen, og en speilet vert med en utdatert sidecar-oppføring i .wslconfig har en tendens til å feile etter en oppgradering, ikke før.

Uansett hva du valgte, er aksepttesten de samme tre forespørslene inne i distribusjonen: et internt navn, et offentlig navn og en rå adresse. Gjenta dem deretter etter å ha koblet fra og til tunnelen igjen, og etter wsl --shutdown. Bare det interne navnet som feiler betyr resolver-policy; interne og offentlige navn som feiler sammen med en fungerende adresse betyr fortsatt resolver-policy; alt som feiler betyr stien.

Hvis én intern vert feiler mens resten virker, slutt å se på resolveren og se etter en manglende rute for det prefikset. Hvis alt virker til neste gjenoppkobling, har du funnet en reparasjon som avhenger av kjøretidstilstand, og den må brukes på nytt automatisk eller erstattes med en av de to mekanismene ovenfor.