Waarom verliest WSL de werkhostnaam wanneer de VPN verbindt?
Dezelfde naam werkt in Windows en faalt in WSL zodra de tunnel staat. Controleer de DNS-modus van het platform en de verouderde overschrijvingen voordat u een resolver toevoegt.
Windows lost de interne host zonder klagen op, en dezelfde naam faalt in WSL op het moment dat de tunnel staat. De gebruikelijke reparatie is een openbare resolver in de distributie schrijven, wat normaal browsen herstelt en de werkhostnaam onoplosbaar maakt. Dat ruilt de ene fout voor de andere en verbergt de laag die echt kapotging. Voordat u een resolverregel toevoegt of verwijdert, moet u uitzoeken welke van de drie lagen faalt.
Sluit eerst een routeringsfout uit
Vraag de identieke volledig gekwalificeerde naam aan beide kanten op, niet twee namen die op elkaar lijken. Een succes in Windows en een fout in WSL voor dezelfde tekenreeks is de signatuur van twee resolutiepaden, en weinig anders levert dat patroon zo schoon op. Als WSL de dienst ook op het bekende numerieke adres niet bereikt, is er ook een routerings- of filterprobleem. In dat geval zal DNS-werk het niet onthullen, en de middag gaat naar de verkeerde laag.
Drie symptomen dekken de meeste van deze gevallen, en elk wijst ergens anders heen. Lees de rij die past voordat u een configuratiebestand opent:
| Symptom inside WSL | Likely layer | Where to look |
|---|---|---|
| Private name fails while public browsing works | Resolver path | Tunneling mode and the Windows build |
| A name that worked yesterday fails today | Stale override | Generated resolver file, immutable flag, shell profile |
| The name resolves but the service does not | Routing or filtering | The resolved address and the path to it |
De middelste rij is degene die mensen verkeerd lezen, omdat de wijziging die hem brak weken eerder is gedaan en toen succesvol leek. De derde rij is degene die mensen verkeerd diagnosticeren, omdat een naam die oplost als bewijs voelt dat het netwerk gezond is. Beide rijen sturen u naar een andere sectie hieronder.
DNS-tunneling heeft een versieondergrens
Microsoft documenteert een WSL-netwerkmodus die DNS-verzoeken via een virtualisatiekanaal naar de Windows-resolver tunnelt. Op ondersteunde Windows 11-builds is die standaard ingeschakeld, waardoor twee machines op hetzelfde bedrijfsnetwerk zich anders gedragen. De variabele is het buildnummer, niet het bedrijfsbeleid.
De WSL-netwerkgids beschrijft die modus en de versies die hem ondersteunen. De functie is belangrijk omdat bedrijfs-DNS-beleid meestal in de Windows-resolver woont, en een distributie die het Windows-pad erft, erft het beleid mee. Een distributie die een openbare resolver vraagt, heeft geen route naar een privénaam, hoe netjes de eigen configuratie er ook uitziet. Dat mechanisme verklaart het hele symptoom, en het verklaart waarom de omweg met een openbare resolver faalt.
Lees de build voordat u iets bewerkt. Een instelling die uit een nieuwere installatie is gekopieerd, is geen bewijs dat een oudere die implementeert. Noteer het buildnummer naast de wijziging, want het verschil tussen twee machines is bijna altijd een versie en niet een beleid.
Oude overschrijvingen overleven het probleem dat ze oplosten
Oudere recepten schakelden gegenereerde resolverbestanden uit, hardcodeerden een nameserver of vergrendelden het bestand met een onveranderlijk attribuut. Die wijzigingen blijven staan lang nadat het verbindingsprobleem dat ze veroorzaakte is verdwenen, en meestal zijn ze de reden dat een nieuwere instelling niets lijkt te doen. Ze overleven ook een herinstallatie van de distributie in de vorm van een shell-profiel dat het bestand bij elke login herschrijft. De laatste is het moeilijkst te vinden, omdat hij onzichtbaar is vanuit het bestand dat iedereen inspecteert.
Zoek een handgeschreven resolverbestand, een onveranderlijk attribuut erop en een opstartscript dat het herschrijft. Controleer de onveranderlijke vlag voordat u bewerkt, want een schrijfactie naar een vergrendeld bestand faalt op een manier die als een rechtenprobleem leest. Controleer daarna het shell-profiel, want een script daar herstelt de oude inhoud binnen seconden na uw correctie.
Het verwijderen van een overschrijving heeft gevolgen, dus noteer wat u hebt verwijderd en waarom. Een distributie die echt een statische resolver nodig heeft voor een ander doel, breekt wanneer het gegenereerde bestand terugkeert.
Twee bestanden, twee verschillende rollen
De twee configuratiebestanden staan op verschillende plaatsen en regelen verschillende dingen, en ze verwarren levert bewerkingen op die op de verkeerde laag worden toegepast. Het bestand aan de Windows-kant stelt eigenschappen van de virtuele machine in, terwijl het bestand aan de distributiekant instelt hoe die distributie zijn eigen resolverconfiguratie opbouwt. Geen van beide overschrijft de ander, daarom moeten beide overeenstemmen.
Voor een installatie die de functie ondersteunt, is het fragment aan de Windows-kant kort. Het is de hele wijziging aan die kant:
[wsl2]
dnsTunneling=trueDat fragment hoort in het Windows-gebruikersprofiel en geldt voor de virtuele machine in plaats van voor één distributie. Tunneling vereist ook dat de distributie het genereren van resolvers niet heeft uitgeschakeld, dus het bestand aan de distributiekant moet dat gedrag met rust laten. Wijzig het ene zonder het andere en de modus doet stil niets, wat de meest voorkomende manier is waarop deze reparatie als kapot wordt gemeld. Controleer beide bestanden in dezelfde sessie, want twee bewerkingen weken uit elkaar zijn twee bewerkingen die niemand kan toeschrijven.
Herstart en vraag dan van beide kanten
Deze instellingen worden gelezen wanneer de omgeving start, dus een nieuwe shell in een draaiende distributie laadt ze niet opnieuw. Schakel de omgeving uit in plaats van de shell te herstarten, en sla eerst eventueel lopend werk op omdat elke distributie ermee stopt. Alleen die omissie verklaart de meeste meldingen dat een wijziging geen effect heeft.
Stel dan dezelfde vraag van beide kanten. De uitvoer laat ook zien bij welke resolver de distributie uiteindelijk is uitgekomen:
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'De eerste opdracht beëindigt de omgeving, de tweede laat zien welke resolver de distributie nu gebruikt, en de laatste twee stellen dezelfde vraag aan elke kant. Vergelijk de antwoorden en niet de status van de instelling. Een query die na een schone herstart met beide bestanden correct nog steeds faalt, wijst op het resolverbeleid van het bedrijf, en dat gesprek heeft een andere eigenaar.