WSL2 ärver inte företags-VPN:et, och det är felet

Den interna wikin laddas i Edge, medan git clone inne i distributionen får timeout. Den enda observationen läses vanligtvis som «VPN:et blockerar WSL2», och nästa timme går till att redigera /etc/resolv.conf. Den mer användbara läsningen är att WSL2 aldrig hade värdens nätverksväg från början: det kör i en hjälp-VM med egen adapter, egna rutter och en resolver-fil som Windows genererar åt det. Allt som följer beror på vilken av de tre du faktiskt saknar.

VM:en har egen stack, metrik och resolver

I standardläget NAT sitter distributionen bakom en virtuell switch och når internet via värden, men ser inte värdens adaptrar. ip addr visar ett gränssnitt med en privat adress, ip route visar en standardrutt genom den switchen, och /etc/resolv.conf är en genererad fil som pekar på en stub-resolver som Windows valde. Inget av detta ändras för att en VPN-klient startade på Windows-sidan.

Därför bevisar «webbläsaren fungerar» så lite. Webbläsaren använder värdens stack, tunneln och värdens resolver-policy. Ditt skal använder en annan stack som råkar dela ett fysiskt nätverkskort. De stämmer överens i det lyckliga fallet och divergerar exakt när VPN:et installerar ett filter, skriver om DNS-listan eller lägger till en rutt för den virtuella switchens subnät.

Två tester avgör vilken värld du är i, och de måste köras inne i distributionen:

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

Att namn misslyckas medan en bokstavlig adress svarar är ett resolver-problem. Att namn och adresser misslyckas tillsammans är ett stigproblem, och ingen mängd resolver-redigering kommer att röra det. Sedan kommer bevisen från Windows-sidan: Get-NetAdapter | Get-DnsClientServerAddress och route print -4 visar om tunneln har tagit subnätet där din VM bor.

Myt ett: företagets DNS-servrar fixar det

Att redigera resolver-filen är det klassiska rådet, och det stämmer ungefär halva tiden. När det stämmer är det av en specifik anledning: den genererade filen pekar på en resolver som bara känner till offentliga namn, så en fråga om intranet.example.internal kommer tillbaka som obefintlig även om stigen är fin.

Att fästa VPN:ets servrar innebär att stoppa Windows från att återskapa filen, eftersom varje fil du skriver för hand ersätts vid nästa start:

[network]
generateResolvConf = false

Spara det som /etc/wsl.conf, kör wsl --shutdown från Windows, starta sedan distributionen och skriv /etc/resolv.conf med tunnelns servrar först och en offentlig resolver bara som reserv. Det här är en varaktig ändring med underhållskostnad: filen följer inte längre värden, så när företagets DNS-adresser ändras fortsätter distributionen att fråga efter de gamla. Någon måste äga den filen.

Det gör inte heller någonting när felet är bredare. Om curl till 1.1.1.1 får timeout filtrerar tunnelklienten den virtuella switchen eller routar VM:ens subnät in i tunneln, och en korrekt resolver ger dig bara namn som fortfarande inte går att nå.

Myt två: metrikändringen håller

När namn löses upp men trafiken går ut via den fysiska adaptern är gränssnittsmetriken spaken. Ge VPN-adaptern hög kostnad och WSL-switchen låg:

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

Kom sedan ihåg att tunneladaptern i många klientbyggen återskapas vid varje anslutning och att metriken återgår till standard. Ett engångskommando är en reparation som tyst löper ut, oftast under en helg, och ärendet kommer tillbaka med «det fungerade förra veckan». En schemalagd uppgift som utlöses av VPN-händelsen, eller ett skript som användaren kör efter anslutning, är den ärliga versionen av den här reparationen.

Samma utgång gäller för värdrutter som läggs till för ett envisa prefix. De är värdefulla som diagnostik, eftersom de säger om problemet är en destination eller hela stigen, men de är inte arkitektur.

Myt tre: en reparation täcker varje Windows-bygge

wsl-vpnkit är sidecar-mönstret: en liten distribution äger stigen på värdsidan och vidarebefordrar för andra distributioner över en virtuell socket, så att applikationstrafik slutar bero på den filtrerade switchen. Det kräver att standardstigen fungerar, vilket innebär att ta bort överstyrningarna networkingMode och dnsTunneling från %UserProfile%\.wslconfig, återställa generateResolvConf = true i varje fungerande distribution och starta tjänsten vid inloggning.

Spegelläget är det inbyggda alternativet på Windows 11 22H2 och senare, och det är en inställning plus en avstängning:

[wsl2]
networkingMode=mirrored

Inne i distributionen listar ip addr då värdens adaptrar, tunneln kan dyka upp bland dem, och DNS-tunnling vidarebefordrar uppslag genom Windows-resolvern även när klienten skriver om DNS-listan. Det är inte universellt: vissa filterdrivrutiner släpper fortfarande spegelstigen, och Hyper-V-brandväggsregler kan behöva ett uttryckligt tillstånd. Microsofts WSL-nätverksguide är sidan du bör kontrollera mot ditt bygge innan du använder ett recept skrivet för ett nyare.

Testa tre saker efter varje ändring

Välj en mekanism per maskin och skriv ned den, eftersom de två kombineras dåligt. En sidecar ovanpå spegelläget fördubblar vidarebefordran, och en speglad värd med en inaktuell sidecar-post i .wslconfig tenderar att misslyckas efter en uppgradering, inte före.

Vad du än valde är acceptanstestet samma tre förfrågningar inne i distributionen: ett internt namn, ett offentligt namn och en rå adress. Upprepa dem sedan efter att ha kopplat från och till tunneln igen, och efter wsl --shutdown. Bara det interna namnet som misslyckas betyder resolver-policy; interna och offentliga namn som misslyckas tillsammans med en fungerande adress betyder fortfarande resolver-policy; allt som misslyckas betyder stigen.

Om en intern värd misslyckas medan resten fungerar, sluta titta på resolvern och leta efter en saknad rutt för det prefixet. Om allt fungerar till nästa återanslutning har du hittat en reparation som beror på körtidstillstånd, och den måste tillämpas igen automatiskt eller ersättas med en av de två mekanismerna ovan.