Editarea resolv.conf nu repară DNS-ul după deconectarea VPN-ului

Deconectați VPN-ul, ping 1.1.1.1 încă răspunde, iar fiecare căutare de nume atârnă înainte ca pagina să renunțe în sfârșit. Apoi cat /etc/resolv.conf arată un server de nume care a existat vreodată doar în interiorul tunelului, de obicei primul în listă. Ștergerea acelei linii pare să rezolve problema pentru vreo zece minute, până când o suspendare, un roaming Wi-Fi sau o repornire o pun la loc. Fișierul pe care l-ați editat nu este setarea; este o reprezentare a stării legăturii pe care o deține alt component.

De ce o singură intrare învechită costă secunde pentru fiecare interogare

Resolverul glibc parcurge lista de servere de nume în ordine și așteaptă expirarea unui timeout înainte de a-l încerca pe următorul, iar resolv.conf(5) limitează această listă la trei intrări. Puneți un resolver din partea tunelului, cum ar fi 10.8.0.1, în frunte după ce tunelul a dispărut, și fiecare interogare plătește timeout-ul înainte de a trece la un server care răspunde. De aceea simptomul arată ca o conexiune moartă și nu ca o eroare DNS: browserele se blochează, expiră și uneori livrează o adresă din cache care devine învechită mai târziu.

Asta explică și de ce reclamația vine ca „internetul este stricat”. Un ping către o adresă IP dovedește că legătura este în regulă, ceea ce face defectul să pară al aplicației. Lista de resolvere este primul lucru de citit și ultimul de editat.

Mitul: resolv.conf este un fișier de setări

Întrebați ce este de fapt calea respectivă înainte de a o schimba:

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf

Pe un host cu systemd-resolved este o legătură simbolică către un fișier stub care indică 127.0.0.53, iar serverele reale trăiesc în starea pe fiecare legătură pe care o tipărește resolvectl. Pe un host cu NetworkManager poate fi un fișier pe care NetworkManager îl scrie din conexiunea activă. La unii clienți ai producătorilor este un fișier simplu rescris pe loc la conectare și, dacă nu aveți noroc, niciodată restaurat la deconectare. Sunt trei proprietari diferiți, iar editarea manuală a primelor două fie nu face nimic, fie ține până la următorul eveniment de rețea.

resolvectl status este vederea care spune adevărul: servere DNS pe fiecare legătură, domenii de rutare și dacă legătura tunelului mai există. resolvectl query example.com merge mai departe și arată ce interfață a răspuns. Folosiți-le pe amândouă înainte de a atinge un fișier și țineți minte că un browser cu DNS securizat propriu ignoră toate acestea.

Găsiți proprietarul înainte de a edita ceva

De obicei trei componente concurează pentru aceeași setare: systemd-resolved, NetworkManager și ce a instalat clientul VPN. Identificați mai întâi componenta vie:

systemctl is-active systemd-resolved
nmcli connection show --active
ps aux | grep -E "openvpn|wg-quick|vpn"

Dacă resolved este activ și legătura simbolică indică stubul lui, fișierul global este ieșire generată, iar editarea dumneavoastră este cosmetică. Dacă NetworkManager deține conexiunea, serverele aparțin profilului de conexiune, așa că remedierea este o schimbare de proprietate prin nmcli, nu o editare de fișier. Dacă rulează un demon al producătorului, doar propria lui cale de restaurare supraviețuiește următoarei conectări.

Curățați starea legăturii lăsate de client

Un client omorât nu își poate rula cârligul de curățare. SIGKILL nu poate fi prins deloc, în timp ce SIGINT și SIGTERM pot, așa că un tunel care „pur și simplu s-a oprit” după o omorâre forțată lasă adesea pe loc atât înregistrarea interfeței, cât și intrarea resolverului. Găsiți PID-ul concret și trimiteți semnalul doar acestuia:

ps aux | grep -E "openvpn|wg-quick"
sudo kill <pid>
resolvectl revert tun0

Nu vă întindeți după pkill -f vpn sau killall vpn înainte de a citi lista completă de potriviri. -f potrivește întreaga linie de comandă, deci poate termina un script de împachetare, o sesiune de editor sau un proces nelegat a cărui cale conține șirul. Terminarea procesului greșit la mijlocul lucrului este felul în care o problemă de resolver devine un fișier pierdut.

resolvectl revert resetează configurația DNS de rulare a acelei legături, ceea ce este mai îngust decât repornirea resolverului și mult mai îngust decât editarea fișierului global. Dacă legătura tunelului a dispărut complet, systemctl restart NetworkManager reconstruiește starea conexiunii și este pasul la care firele sursă revin mereu. Fiți atenți la un manager de servicii cu Restart=always, pentru că poate pune un client omorât, și setările lui DNS, direct la loc.

Cealaltă direcție: DNS împins care nu a ajuns niciodată

Imaginea în oglindă a intrării învechite este un tunel fără niciun resolver utilizabil. O opțiune DNS din profil este o cerere; componenta care gestionează conexiunea trebuie să o predea resolverului. Dacă jurnalul arată că serverul a fost primit, dar legătura tunelului nu poartă nicio setare DNS, lipsește integrarea, nu serverul.

Testați predarea făcând-o manual, ceea ce separă „serverul este greșit” de „nimeni nu l-a aplicat”:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

Domeniul de rutare care prinde tot trimite fiecare nume către acea legătură, ceea ce vrea un client de tunel complet și ceea ce DNS-ul divizat nu trebuie să folosească. Aceste setări dispar la următoarea conectare. Pentru a le face persistente în NetworkManager, dezactivați DNS-ul automat, setați serverul pe conexiune și adăugați domeniul:

nmcli connection modify office ipv4.ignore-auto-dns yes
nmcli connection modify office ipv4.dns 10.10.10.10
nmcli connection modify office ipv4.dns-search "~."

Pentru un tunel de companie care ar trebui să răspundă doar numelor interne, listați acele zone cu un tilde inițial în locul prinderii-tot, astfel încât numele publice să folosească în continuare resolverul local.

Soluții de avarie care devin următoarea pană

Copierea resolv.conf înainte de conectare și restaurarea lui după este o linie legitimă într-un runbook și este o soluție de avarie, nu o reparație. Ea eșuează exact când contează, pentru că o prăbușire sau o repornire forțată sare peste restaurare. Notați-o ca soluție de avarie, ca următoarea persoană să nu construiască pe ea.

Dezactivarea systemd-resolved și codificarea rigidă a serverelor publice este cealaltă mișcare populară. Face conectarea și deconectarea previzibile și elimină DNS-ul pe fiecare legătură pentru orice altă rețea, ceea ce strică DNS-ul divizat pentru numele interne și anulează scopul unui tunel menit să țină interogările în interiorul lui. Instalarea resolvconf și fixarea serverelor publice costă la fel, cu un strat în plus. Tratați oricare dintre ele ca diagnostic: dacă readuce navigarea, ați învățat că integrarea resolverului este vinovată, nu că serverele publice sunt corecte.

Reparația durabilă este un proprietar pe fiecare strat: decideți ce componentă deține DNS-ul legăturii tunelului și care deține valoarea globală implicită, notați asta și scoateți celelalte din cale. Apoi verificați după o deconectare cu un nume pe care doar VPN-ul îl rezolvă. Dacă un nume privat încă răspunde, înregistrarea nu a fost eliminată; dacă nimic nu se rezolvă, fișierul indică un server care nu mai există. Ambele se văd în resolvectl înainte de a deschide un browser.