Hvorfor mister WSL arbejdsværtsnavnet, når VPN’et opretter forbindelse?

Windows opløser den interne vært uden klager, og det samme navn fejler inde i WSL i det øjeblik, tunnelen kommer op. Den sædvanlige reparation er at skrive en offentlig resolver ind i distributionen, hvilket gendanner almindelig browsing og gør arbejdsværtsnavnet umuligt at opløse. Det bytter én fejl ud med en anden og skjuler det lag, der faktisk gik i stykker. Før du tilføjer eller fjerner en resolverlinje, skal du finde ud af, hvilket af de tre lag der fejler.

Udeluk først en routingfejl

Forespørg på det identiske fuldt kvalificerede navn på begge sider, ikke to navne, der ligner hinanden. En succes i Windows og en fejl i WSL for den samme streng er signaturen på to opløsningsveje, og få andre ting giver det mønster så rent. Hvis WSL heller ikke kan nå tjenesten på dens kendte numeriske adresse, er der også et routing- eller filtreringsproblem. I så fald vil DNS-arbejde ikke afsløre det, og eftermiddagen går til det forkerte lag.

Tre symptomer dækker de fleste af disse tilfælde, og hvert peger et andet sted hen. Læs den række, der passer, før du åbner en konfigurationsfil:

Den midterste række er den, folk læser forkert, fordi ændringen, der brød den, blev lavet uger tidligere og så vellykket ud dengang. Den tredje række er den, folk fejldiagnosticerer, fordi et navn, der opløses, føles som bevis på, at netværket er sundt. Begge rækker sender dig til et andet afsnit nedenfor.

DNS-tunnelering har en versionsgrænse

Microsoft dokumenterer en WSL-netværkstilstand, der tunnelerer DNS-anmodninger til Windows-resolveren gennem en virtualiseringskanal. På understøttede Windows 11-builds er den aktiveret som standard, og derfor opfører to maskiner på samme virksomhedsnetværk sig forskelligt. Variablen er build-nummeret, ikke virksomhedspolitikken.

WSL-netværksvejledningen beskriver den tilstand og de versioner, der understøtter den. Funktionen er vigtig, fordi virksomhedens DNS-politik normalt bor i Windows-resolveren, og en distribution, der arver Windows-stien, arver politikken med. En distribution, der spørger en offentlig resolver, har ingen rute til et privat navn, uanset hvor pæn dens egen konfiguration ser ud. Den mekanisme forklarer hele symptomet og forklarer, hvorfor workarounden med offentlig resolver fejler.

Læs build-nummeret, før du redigerer noget. En indstilling kopieret fra en nyere installation er ikke bevis for, at en ældre implementerer den. Notér build-nummeret ved siden af ændringen, fordi forskellen mellem to maskiner næsten altid er en version snarere end en politik.

Gamle tilsidesættelser overlever det problem, de løste

Ældre opskrifter deaktiverede genererede resolverfiler, hardkodede en navneserver eller låste filen med et immutable-attribut. De ændringer bliver på plads længe efter, at det forbindelsesproblem, der udløste dem, er forsvundet, og de er normalt grunden til, at en nyere indstilling ser ud til at gøre ingenting. De overlever også en geninstallation af distributionen i form af en shell-profil, der omskriver filen ved hver login. Den sidste er den sværeste at finde, fordi den er usynlig fra den fil, alle inspicerer.

Læg mærke til en håndskrevet resolverfil, et immutable-attribut på den og et opstartsscript, der omskriver den. Tjek immutable-flaget før redigering, fordi en skrivning til en låst fil fejler på en måde, der læses som et tilladelsesproblem. Tjek shell-profilen bagefter, fordi et script der gendanner det gamle indhold inden for sekunder efter din rettelse.

At fjerne en tilsidesættelse har konsekvenser, så notér, hvad du fjernede og hvorfor. En distribution, der virkelig har brug for en statisk resolver til et andet formål, vil gå i stykker, når den genererede fil vender tilbage.

To filer, to forskellige roller

De to konfigurationsfiler bor forskellige steder og styrer forskellige ting, og at forveksle dem giver ændringer anvendt på det forkerte lag. Filen på Windows-siden sætter egenskaber for den virtuelle maskine, mens filen på distributionssiden sætter, hvordan den distribution opbygger sin egen resolverkonfiguration. Ingen af dem tilsidesætter den anden, og derfor skal begge være enige.

For en installation, der understøtter funktionen, er fragmentet på Windows-siden kort. Det er hele ændringen på den side:

[wsl2]
dnsTunneling=true

Det fragment hører i Windows-brugerprofilen og gælder for den virtuelle maskine snarere end for en enkelt distribution. Tunnelering kræver også, at distributionen ikke har deaktiveret resolver-generering, så filen på distributionssiden skal lade den adfærd være. Ændr det ene uden det andet, og tilstanden gør stille ingenting, hvilket er den mest almindelige måde, denne reparation rapporteres som brudt. Tjek begge filer i samme session, fordi to ændringer lavet uger fra hinanden er to ændringer, ingen kan tilskrive.

Genstart, og forespørg så fra begge sider

Disse indstillinger læses, når miljøet starter, så et nyt shell inde i en kørende distribution indlæser dem ikke igen. Luk miljøet ned i stedet for at genstarte shell’et, og gem først eventuelt kørende arbejde, fordi hver distribution stopper med det. Den udeladelse alene forklarer de fleste rapporter om en ændring uden effekt.

Stil så det samme spørgsmål fra begge sider. Outputtet viser også, hvilken resolver distributionen 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 kommando afslutter miljøet, den anden viser, hvilken resolver distributionen nu bruger, og de sidste to stiller det samme spørgsmål til hver side. Sammenlign svarene i stedet for indstillingens status. En forespørgsel, der stadig fejler efter en ren genstart med begge filer korrekte, peger på virksomhedens resolverpolitik, og den samtale har en anden ejer.