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 netko 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 trebala. Prođite kroz četiri provjere u nastavku redom i popravite raspored na razini koja ga posjeduje, a ne na datoteci.

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

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

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

Poveznica 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 recima 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 razrješivača, 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 poslužitelje po vezi i domene usmjeravanja, a to je karta koja vam treba za split DNS. Ako unutarnja imena moraju ići na unutarnji poslužitelj, 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 razrješivača, 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 razrješivača 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 razrješivač 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 poslužitelje 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 poslužitelj, dok javno ime još radi. Konfiguracija koja sve šalje na unutarnji poslužitelj 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 poveznice 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.