Opriți două servicii Linux care se întrec pentru /etc/resolv.conf

DNS revine mereu la starea anterioară, reconectarea VPN anulează corectura dvs., iar la final cineva din echipă propune blocarea fișierului. Această succesiune este un simptom, nu o soluție: două componente cred ambele că dețin /etc/resolv.conf, și câștigă cel care scrie ultimul. Blocarea fișierului nu rezolvă conflictul de proprietate, doar îl ascunde și, în același timp, strică componenta pe care o doreați de fapt. Faceți cele patru verificări de mai jos în ordine și corectați aranjamentul la nivelul care îl deține, nu la fișier.

Verificarea 1: este o legătură simbolică și către ce

Începeți cu fișierul însuși, pentru că calea pe care o editați s-ar putea să nu fie deloc fișierul. O legătură simbolică într-un director de rulare al unui resolver se comportă complet diferit de un fișier obișnuit pe care un script client îl rescrie:

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

O legătură către o cale stub a systemd-resolved înseamnă că conținutul fișierului este generat, iar editarea manuală va fi suprascrisă la următorul eveniment. Un fișier obișnuit cu linii nameserver este scris de obicei de clientul sau de hook-ul DHCP care rulează la conectare. Ambele sunt legitime; important este să știți care dintre ele există înainte de a schimba ceva.

Verificarea 2: ce daemon rulează

Aflați ce este cu adevărat activ, nu ce este instalat. Într-o distribuție modernă pot exista mai mulți resolvere, iar cel care ține portul 53 pe interfața loopback este cel care răspunde:

systemctl status systemd-resolved --no-pager
resolvectl status
ss -lunp | grep ':53'

Ieșirea de stare numește serverele DNS pentru fiecare legătură și domeniile de rutare, care este harta de care aveți nevoie pentru split DNS. Dacă numele interne trebuie să meargă la un server intern, iar restul la unul public, această politică trăiește în domeniile pe legătură, iar aplatizarea ei într-o listă statică de nameserver în fișier pierde în silențiu această distincție.

Configurația proprie a NetworkManager decide care dintre aceste backend-uri este folosit. Setarea dns= din fișierul principal de configurare alege între resolverul său intern, dnsmasq, systemd-resolved și none, iar distribuția poate a ales în locul dumneavoastră. Citiți acea setare înainte de a decide ce înseamnă „repararea DNS” pe acest host.

Verificarea 3: ce are voie să scrie clientul VPN

Aici trăiește de obicei conflictul. Un client VPN care rescrie direct fișierul resolverului se va lupta cu orice serviciu care îl întreține și el, iar pierzătorul este cel care rulează primul. Versiunile recente de OpenVPN pot preda setările DNS către systemd-resolved în loc să rescrie fișierul, ceea ce este comportamentul cooperant pe care îl doriți; scripturile mai vechi și hook-urile scrise manual apelează adesea un utilitar învechit sau pur și simplu suprascriu fișierul.

Situația WireGuard este similară ca formă: configurația interfeței nu gestionează ea însăși DNS-ul, ci uneltele din jurul ei, printr-un helper de resolver sau integrarea resolved. Dacă sunt instalate două astfel de helpere, ambele vor încerca să își impună viziunea asupra lumii la conectare.

Citiți hook-urile up și down ale clientului în loc să ghiciți. Câteva linii de shell în /etc/openvpn/up.sh sau într-un director echivalent explică un comportament care altfel pare aleatoriu, și tot acolo puteți face clientul să coopereze în loc să concureze.

Verificarea 4: reparați-l la proprietar, nu în fișier

După ce știți proprietarul, configurați DNS prin interfața acceptată de acel proprietar. Pentru systemd-resolved aceasta înseamnă setări pe legătură și domenii de rutare în loc de un fișier static; pentru NetworkManager înseamnă setările DNS ale profilului de conexiune și backend-ul ales; pentru o distribuție cu integrare resolvconf înseamnă scrierea prin acel helper.

Nu faceți fișierul imutabil. Atributul de imutabilitate oprește reînnoirile DHCP legitime și actualizările VPN împreună cu cele cu care vă luptați, și lasă sistemul într-o stare în care următoarea actualizare de pachete sau reconectare produce o defecțiune pe care nimeni nu o poate explica din configurație. Ascunde conflictul de proprietate, exact ceea ce încercați să rezolvați.

Acolo unde două componente chiar trebuie să coexiste, dați-le sarcini diferite. Lăsați managerul de rețea să dețină configurația la nivel de interfață, lăsați clientul VPN să contribuie cu DNS și domenii pe legătură prin aceeași integrare, și eliminați al treilea script care scrie fișierul direct. Documentația systemd-resolved descrie modurile pe care le acceptă și ce expune fiecare dintre ele în /etc/resolv.conf. Alegeți modul care corespunde cantității de politică pe care trebuie să o păstrați. Dacă split DNS contează, aranjamentul stub cu domenii pe legătură îl păstrează, în timp ce modul care copiază serverele upstream în fișier îl aplatizează în silențiu.

Verificați după o reconectare, nu după editare

Un fișier care pare corect imediat după modificarea dvs. nu dovedește nimic, pentru că următorul eveniment nu s-a întâmplat încă. Declanșați secvența care îl strica înainte: coborâți și ridicați tunelul, reînnoiți bailul DHCP sau comutați interfața, apoi citiți din nou aceleași valori.

resolvectl query build.corp.example
resolvectl query example.com
resolvectl status | head -40

Apoi confirmați distincția care contează: numele intern se rezolvă prin serverul intern, în timp ce numele public încă funcționează. O configurație care trimite totul la serverul intern pare în regulă până când cineva încearcă să ajungă la internet prin tunel, iar o configurație care trimite totul la cel public lasă să scape nume interne.

Notați proprietarul, backend-ul și modul legăturii simbolice în notele de implementare. Acel singur paragraf transformă o viitoare actualizare de pachete din incident în punct de revizuire și împiedică următoarea persoană să redescopere același conflict cu o comandă chattr.