Hvorfor mister WSL arbeidsvertens navn når VPN kobles til?

Windows løser opp den interne verten uten klager, og det samme navnet feiler inne i WSL i det øyeblikket tunnelen kommer opp. Den vanlige reparasjonen er å skrive en offentlig resolver inn i distribusjonen, noe som gjenoppretter vanlig nettlesing og gjør arbeidsvertens navn umulig å slå opp. Det bytter én feil mot en annen og skjuler laget som faktisk gikk i stykker. Før du legger til eller fjerner en resolverlinje, finn ut hvilket av de tre lagene som feiler.

Utelukk først en rutingfeil

Spør etter det identiske fullt kvalifiserte navnet på begge sider, ikke to navn som ligner. En suksess i Windows og en feil i WSL for den samme strengen er signaturen til to oppløsningsveier, og få andre ting gir det mønsteret så rent. Hvis WSL heller ikke når tjenesten på dens kjente numeriske adresse, er det også et ruting- eller filtreringsproblem. I så fall vil DNS-arbeid ikke avdekke det, og ettermiddagen går til feil lag.

Tre symptomer dekker de fleste av disse tilfellene, og hvert peker et annet sted. Les raden som passer før du åpner en konfigurasjonsfil:

Den midterste raden er den folk leser feil, fordi endringen som ødela den ble gjort uker tidligere og så vellykket ut da. Den tredje raden er den folk feildiagnostiserer, fordi et navn som løses opp føles som bevis på at nettverket er sunt. Begge radene sender deg til en annen seksjon nedenfor.

DNS-tunnelering har en versjonsgrense

Microsoft dokumenterer en WSL-nettverksmodus som tunnelerer DNS-forespørsler til Windows-resolveren gjennom en virtualiseringskanal. På støttede Windows 11-bygg er den aktivert som standard, og derfor oppfører to maskiner på samme bedriftsnettverk seg ulikt. Variabelen er byggnummeret, ikke bedriftspolicyen.

WSL-nettverksveiledningen beskriver den modusen og versjonene som støtter den. Funksjonen er viktig fordi bedriftens DNS-policy vanligvis bor i Windows-resolveren, og en distribusjon som arver Windows-banen arver policyen med den. En distribusjon som spør en offentlig resolver har ingen rute til et privat navn, uansett hvor ryddig dens egen konfigurasjon ser ut. Den mekanismen forklarer hele symptomet, og forklarer hvorfor omveien med offentlig resolver feiler.

Les byggnummeret før du redigerer noe. En innstilling kopiert fra en nyere installasjon er ikke bevis for at en eldre implementerer den. Noter byggnummeret ved siden av endringen, fordi forskjellen mellom to maskiner nesten alltid er en versjon og ikke en policy.

Gamle overstyringer overlever problemet de løste

Eldre oppskrifter deaktiverte genererte resolverfiler, hardkodet en navneserver eller låste filen med et uforanderlig attributt. Disse endringene blir stående lenge etter at tilkoblingsproblemet som utløste dem er borte, og de er vanligvis grunnen til at en nyere innstilling ser ut til å gjøre ingenting. De overlever også en reinstallasjon av distribusjonen i form av en shell-profil som skriver filen på nytt ved hver innlogging. Den siste er vanskeligst å finne, fordi den er usynlig fra filen alle inspiserer.

Se etter en håndskrevet resolverfil, et uforanderlig attributt på den og et oppstartsskript som skriver den på nytt. Sjekk det uforanderlige flagget før du redigerer, fordi en skriving til en låst fil feiler på en måte som leses som et tillatelsesproblem. Sjekk shell-profilen etterpå, fordi et skript der gjenoppretter det gamle innholdet innen sekunder etter rettelsen din.

Å fjerne en overstyring har konsekvenser, så noter hva du fjernet og hvorfor. En distribusjon som virkelig trenger en statisk resolver til et annet formål vil bryte når den genererte filen kommer tilbake.

To filer, to ulike roller

De to konfigurasjonsfilene bor på forskjellige steder og styrer forskjellige ting, og å forveksle dem gir endringer brukt på feil lag. Filen på Windows-siden setter egenskaper for den virtuelle maskinen, mens filen på distribusjonssiden setter hvordan den distribusjonen bygger sin egen resolverkonfigurasjon. Ingen av dem overstyrer den andre, og derfor må begge stemme overens.

For en installasjon som støtter funksjonen, er fragmentet på Windows-siden kort. Det er hele endringen på den siden:

[wsl2]
dnsTunneling=true

Det fragmentet hører i Windows-brukerprofilen og gjelder den virtuelle maskinen snarere enn en enkelt distribusjon. Tunnelering krever også at distribusjonen ikke har deaktivert resolvergenerering, så filen på distribusjonssiden må la denne oppførselen være. Endre det ene uten det andre, og modusen gjør stille ingenting, som er den vanligste måten denne reparasjonen rapporteres som ødelagt. Sjekk begge filene i samme økt, fordi to endringer gjort uker fra hverandre er to endringer ingen kan tilskrive.

Start på nytt, og spør så fra begge sider

Disse innstillingene leses når miljøet starter, så et nytt shell inne i en kjørende distribusjon laster dem ikke på nytt. Slå av miljøet i stedet for å starte shellen på nytt, og lagre først eventuelt arbeid som kjører, fordi hver distribusjon stopper med det. Den utelatelsen alene forklarer de fleste rapportene om at en endring ikke har effekt.

Still så det samme spørsmålet fra begge sider. Utdataene viser også hvilken resolver distribusjonen faktisk endte med:

wsl.exe --shutdown
wsl.exe -e sh -c 'cat /etc/resolv.conf'
wsl.exe -e sh -c 'getent hosts files.corp.example'
wsl.exe -e powershell -Command 'Resolve-DnsName files.corp.example'

Den første kommandoen avslutter miljøet, den andre viser hvilken resolver distribusjonen bruker nå, og de to siste stiller det samme spørsmålet til hver side. Sammenlign svarene i stedet for statusen til innstillingen. Et oppslag som fortsatt feiler etter en ren omstart med begge filene korrekte, peker på bedriftens resolverpolicy, og den samtalen har en annen eier.