Zakaj WSL izgubi ime delovnega gostitelja, ko se poveže VPN?

Windows razreši notranjega gostitelja brez vsake pritožbe, isto ime pa znotraj WSL ne uspe v trenutku, ko se tunel dvigne. Običajno popravilo je v distribucijo zapisati javni resolver, kar obnovi običajno brskanje in naredi ime delovnega gostitelja nerazrešljivo. To zamenja eno napako z drugo in skrije plast, ki se je v resnici zlomila. Preden dodate ali odstranite katero koli vrstico resolverja, ugotovite, katera od treh plasti ne uspe.

Najprej izključite napako usmerjanja

Povprašajte po istem popolnoma kvalificiranem imenu na obeh straneh, ne po dveh podobnih imenih. Uspeh v Windows in neuspeh v WSL za isto niz je podpis dveh poti razreševanja, in malo česa drugega ustvari ta vzorec tako čisto. Če WSL ne doseže storitve niti na njenem znanem številčnem naslovu, je prisotna tudi težava z usmerjanjem ali filtriranjem. V tem primeru dela na DNS tega ne bo razkrilo, in popoldne gre na napačno plast.

Trije simptomi pokrijejo večino takih primerov, in vsak kaže drugam. Preberite ustrezno vrstico, preden odprete konfiguracijsko datoteko:

Srednjo vrstico ljudje berejo narobe, ker je bila sprememba, ki jo je pokvarila, narejena tedne prej in je takrat izgledala uspešna. Tretjo vrstico ljudje napačno diagnostizirajo, ker ime, ki se razreši, deluje kot dokaz, da je omrežje zdravo. Obe vrstici vas pošljeta v drug razdelek spodaj.

Tuneliranje DNS ima spodnjo mejo različice

Microsoft dokumentira omrežni način WSL, ki tunelira zahteve DNS do resolverja Windows skozi kanal virtualizacije. Na podprtih gradnjah Windows 11 je privzeto omogočen, zato se dva računalnika v istem poslovnem omrežju obnašata različno. Spremenljivka je številka gradnje, ne poslovna politika.

Vodnik po omrežjih WSL opisuje ta način in različice, ki ga podpirajo. Funkcija je pomembna, ker poslovna politika DNS običajno živi v resolverju Windows, in distribucija, ki podeduje pot Windows, podeduje tudi politiko. Distribucija, ki sprašuje javni resolver, nima nobene poti do zasebnega imena, ne glede na to, kako urejena je njena lastna konfiguracija. Ta mehanizem pojasni celoten simptom in pojasni, zakaj obhod z javnim resolverjem ne uspe.

Preberite gradnjo, preden karkoli uredite. Nastavitev, kopirana iz novejše namestitve, ni dokaz, da jo starejša izvaja. Zapišite številko gradnje ob spremembo, ker je razlika med dvema računalnikoma skoraj vedno različica in ne politika.

Stari prepisi preživijo težavo, ki so jo rešili

Starejši recepti so onemogočili ustvarjene datoteke resolverja, trdo kodirali strežnik imen ali zaklenili datoteko z atributom nespremenljivosti. Te spremembe ostanejo na mestu dolgo po tem, ko težava s povezljivostjo, ki jih je sprožila, izgine, in običajno so razlog, da se zdi, da novejša nastavitev ne naredi ničesar. Preživijo tudi ponovno namestitev distribucije v obliki profila lupine, ki datoteko prepiše ob vsaki prijavi. Zadnjo je najtežje najti, ker je nevidna iz datoteke, ki jo vsi pregledujejo.

Poiščite ročno napisano datoteko resolverja, atribut nespremenljivosti na njej in zagonski skript, ki jo prepiše. Pred urejanjem preverite zastavico nespremenljivosti, ker pisanje v zaklenjeno datoteko ne uspe na način, ki se bere kot težava z dovoljenji. Nato preverite profil lupine, ker skript tam obnovi staro vsebino v nekaj sekundah po vašem popravku.

Odstranitev prepisa ima posledice, zato si zapišite, kaj ste odstranili in zakaj. Distribucija, ki resnično potrebuje statični resolver za drug namen, se bo zlomila, ko se ustvarjena datoteka vrne.

Dve datoteki, dve različni vlogi

Obe konfiguracijski datoteki živita na različnih mestih in nadzorujeta različne stvari, in njuna zamenjava povzroči urejanja, uporabljena na napačni plasti. Datoteka na strani Windows nastavi lastnosti navideznega računalnika, medtem ko datoteka na strani distribucije nastavi, kako ta distribucija sestavi svojo lastno konfiguracijo resolverja. Nobena ne prepiše druge, zato se morata obe ujemati.

Za namestitev, ki to funkcijo podpira, je fragment na strani Windows kratek. To je celotna sprememba na tej strani:

[wsl2]
dnsTunneling=true

Ta fragment sodi v uporabniški profil Windows in velja za navidezni računalnik, ne za eno distribucijo. Tuneliranje tudi zahteva, da distribucija ni onemogočila ustvarjanja resolverja, zato mora datoteka na strani distribucije to vedenje pustiti pri miru. Spremenite eno brez drugega in način tiho ne naredi ničesar, in to je najpogostejši način, kako je to popravilo prijavljeno kot pokvarjeno. Preverite obe datoteki v isti seji, ker sta dve urejanji, narejeni s tedni razlike, dve urejanji, ki ju nihče ne more pripisati.

Znova zaženite in nato povprašajte z obeh strani

Te nastavitve se preberejo ob zagonu okolja, zato jih nov shell znotraj delujoče distribucije ne bo znova naložil. Izklopite okolje namesto da znova zaženete shell, in najprej shranite morebitno delo v teku, ker se vsaka distribucija ustavi z njim. Samo ta izpustitev pojasni večino poročil o spremembi brez učinka.

Nato postavite isto vprašanje z obeh strani. Izpis tudi pokaže, pri katerem resolverju je distribucija v resnici končala:

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'

Prvi ukaz konča okolje, drugi pokaže, kateri resolver distribucija zdaj uporablja, zadnja dva pa postavita isto vprašanje vsaki strani. Primerjajte odgovore, ne stanja nastavitve. Poizvedba, ki po čistem ponovnem zagonu z obema pravilnima datotekama še vedno ne uspe, kaže na poslovno politiko resolverja, in ta pogovor ima drugega lastnika.