WSL2 a pierdut DNS după conectarea VPN? Două cauze

Ping-ul după adresă funcționează în interiorul distribuției, instalările de pachete și descărcările git nu, iar defecțiunea a apărut imediat după ridicarea tunelului. Doar numele au încetat să se rezolve, ceea ce indică DNS și nu conectivitate. Reinstalarea pachetelor este cel mai popular prim pas greșit aici. WSL2 are două moduri independente de a produce exact acel simptom, iar ele cer reparații diferite.

De ce distribuția își păstrează propriul resolver

Clientul DNS din Windows nu este folosit în interiorul distribuției. WSL2 construiește propriul fișier resolver la pornire, care indică o adresă stub pe care Windows o publică pe comutatorul virtual pentru mașina virtuală auxiliară.

Aranjamentul este stabil la schimbările obișnuite de rețea pentru că este scris o dată și reutilizat. Aranjamentul nu mai este corect când un client de tunel rescrie lista de adaptoare a gazdei după ce mașina virtuală auxiliară a pornit deja.

Nimic din interiorul distribuției nu urmărește schimbarea, așa că fișierul continuă să indice o adresă care poate nu mai este pe traseu. Următoarea interogare atunci așteaptă, expiră sau primește un răspuns de la un server care nu a auzit niciodată de zona internă. Din interior, resolverul pur și simplu nu mai răspunde, iar toate numele eșuează deodată.

Mai întâi adunați dovezi de ambele părți

Înregistrați ce vede distribuția, apoi ce vede Windows, înainte de a schimba oricare dintre ele. Cele două vederi împreună sunt ce distinge modurile de defectare.

În interiorul distribuției, afișați fișierul resolver, tabela de rutare și o interogare internă și una publică:

ip -4 route
cat /etc/resolv.conf
getent hosts intranet.corp.example
getent hosts example.com

În Windows, listați serverele DNS pe adaptor și tabela IPv4 cu metrici. Un client VPN instalează de obicei o rută pentru subrețeaua WSL2, iar metrica ei decide dacă acel trafic pleacă prin tunel sau rămâne local.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

Metrică de rută sau fișier învechit

Prima defecțiune este fișierul învechit. Resolverul a fost scris pentru starea adaptorului la pornire, iar tunelul a schimbat acea stare. Adresa sa stub poate fi acum inaccesibilă sau poate numi un server care nu știe nimic despre zona internă.

A doua este o problemă de rutare. Când VPN-ul adaugă o rută care acoperă subrețeaua WSL2 cu o metrică mai mică decât ruta de legătură a gazdei, pachetele adresate mașinii virtuale auxiliare intră în tunel. Atunci expiră fiecare serviciu WSL2, nu doar DNS.

Testul care le distinge costă o linie. Dacă o adresă numerică precum un resolver public încă răspunde la ping în timp ce numele eșuează, traseul este intact și problema este DNS. Acesta este cazul în care o schimbare de resolver este justificată, iar cazul în care nu este devine și el evident. Dacă și testul numeric eșuează, mașina virtuală auxiliară și-a pierdut ruta și niciun fișier resolver nu va repara asta.

Pentru cazul de rutare, eliminați metrica automată de pe adaptorul tunelului și dați-i un număr peste ruta de legătură WSL2:

Get-NetAdapter | Where-Object InterfaceDescription -Match VPN | Set-NetIPInterface -InterfaceMetric 5500
wsl.exe --shutdown

Oprirea contează. Schimbarea metricii nu rescrie mașina virtuală auxiliară care rulează, așa că distribuția trebuie reconstruită înainte ca schimbarea să fie vizibilă.

Preluați fișierul, deliberat

Dacă rutarea este corectă și doar numele interne eșuează, resolverul este vinovat și puteți opri generatorul. Este o schimbare deliberată cu un cost de întreținere, nu o soluție provizorie de aplicat în grabă.

Creați /etc/wsl.conf în interiorul distribuției cu secțiunea de rețea care dezactivează generarea, apoi scrieți singur fișierul resolver, serverul corporativ primul și unul public de rezervă al doilea:

[network]
generateResolvConf = false

search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

Ordinea contează. Un resolver public nu poate răspunde unui nume intern, iar rezerva există doar pentru interogări de internet. Odată ce fișierul este al dumneavoastră, nimic nu îl regenerează, așa că un resolver corporativ care se mută devine o cădere pe care trebuie să o observați singur.

Verificați numele, apoi pachetele

Verificați un nume intern și unul public cu resolverul sistemului, apoi repetați operațiunea care a eșuat. Managerii de pachete folosesc uneori un resolver propriu, de aceea un getent funcțional poate coexista cu o instalare stricată.

Dacă automatizați rescrierea, faceți-o idempotentă: fără tunel, păstrați fișierul care există deja în loc să scrieți o listă goală de servere.

getent hosts intranet.corp.example
resolvectl status | head -20
getent hosts example.com

O interogare internă funcțională și o interogare publică funcțională, din interiorul distribuției, este rezultatul care merită înregistrat. O pictogramă VPN verde pe gazdă nu dovedește niciuna dintre ele.