Kvifor mistar WSL namnet på arbeidsverten når VPN koplar til?

Windows løyser opp den interne verten utan klager, og det same namnet feilar inne i WSL i det augeblikket tunnelen kjem opp. Den vanlege reparasjonen er å skrive ein offentleg resolver inn i distribusjonen, noko som gjenopprettar vanleg nettlesing og gjer namnet på arbeidsverten umogleg å slå opp. Det byter éin feil mot ein annan og skjuler laget som faktisk gjekk i stykke. Før du legg til eller fjernar ei resolverlinje, finn ut kva av dei tre laga som feilar.

Utelukk først ein rutefeil

Spør etter det identiske fullt kvalifiserte namnet på begge sider, ikkje to namn som liknar. Ein suksess i Windows og ein feil i WSL for den same strengen er signaturen til to oppløysingsvegar, og få andre ting gir det mønsteret så reint. Viss WSL heller ikkje når tenesta på den kjende numeriske adressa hennar, er det også eit ruting- eller filtreringsproblem. I så fall vil DNS-arbeid ikkje avdekkje det, og ettermiddagen går til feil lag.

Tre symptom dekkjer dei fleste av desse tilfella, og kvart peikar ein annan stad. Les rada som passar før du opnar ei konfigurasjonsfil:

Den midtre rada er den folk les feil, fordi endringa som øydela henne vart gjord veker tidlegare og såg vellukka ut då. Den tredje rada er den folk feildiagnostiserer, fordi eit namn som blir løyst opp kjennest som prov på at nettet er sunt. Begge radene sender deg til ein annan seksjon nedanfor.

DNS-tunnelering har ei versjonsgrense

Microsoft dokumenterer ein WSL-nettverksmodus som tunnelerer DNS-førespurnader til Windows-resolveren gjennom ein virtualiseringskanal. På støtta Windows 11-bygg er han slått på som standard, og difor oppfører to maskiner på same bedriftsnett seg ulikt. Variabelen er byggnummeret, ikkje bedriftspolitikken.

WSL-nettverksrettleiinga skildrar den modusen og versjonane som støttar han. Funksjonen er viktig fordi bedriftas DNS-politikk vanlegvis bur i Windows-resolveren, og ein distribusjon som arvar Windows-banen arvar politikken med han. Ein distribusjon som spør ein offentleg resolver har ingen rute til eit privat namn, uansett kor ryddig den eigne konfigurasjonen ser ut. Den mekanismen forklarar heile symptomet, og forklarar kvifor omvegen med offentleg resolver feilar.

Les bygget før du redigerer noko. Ei innstilling kopiert frå ein nyare installasjon er ikkje prov på at ein eldre implementerer henne. Noter byggnummeret ved sida av endringa, fordi skilnaden mellom to maskiner nesten alltid er ein versjon og ikkje ein politikk.

Gamle overstyringar overlever problemet dei løyste

Eldre oppskrifter deaktiverte genererte resolverfiler, hardkoda ein namneserver eller låste fila med eit uforanderleg attributt. Desse endringane blir ståande lenge etter at tilkoplingsproblemet som utløyste dei er borte, og dei er vanlegvis grunnen til at ei nyare innstilling ser ut til å gjere ingenting. Dei overlever også ein reinstallasjon av distribusjonen i form av ein shell-profil som skriv fila på nytt ved kvar innlogging. Den siste er vanskelegast å finne, fordi han er usynleg frå fila alle inspiserer.

Sjå etter ei handskriven resolverfil, eit uforanderleg attributt på henne og eit oppstartsskript som skriv henne på nytt. Sjekk det uforanderlege flagget før du redigerer, fordi ei skriving til ei låst fil feilar på ein måte som blir lesen som eit løyveproblem. Sjekk shell-profilen etterpå, fordi eit skript der gjenopprettar det gamle innhaldet innan sekund etter rettinga di.

Å fjerne ei overstyring har konsekvensar, så noter kva du fjerna og kvifor. Ein distribusjon som verkeleg treng ein statisk resolver til eit anna føremål vil bryte når den genererte fila kjem tilbake.

To filer, to ulike roller

Dei to konfigurasjonsfilene bur på ulike stader og styrer ulike ting, og å forveksle dei gir endringar brukte på feil lag. Fila på Windows-sida set eigenskapar for den virtuelle maskina, medan fila på distribusjonssida set korleis den distribusjonen byggjer sin eigen resolverkonfigurasjon. Ingen av dei overstyrer den andre, og difor må begge stemme overeins.

For ein installasjon som støttar funksjonen, er fragmentet på Windows-sida kort. Det er heile endringa på den sida:

[wsl2]
dnsTunneling=true

Det fragmentet høyrer i Windows-brukarprofilen og gjeld den virtuelle maskina snarare enn ein enkelt distribusjon. Tunnelering krev også at distribusjonen ikkje har deaktivert resolvergenerering, så fila på distribusjonssida må la denne åtferda vere. Endre det eine utan det andre, og modusen gjer stille ingenting, som er den vanlegaste måten denne reparasjonen blir rapportert som øydelagd. Sjekk begge filene i same økt, fordi to endringar gjorde veker frå kvarandre er to endringar ingen kan tilskrive.

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

Desse innstillingane blir lesne når miljøet startar, så eit nytt shell inne i ein køyrande distribusjon lastar dei ikkje på nytt. Slå av miljøet i staden for å starte shellen på nytt, og lagre først eventuelt arbeid som køyrer, fordi kvar distribusjon stoppar med det. Den utelatinga åleine forklarar dei fleste rapportane om at ei endring ikkje har effekt.

Still så det same spørsmålet frå begge sider. Utdataa viser også kva resolver distribusjonen faktisk enda 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 avsluttar miljøet, den andre viser kva resolver distribusjonen brukar no, og dei to siste stiller det same spørsmålet til kvar side. Samanlikn svara i staden for statusen til innstillinga. Eit oppslag som framleis feilar etter ein rein omstart med begge filene korrekte, peikar på bedriftas resolverpolitikk, og den samtalen har ein annan eigar.