Varför tappar WSL arbetsvärdens namn när VPN ansluter?

Windows löser den interna värden utan klagomål, och samma namn misslyckas inne i WSL i samma ögonblick som tunneln kommer upp. Den vanliga reparationen är att skriva en offentlig resolver i distributionen, vilket återställer vanlig surfning och gör arbetsvärdens namn omöjligt att slå upp. Det byter ett fel mot ett annat och döljer det lager som faktiskt gick sönder. Innan du lägger till eller tar bort en resolverrad, ta reda på vilket av de tre lagren som misslyckas.

Uteslut först ett routingfel

Fråga efter samma fullständigt kvalificerade namn på båda sidor, inte två namn som liknar varandra. En framgång i Windows och ett misslyckande i WSL för samma sträng är signaturen för två upplösningsvägar, och få andra saker ger det mönstret så rent. Om WSL inte heller når tjänsten på dess kända numeriska adress finns också ett routing- eller filtreringsproblem. I så fall avslöjar DNS-arbetet det inte, och eftermiddagen går till fel lager.

Tre symtom täcker de flesta av dessa fall, och varje pekar någon annanstans. Läs raden som passar innan du öppnar en konfigurationsfil:

Den mellersta raden är den folk läser fel, eftersom ändringen som bröt den gjordes veckor tidigare och verkade lyckad då. Den tredje raden är den folk feldiagnostiserar, eftersom ett namn som löses upp känns som bevis på att nätet är friskt. Båda raderna skickar dig till ett annat avsnitt nedan.

DNS-tunnel har ett versionsgolv

Microsoft dokumenterar ett WSL-nätverksläge som tunnlar DNS-förfrågningar till Windows-resolvern genom en virtualiseringskanal. På byggen av Windows 11 som stöds är det aktiverat som standard, och därför beter sig två maskiner i samma företagsnät olika. Variabeln är byggnumret, inte företagspolicyn.

WSL:s nätverksguide beskriver det läget och de versioner som stöder det. Funktionen spelar roll eftersom företagets DNS-policy oftast bor i Windows-resolvern, och en distribution som ärver Windows-vägen ärver policyn med den. En distribution som frågar en offentlig resolver har ingen väg till ett privat namn, hur prydlig dess egen konfiguration än ser ut. Den mekanismen förklarar hela symtomet, och den förklarar varför omvägen med offentlig resolver misslyckas.

Läs bygget innan du ändrar något. En inställning kopierad från en nyare installation är inte bevis för att en äldre implementerar den. Anteckna byggnumret bredvid ändringen, eftersom skillnaden mellan två maskiner nästan alltid är en version och inte en policy.

Gamla överstyrningar överlever problemet de löste

Äldre recept inaktiverade genererade resolverfiler, hårdkodade en namnserver eller låste filen med ett oföränderligt attribut. Dessa ändringar ligger kvar långt efter att anslutningsproblemet som utlöste dem är borta, och de är oftast anledningen till att en nyare inställning verkar göra ingenting. De överlever också en ominstallation av distributionen i form av en shell-profil som skriver om filen vid varje inloggning. Den sista är svårast att hitta, eftersom den är osynlig från filen som alla inspekterar.

Leta efter en handskriven resolverfil, ett oföränderligt attribut på den och ett startskript som skriver om den. Kontrollera den oföränderliga flaggan innan du redigerar, eftersom en skrivning till en låst fil misslyckas på ett sätt som läses som ett behörighetsproblem. Kontrollera sedan shell-profilen, eftersom ett skript där återställer det gamla innehållet inom sekunder efter din rättelse.

Att ta bort en överstyrning har konsekvenser, så anteckna vad du tog bort och varför. En distribution som verkligen behöver en statisk resolver för ett annat syfte går sönder när den genererade filen kommer tillbaka.

Två filer, två olika roller

De två konfigurationsfilerna bor på olika ställen och styr olika saker, och att blanda ihop dem ger ändringar som tillämpas på fel lager. Filen på Windows-sidan ställer in egenskaper för den virtuella maskinen, medan filen på distributionssidan ställer in hur den distributionen bygger sin egen resolverkonfiguration. Ingen av dem skriver över den andra, därför måste båda stämma.

För en installation som stöder funktionen är fragmentet på Windows-sidan kort. Det är hela ändringen på den sidan:

[wsl2]
dnsTunneling=true

Det fragmentet hör hemma i Windows-användarprofilen och gäller den virtuella maskinen snarare än en enskild distribution. Tunnling kräver också att distributionen inte har inaktiverat resolvergenerering, så filen på distributionssidan måste låta det beteendet vara. Ändra det ena utan det andra och läget gör stilla ingenting, vilket är det vanligaste sättet som den här reparationen rapporteras som trasig. Kontrollera båda filerna i samma session, eftersom två ändringar gjorda veckor isär är två ändringar som ingen kan tillskriva.

Starta om och fråga sedan från båda sidor

Dessa inställningar läses när miljön startar, så ett nytt shell inne i en körande distribution laddar inte om dem. Stäng av miljön i stället för att starta om skalet, och spara först eventuellt arbete som körs eftersom varje distribution stoppas med det. Den utelämningen ensam förklarar de flesta rapporterna om att en ändring inte har effekt.

Ställ sedan samma fråga från båda sidor. Utdata visar också vilken resolver distributionen faktiskt hamnade på:

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'

Det första kommandot avslutar miljön, det andra visar vilken resolver distributionen använder nu, och de två sista ställer samma fråga till varje sida. Jämför svaren och inte inställningens status. En fråga som fortfarande misslyckas efter en ren omstart med båda filerna korrekta pekar på företagets resolverpolicy, och det samtalet har en annan ägare.