WSL2 arver ikke den virksomheds-VPN, og det er fejlen

Den interne wiki indlæses i Edge, mens git clone inde i distributionen timer ud. Den ene iagttagelse læses normalt som «VPN'en blokerer WSL2», og den næste time går med at redigere /etc/resolv.conf. Den mere nyttige læsning er, at WSL2 aldrig havde værtens netværkssti til at begynde med: den kører i en hjælpe-VM med sin egen adapter, sine egne ruter og en resolver-fil, som Windows genererer til den. Alt det følgende afhænger af, hvilken af de tre du faktisk mangler.

VM'en har sin egen stak, metrik og resolver

I standard NAT-tilstand sidder distributionen bag en virtuel switch og når internettet gennem værten, men den ser ikke værtens adaptere. ip addr viser ét interface med en privat adresse, ip route viser en standardrute gennem den switch, og /etc/resolv.conf er en genereret fil, der peger på en stub-resolver, som Windows valgte. Intet af det ændrer sig, fordi en VPN-klient startede på Windows-siden.

Derfor beviser «browseren virker» så lidt. Browseren bruger værtens stak, tunnelen og værtens resolver-politik. Din shell bruger en anden stak, som tilfældigvis deler et fysisk netkort. De er enige i det gode tilfælde og divergerer præcis, når VPN'en installerer et filter, omskriver DNS-listen eller tilføjer en rute til den virtuelle switchs subnet.

To tests afgør, hvilken verden du er i, og de skal køre inde 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

At navne fejler, mens en bogstavelig adresse svarer, er et resolver-problem. At navne og adresser fejler sammen, er et stifproblem, og ingen mængde resolver-redigering rører ved det. Beviser fra Windows-siden kommer derefter: Get-NetAdapter | Get-DnsClientServerAddress og route print -4 viser, om tunnelen har overtaget det subnet, din VM bor i.

Myte et: virksomhedens DNS-servere løser det

At redigere resolver-filen er det klassiske råd, og det er rigtigt cirka halvdelen af tiden. Når det er rigtigt, er det rigtigt af en bestemt grund: den genererede fil peger på en resolver, der kun kender offentlige navne, så en forespørgsel på intranet.example.internal kommer tilbage som ikke-eksisterende, selv om stien er fin.

At fastgøre VPN'ens servere betyder at stoppe Windows i at genskabe filen, fordi enhver fil, du skriver i hånden, erstattes ved næste start:

[network]
generateResolvConf = false

Gem det som /etc/wsl.conf, kør wsl --shutdown fra Windows, start derefter distributionen og skriv /etc/resolv.conf med tunnelens servere først og en offentlig resolver kun som reserve. Det er en varig ændring med en vedligeholdelsesomkostning: filen følger ikke længere værten, så når de virksomheds-DNS-adresser ændrer sig, bliver distributionen ved med at spørge de gamle. Nogen skal eje den fil.

Det gør heller intet, når fejlen er bredere. Hvis curl til 1.1.1.1 timer ud, filtrerer tunnelklienten den virtuelle switch eller ruter VM'ens subnet ind i tunnelen, og en korrekt resolver giver dig bare navne, der stadig ikke kan nås.

Myte to: metrikændringen holder

Når navne opløses, men trafikken forlader via den fysiske adapter, er interface-metrikker håndtaget. Giv VPN-adapteren en høj pris og WSL-switchen en 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 klientbuilds genskabes ved hver forbindelse, og metrikken vender tilbage til sin standard. En engangskommando er en rettelse, der udløber stille, som regel i løbet af en weekend, og sagen kommer tilbage med «det virkede i sidste uge». En planlagt opgave, der udløses af VPN-hændelsen, eller et script, brugeren kører efter forbindelse, er den ærlige version af denne reparation.

Den samme udløb gælder for værtsruter tilføjet for et enkelt stædigt præfiks. De er værd at have som diagnostik, fordi de fortæller, om problemet er én destination eller hele stien, men de er ikke en arkitektur.

Myte tre: én rettelse dækker hvert Windows-build

wsl-vpnkit er sidecar-mønstret: en lille distribution ejer stien på værtsiden og videresender for andre distributioner over en virtuel socket, så applikationstrafik holder op med at afhænge af den filtrerede switch. Det kræver, at standardstien virker, hvilket betyder at fjerne tilsidesættelserne networkingMode og dnsTunneling fra %UserProfile%\.wslconfig, gendanne generateResolvConf = true i hver fungerende distribution og starte tjenesten ved login.

Spejltilstand er det indbyggede alternativ på Windows 11 22H2 og nyere, og det er én indstilling plus en nedlukning:

[wsl2]
networkingMode=mirrored

Inde i distributionen viser ip addr derefter værtens adaptere, tunnelen kan optræde blandt dem, og DNS-tunnelering videresender opslag gennem Windows-resolveren, selv når klienten omskriver DNS-listen. Det er ikke universelt: nogle filterdrivere dropper stadig spejlstien, og Hyper-V-firewallregler kan kræve en eksplicit tilladelse. Microsofts WSL-netværksguide er den side, du skal tjekke mod dit build, før du anvender en opskrift skrevet til et nyere.

Test tre ting efter hver ændring

Vælg én mekanisme pr. maskine, og skriv den ned, fordi de to kombineres dårligt. En sidecar oven på spejltilstand fordobler videresendelsen, og en spejlet vært med en forældet sidecar-post i .wslconfig har tendens til at fejle efter en opgradering, ikke før.

Uanset hvad du valgte, er accepttesten de samme tre forespørgsler inde i distributionen: et internt navn, et offentligt navn og en rå adresse. Gentag dem derefter efter at have afbrudt og genoprettet tunnelen og efter wsl --shutdown. Kun det interne navn, der fejler, betyder resolver-politik; interne og offentlige navne, der fejler sammen med en fungerende adresse, betyder stadig resolver-politik; alt, der fejler, betyder stien.

Hvis én intern vært fejler, mens resten virker, skal du stoppe med at kigge på resolveren og lede efter en manglende rute til det præfiks. Hvis alt virker indtil næste genforbindelse, har du fundet en rettelse, der afhænger af runtime-tilstand, og den skal anvendes automatisk igen eller erstattes med en af de to mekanismer ovenfor.