De ce WSL pierde numele gazdei de lucru când se conectează VPN-ul?

Windows rezolvă gazda internă fără nicio obiecție, iar același nume eșuează în WSL în momentul în care tunelul urcă. Reparația obișnuită este să scrii un resolver public în distribuție, ceea ce restabilește navigarea normală și face numele gazdei de lucru imposibil de rezolvat. Asta schimbă o defecțiune cu alta și ascunde stratul care chiar s-a stricat. Înainte de a adăuga sau elimina orice linie de resolver, stabiliți care dintre cele trei straturi eșuează.

Mai întâi excludeți o defecțiune de rutare

Interogați același nume complet calificat pe ambele părți, nu două nume care seamănă. Un succes în Windows și o eșuare în WSL pentru același șir este semnătura a două căi de rezolvare, și puține alte lucruri produc acel model atât de curat. Dacă WSL nu ajunge la serviciu nici la adresa sa numerică cunoscută, există și o problemă de rutare sau de filtrare. În acel caz munca pe DNS nu o va dezvălui, iar după-amiaza se duce pe stratul greșit.

Trei simptome acoperă majoritatea acestor cazuri, iar fiecare indică în altă parte. Citiți rândul care corespunde înainte de a deschide un fișier de configurare:

Rândul din mijloc este cel pe care oamenii îl citesc greșit, pentru că schimbarea care l-a stricat a fost făcută cu săptămâni înainte și atunci părea reușită. Al treilea rând este cel pe care oamenii îl diagnostichează greșit, pentru că un nume care se rezolvă pare dovada că rețeaua este sănătoasă. Ambele rânduri vă trimit la o secțiune diferită mai jos.

Tunelarea DNS are o limită minimă de versiune

Microsoft documentează un mod de rețea al WSL care tunelează cererile DNS către resolverul Windows printr-un canal de virtualizare. Pe compilările Windows 11 acceptate este activat implicit, de aceea două mașini din aceeași rețea corporate se comportă diferit. Variabila este numărul compilării, nu politica firmei.

Ghidul de rețea al WSL descrie acel mod și versiunile care îl acceptă. Funcția contează pentru că politica DNS corporate locuiește de obicei în resolverul Windows, iar o distribuție care moștenește calea Windows moștenește și politica. O distribuție care întreabă un resolver public nu are nicio rută către un nume privat, oricât de îngrijită ar arăta propria configurație. Acel mecanism explică întregul simptom și explică de ce soluția ocolitoare cu resolver public eșuează.

Citiți compilarea înainte de a edita ceva. O setare copiată dintr-o instalare mai nouă nu este dovada că una mai veche o implementează. Notați numărul compilării lângă schimbare, pentru că diferența dintre două mașini este aproape întotdeauna o versiune, nu o politică.

Suprascrierile vechi supraviețuiesc problemei pe care au rezolvat-o

Rețetele mai vechi dezactivau fișierele de resolver generate, codau fix un server de nume sau blocau fișierul cu un atribut imutabil. Acele schimbări rămân pe loc mult după ce problema de conectivitate care le-a provocat a dispărut, și de obicei ele sunt motivul pentru care o setare mai nouă pare să nu facă nimic. Ele supraviețuiesc și unei reinstalări a distribuției sub forma unui profil de shell care rescrie fișierul la fiecare autentificare. Ultimul este cel mai greu de găsit, pentru că este invizibil din fișierul pe care toată lumea îl inspectează.

Căutați un fișier de resolver scris de mână, un atribut imutabil pe el și un script de pornire care îl rescrie. Verificați indicatorul imutabil înainte de editare, pentru că o scriere într-un fișier blocat eșuează într-un mod care se citește ca o problemă de permisiuni. Verificați apoi profilul de shell, pentru că un script de acolo restaurează conținutul vechi în câteva secunde după corectarea dumneavoastră.

Eliminarea unei suprascrieri are consecințe, așa că notați ce ați eliminat și de ce. O distribuție care chiar are nevoie de un resolver static pentru alt scop se va strica atunci când fișierul generat revine.

Două fișiere, două roluri diferite

Cele două fișiere de configurare locuiesc în locuri diferite și controlează lucruri diferite, iar confundarea lor produce modificări aplicate pe stratul greșit. Fișierul din partea Windows setează proprietăți ale mașinii virtuale, în timp ce fișierul din partea distribuției setează cum își construiește acea distribuție propria configurație de resolver. Niciunul nu îl suprascrie pe celălalt, de aceea ambele trebuie să fie de acord.

Pentru o instalare care acceptă funcția, fragmentul din partea Windows este scurt. Este întreaga schimbare din acea parte:

[wsl2]
dnsTunneling=true

Acest fragment aparține profilului de utilizator Windows și se aplică mașinii virtuale, nu unei singure distribuții. Tunelarea cere de asemenea ca distribuția să nu fi dezactivat generarea resolverului, așa că fișierul din partea distribuției trebuie să lase acel comportament în pace. Schimbați unul fără celălalt și modul nu face nimic în tăcere, iar acesta este cel mai obișnuit mod în care această reparație este raportată ca stricată. Verificați ambele fișiere în aceeași sesiune, pentru că două modificări făcute la săptămâni distanță sunt două modificări pe care nimeni nu le poate atribui.

Reporniți, apoi interogați din ambele părți

Aceste setări sunt citite la pornirea mediului, așa că un shell nou într-o distribuție care rulează nu le va reîncărca. Opriți mediul în loc să reporniți shell-ul și salvați mai întâi orice lucru aflat în desfășurare, pentru că fiecare distribuție se oprește împreună cu el. Doar această omisiune explică majoritatea rapoartelor că o schimbare nu are efect.

Apoi puneți aceeași întrebare din ambele părți. Rezultatul arată și cu ce resolver a rămas de fapt distribuția:

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'

Prima comandă încheie mediul, a doua arată ce resolver folosește distribuția acum, iar ultimele două pun aceeași întrebare fiecărei părți. Comparați răspunsurile, nu starea setării. O interogare care încă eșuează după o repornire curată, cu ambele fișiere corecte, indică politica de resolver a firmei, iar acea conversație are alt proprietar.