Zaustavite dvije Linux usluge koje se bore za /etc/resolv.conf

DNS se stalno vraća na staro, ponovno povezivanje VPN-a poništava vaš popravak, i neko u timu na kraju predloži zaključavanje datoteke. Taj slijed je simptom, a ne rješenje: dvije komponente obje misle da posjeduju /etc/resolv.conf, a pobjeđuje ona koja piše posljednja. Zaključavanje datoteke ne rješava sukob vlasništva, samo ga skriva i pritom kvari komponentu koja vam je zapravo bila potrebna. Prođite kroz četiri provjere ispod redom i popravite raspored na razini koja ga posjeduje, a ne na datoteci.

Provjera 1: je li to simbolička veza i prema čemu

Počnite od same datoteke, jer putanja koju uređujete možda uopće nije datoteka. Simbolička veza u radni direktorij rezolvera ponaša se potpuno drugačije od obične datoteke koju klijentska skripta prepisuje:

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

Veza na stub putanju systemd-resolveda znači da se sadržaj datoteke generira i da će ručno uređivanje biti prepisano pri sljedećem događaju. Običnu datoteku s nameserver redcima obično piše onaj klijent ili DHCP hook koji se pokrene pri povezivanju. Oboje je legitimno; važno je znati koje od toga imate prije nego što bilo što promijenite.

Provjera 2: koji daemon radi

Otkrijte što je stvarno aktivno, a ne što je instalirano. Na modernoj distribuciji može biti prisutno nekoliko rezolvera, a odgovara onaj koji drži port 53 na loopback sučelju:

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

Izlaz statusa navodi DNS servere po vezi i domene usmjeravanja, a to je karta koja vam treba za split DNS. Ako unutarnja imena moraju ići na unutarnji server, a sve ostalo na javni, ta politika živi u domenama po vezi, a njezino spljoštavanje u statički popis nameservera u datoteci tiho gubi tu razliku.

Vlastita konfiguracija NetworkManagera odlučuje koji od ovih pozadinskih sustava koristi. Njegova postavka dns= u glavnoj konfiguracijskoj datoteci bira između njegovog unutarnjeg rezolvera, dnsmasqa, systemd-resolveda i none, a distribucija je možda izabrala umjesto vas. Pročitajte tu postavku prije nego što odlučite što “popravljanje DNS-a” znači na ovom hostu.

Provjera 3: što VPN klijent smije pisati

Ovdje sukob obično i živi. VPN klijent koji izravno prepisuje datoteku rezolvera borit će se sa svakom uslugom koja je također održava, a gubi onaj koji se pokrene prvi. Novija izdanja OpenVPN-a mogu predati DNS postavke systemd-resolvedu umjesto prepisivanja datoteke, što je kooperativno ponašanje koje želite; starije skripte i ručno napisani hookovi često pozivaju zastarjeli pomoćni alat ili jednostavno prepisuju datoteku.

Situacija s WireGuardom slična je po obliku: sama konfiguracija sučelja ne upravlja DNS-om, to rade alati oko nje, preko pomoćnika za rezolver ili integracije s resolvedom. Ako su instalirana dva takva pomoćnika, oba će pri povezivanju pokušati primijeniti svoju sliku svijeta.

Čitajte klijentove up i down hookove umjesto da nagađate. Nekoliko redaka shella u /etc/openvpn/up.sh ili ekvivalentnom direktoriju objašnjava ponašanje koje inače izgleda slučajno, a to je i mjesto na kojem klijenta možete natjerati da surađuje umjesto da se natječe.

Provjera 4: popravite to kod vlasnika, ne u datoteci

Kad znate vlasnika, konfigurirajte DNS kroz sučelje koje taj vlasnik podržava. Za systemd-resolved to znači postavke po vezi i domene usmjeravanja umjesto statičke datoteke; za NetworkManager to znači DNS postavke profila veze i odabrani pozadinski sustav; za distribuciju s integracijom resolvconfa to znači pisanje kroz taj pomoćnik.

Ne činite datoteku nepromjenjivom. Atribut nepromjenjivosti zaustavlja legitimna obnavljanja DHCP-a i VPN ažuriranja zajedno s onima s kojima ste se borili, i ostavlja sustav u stanju u kojem sljedeće nadograđivanje paketa ili ponovno povezivanje proizvodi kvar koji nitko ne može objasniti iz konfiguracije. On prikriva sukob vlasništva, upravo ono što ste pokušavali riješiti.

Gdje dvije komponente doista moraju supostojati, dajte im različite poslove. Neka mrežni upravitelj posjeduje konfiguraciju na razini sučelja, neka VPN klijent doprinosi DNS-om i domenama po vezi kroz istu integraciju, i uklonite treću skriptu koja izravno piše datoteku. Dokumentacija systemd-resolveda opisuje načine rada koje podržava i što svaki od njih izlaže u /etc/resolv.conf. Odaberite način koji odgovara količini politike koju trebate zadržati. Ako je split DNS važan, stub raspored s domenama po vezi to čuva, dok način koji kopira upstream servere u datoteku to tiho spljoštava.

Provjerite nakon ponovnog povezivanja, a ne nakon uređivanja

Datoteka koja izgleda ispravno odmah nakon vaše promjene ne dokazuje ništa, jer se sljedeći događaj još nije dogodio. Pokrenite slijed koji ju je prije kvario: spustite i podignite tunel, obnovite DHCP lease ili prebacite sučelje, pa ponovno pročitajte iste vrijednosti.

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

Zatim potvrdite razliku koja je važna: unutarnje ime razrješava unutarnji server, dok javno ime još radi. Konfiguracija koja sve šalje na unutarnji server izgleda dobro dok netko ne pokuša doći na internet kroz tunel, a konfiguracija koja sve šalje na javni odaje unutarnja imena.

Zabilježite vlasnika, pozadinski sustav i način simboličke veze u bilješke o postavljanju. Taj jedan odlomak pretvara buduću nadogradnju paketa iz incidenta u stavku za pregled i sprječava sljedeću osobu da ponovno otkrije isti sukob naredbom chattr.