resolv.conf în WSL 2: DNS-ul moare când se conectează VPN-ul
WSL regenerează resolv.conf din adaptoarele Windows pe care le vede, așa că resolverul VPN-ului poate să nu ajungă niciodată. Opriți generarea, apoi testați un nume corporativ.
Navigarea în interiorul distribuției funcționează, iar primul nume de gazdă intern eșuează în momentul în care tunelul urcă. Reflexul este să adaugi un resolver public, care readuce internetul și face numele corporativ inaccesibil pentru restul zilei. În WSL 2, /etc/resolv.conf este rezultat generat, nu configurație, iar acesta este mecanismul care merită înțeles. Remediu nu este un resolver mai bun, ci proprietatea asupra fișierului.
Fișierul este generat, nu configurat
WSL 2 scrie fișierul la pornire din adaptoarele Windows pe care le vede în acel moment și afișează sus un comentariu care spune acest lucru. Când un client VPN adaugă sau rescrie un adaptor după aceea, distribuția nu regenerează neapărat nimic, și fișierul continuă să descrie o rețea care nu mai există.
Un al doilea mod de eșec este mai silențios: WSL poate copia servere doar de la unele adaptoare. Dacă adaptorul fizic are deja un resolver IPv6, serverele IPv4 furnizate de adaptorul VPN pot fi eliminate în loc să fie adăugate, iar fișierul pare complet omițând exact pe cel care răspunde la numele interne.
Comparați vederea din Windows cu vederea din Linux
Citiți ambele părți înainte de a edita. În interiorul distribuției, uitați-vă ce conține fișierul și dacă este un fișier obișnuit sau o legătură. În Windows, listați resolverul pentru fiecare adaptor, inclusiv cel creat de VPN:
ls -l /etc/resolv.conf
cat /etc/resolv.conf
Get-DnsClientServerAddress -AddressFamily IPv4
Get-NetAdapter | Where-Object Status -eq 'Up'
Când adaptorul VPN arată serverele corporative iar Linux arată altceva, dezacordul este în generare, nu în accesibilitate. Comparați lista de adaptoare și adresele, pentru că un adaptor lipsă explică un server lipsă. Această distincție decide dacă reparați WSL sau un firewall, iar cele două nu au nimic în comun.
Opriți generarea și scrieți-vă propriul fișier
O singură setare documentată împiedică WSL să rescrie fișierul și se află în /etc/wsl.conf. Adăugați o secțiune de rețea în acel fișier:
[network]
generateResolvConf = false
Apoi opriți distribuția din Windows cu wsl --shutdown și porniți-o din nou. Dacă calea este o legătură simbolică și nu un fișier obișnuit, eliminați legătura înainte de a scrie conținutul propriu, pentru că scrierea prin legătură poate recrea ținta generată la următoarea pornire. Din acel moment fișierul este al dumneavoastră și nimic nu îl rescrie.
nameserver 172.28.4.10
nameserver 172.28.4.11
search site.corp.example
options timeout:1 attempts:2 rotate
Fără un domeniu de căutare, un nume de gazdă necualificat este completat cu rădăcina publică și revine ca nu există un astfel de domeniu. timeout împiedică un prim server mort să blocheze fiecare interogare, attempts limitează câte încercări consumă o interogare, iar rotate distribuie reîncercările în loc să înceapă mereu de sus. Schimbul este că fișierul nu mai urmărește un VPN a cărui adresă de resolver se schimbă între sesiuni.
Gestionați un resolver care se mută, apoi verificați
Unii clienți oferă un resolver specific sesiunii, așa că un fișier static se rupe la următoarea conexiune. Două abordări sunt de apărat. Scrieți fișierul dintr-un script mic ori de câte ori se schimbă adresa, sau lăsați generarea activă și asigurați-vă că adaptorul din care copiază WSL poartă serverul corporativ. A doua nu are nevoie de cârlig și eșuează ori de câte ori generarea sare peste adaptorul VPN; ambele cer totuși rezolvarea mai întâi a conflictului IPv6.
Windows aplică și propriile politici de nume, cum ar fi o listă de căutare a sufixelor sau o politică de rezoluție pentru domenii anume, iar copierea adreselor adaptoarelor nu reproduce aceste reguli. Dacă un nume se rezolvă în Windows și nu în distribuție cu același server, comparați tratarea sufixelor înainte de a da vina pe tunel.
Testați cu un nume și nu cu un pachet: getent hosts sensor-access0.corp.example trece prin stiva de resolvere, în timp ce un ping poate reuși împotriva unei adrese din cache sau literală. Apoi repetați după deconectare și reconectare, pentru că o setare care funcționează o dată și se regenerează la reluare nu a fost niciodată reparată. Salvați conținutul anterior și notați ce componentă deține calea pe acea mașină, ca următoarea schimbare să înceapă cu dovezi.