Waarom verloor WSL die werkhostnaam wanneer die VPN verbind?

Windows los die interne gasheer sonder klag op, en dieselfde naam misluk binne WSL sodra die tonnel opkom. Die gewone regstelling is om 'n publieke oplosser in die distribusie te skryf, wat gewone blaai herstel en die werkhostnaam onopgelosbaar maak. Dit ruil een fout vir 'n ander, en dit verberg die laag wat werklik gebreek het. Voordat jy enige oplosser-reel byvoeg of verwyder, bepaal watter van die drie lae faal.

Sluit eers 'n routeringsfout uit

Vra dieselfde volledig gekwalifiseerde naam aan beide kante, nie twee name wat soos mekaar lyk nie. 'n Windows-sukses en 'n WSL-mislukking vir dieselfde string is die kenmerk van twee resolusiepaaie, en min anders lewer daardie patroon so skoon. As WSL ook nie die diens by sy bekende numeriese adres kan bereik nie, is daar ook 'n routerings- of filterprobleem. In daardie geval sal DNS-werk dit nie openbaar nie, en die middag gaan na die verkeerde laag.

Drie simptome dek die meeste van hierdie gevalle, en elkeen wys êrens anders heen. Lees die ry wat pas voordat jy 'n konfigurasielêer oopmaak:

Die middelste ry is die een wat mense verkeerd lees, want die verandering wat dit gebreek het, is weke vroeër gemaak en het toe suksesvol gelyk. Die derde ry is die een wat mense verkeerd diagnostiseer, want 'n naam wat oplos voel soos bewys dat die netwerk gesond is. Albei rye stuur jou na 'n ander afdeling hieronder.

DNS-tonnelering het 'n weergawe-ondergrens

Microsoft dokumenteer 'n WSL-netwerkmodus wat DNS-versoeke deur 'n virtualiseringskanaal na die Windows-oplosser tonnel. Op ondersteunde Windows 11-bouwe is dit by verstek geaktiveer, en daarom gedra twee masjiene op dieselfde korporatiewe netwerk hulle anders. Die bou-nommer is die veranderlike, nie die korporatiewe beleid nie.

Die WSL-netwerkgids beskryf daardie modus en die weergawes wat dit ondersteun. Die kenmerk maak saak omdat korporatiewe DNS-beleid gewoonlik in die Windows-oplosser woon, en 'n distribusie wat die Windows-pad erf, erf die beleid saam. 'n Distribusie wat 'n publieke oplosser vra, het geen roete na 'n private naam nie, hoe netjies sy eie konfigurasie ook al lyk. Daardie meganisme verduidelik die hele simptoom, en dit verduidelik waarom die publieke-oplosser-omweg faal.

Lees die bou-nommer voordat jy enigiets wysig. 'n Instelling wat van 'n nuwer installasie gekopieer is, is nie bewys dat 'n ouer een dit implementeer nie. Teken die bou-nommer langs die verandering aan, want die verskil tussen twee masjiene is byna altyd 'n weergawe eerder as 'n beleid.

Ou oorheersings oorleef die probleem wat hulle opgelos het

Ouer resepte het gegenereerde oplosser-lêers gedeaktiveer, 'n naambediener hardgekodeer, of die lêer met 'n onveranderlike kenmerk gesluit. Daardie veranderinge bly in plek lank nadat die verbindingsprobleem wat hulle veroorsaak het verdwyn het, en hulle is gewoonlik die rede waarom 'n nuwer instelling niks blyk te doen nie. Hulle oorleef ook 'n herinstallasie van die distribusie in die vorm van 'n shell-profiel wat die lêer by elke aanmelding herskryf. Daardie laaste een is die moeilikste om te vind, want dit is onsigbaar vanuit die lêer wat almal inspekteer.

Soek 'n handgeskrewe oplosser-lêer, 'n onveranderlike kenmerk daarop, en 'n opstartskrip wat dit herskryf. Kontroleer die onveranderlike vlag voor jy wysig, want 'n skryf na 'n geslote lêer misluk op 'n manier wat soos 'n toestemmingsprobleem lees. Kontroleer die shell-profiel daarna, want 'n skrip daar herstel die ou inhoud binne sekondes na jou regstelling.

Die verwydering van 'n oorheersing het gevolge, so teken aan wat jy verwyder het en waarom. 'n Distribusie wat werklik 'n statiese oplosser vir 'n ander doel nodig het, sal breek wanneer die gegenereerde lêer terugkeer.

Twee lêers, twee verskillende rolle

Die twee konfigurasielêers woon op verskillende plekke en beheer verskillende dinge, en om hulle te verwar lei tot wysigings wat op die verkeerde laag toegepas word. Die lêer aan die Windows-kant stel eienskappe van die virtuele masjien in, terwyl die lêer aan die distribusiekant instel hoe daardie distribusie sy eie oplosser-konfigurasie bou. Nie een oorheers die ander nie, en daarom moet albei saamstem.

Vir 'n installasie wat die kenmerk ondersteun, is die fragment aan die Windows-kant kort. Dit is die hele verandering aan daardie kant:

[wsl2]
dnsTunneling=true

Daardie fragment hoort in die Windows-gebruikersprofiel en geld vir die virtuele masjien eerder as vir 'n enkele distribusie. Tonnelering vereis ook dat die distribusie nie oplosser-generering gedeaktiveer het nie, so die lêer aan die distribusiekant moet daardie gedrag alleen laat. Verander een sonder die ander en die modus doen stilweg niks, wat die mees algemene manier is waarop hierdie regstelling as gebreek gerapporteer word. Kontroleer albei lêers in dieselfde sessie, want twee wysigings wat weke uitmekaar gemaak is, is twee wysigings wat niemand kan toeskryf nie.

Herbegin, en vra dan van beide kante

Hierdie instellings word gelees wanneer die omgewing begin, so 'n nuwe shell binne 'n lopende distribusie sal hulle nie herlaai nie. Skakel die omgewing af eerder as om die shell te herbegin, en stoor eers enige lopende werk want elke distribusie stop saam daarmee. Daardie weglating alleen verduidelik die meeste verslae van 'n verandering wat geen effek het nie.

Vra dan dieselfde vraag van beide kante. Die uitvoer wys ook watter oplosser die distribusie werklik gekry het:

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'

Die eerste opdrag beëindig die omgewing, die tweede wys watter oplosser die distribusie nou gebruik, en die laaste twee stel dieselfde vraag aan elke kant. Vergelyk die antwoorde eerder as die status van die instelling. 'n Vraag wat steeds misluk ná 'n skoon herbegin met albei lêers korrek, wys na die korporatiewe oplosser-beleid, en daardie gesprek het 'n ander eienaar.