Ustavite dve storitvi Linuxa, ki se borita za /etc/resolv.conf

DNS se vedno znova vrača v prejšnje stanje, ponovna povezava VPN razveljavi vaš popravek in na koncu nekdo v ekipi predlaga zaklep datoteke. To zaporedje je simptom, ne rešitev: dve komponenti obe menita, da posedujeta /etc/resolv.conf, in zmaga tista, ki piše zadnja. Zaklep datoteke ne reši spora o lastništvu, le skrije ga in hkrati pokvari komponento, ki ste jo pravzaprav želeli. Izvedite štiri preverjanja spodaj po vrsti in ureditev popravite na ravni, ki jo poseduje, ne na datoteki.

Preverjanje 1: je to simbolična povezava in kam

Začnite s samo datoteko, ker pot, ki jo urejate, morda sploh ni datoteka. Simbolična povezava v izvajalno mapo resolverja se obnaša povsem drugače kot običajna datoteka, ki jo prepisuje odjemalska skripta:

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

Povezava na stub pot systemd-resolved pomeni, da se vsebina datoteke ustvarja, in ročno urejanje bo ob naslednjem dogodku prepisano. Običajno datoteko z vrsticami nameserver običajno zapiše odjemalec ali kavelj DHCP, ki se zažene ob povezavi. Oboje je legitimno; pomembno je vedeti, katero imate, preden karkoli spremenite.

Preverjanje 2: kateri demon teče

Ugotovite, kaj je resnično aktivno, ne kaj je nameščeno. V sodobni distribuciji je lahko prisotnih več resolverjev, in odgovarja tisti, ki drži vrata 53 na vmesniku loopback:

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

Izhod stanja navaja strežnike DNS za posamezno povezavo in domene usmerjanja, kar je zemljevid, ki ga potrebujete za split DNS. Če morajo notranja imena iti na notranji strežnik in vse ostalo na javnega, ta politika živi v domenah posameznih povezav, in njeno sploščenje v statični seznam nameserver v datoteki tiho izgubi to razliko.

Lastna konfiguracija NetworkManagerja odloča, kateri od teh backendov se uporablja. Njegova nastavitev dns= v glavni konfiguracijski datoteki izbere med njegovim notranjim resolverjem, dnsmasq, systemd-resolved in none, distribucija pa je morda izbrala namesto vas. Preberite to nastavitev, preden se odločite, kaj „popravljanje DNS“ pomeni na tem gostitelju.

Preverjanje 3: kaj sme odjemalec VPN pisati

Tu običajno živi spor. Odjemalec VPN, ki neposredno prepisuje datoteko resolverja, se bo boril z vsako storitvijo, ki jo tudi vzdržuje, in izgubi tisti, ki se zažene prvi. Novejše izdaje OpenVPN lahko nastavitve DNS predajo systemd-resolved namesto prepisovanja datoteke, kar je sodelovalno vedenje, ki ga želite; starejše skripte in ročno napisani kavlji pogosto kličejo zastarel pomožni pripomoček ali preprosto prepišejo datoteko.

Stanje pri WireGuardu je po obliki podobno: konfiguracija vmesnika sama ne upravlja DNS, to delajo orodja okoli nje, prek pomočnika resolverja ali integracije resolved. Če sta nameščena dva taka pomočnika, bosta oba poskušala ob povezavi uveljaviti svojo podobo sveta.

Preberite kavlje up in down odjemalca, namesto da ugibate. Nekaj vrstic lupine v /etc/openvpn/up.sh ali enakovredni mapi pojasni vedenje, ki se sicer zdi naključno, in prav tam lahko odjemalca pripravite do sodelovanja namesto tekmovanja.

Preverjanje 4: popravite pri lastniku, ne v datoteki

Ko poznate lastnika, konfigurirajte DNS prek vmesnika, ki ga ta lastnik podpira. Za systemd-resolved to pomeni nastavitve za posamezno povezavo in domene usmerjanja namesto statične datoteke; za NetworkManager nastavitve DNS v profilu povezave in izbrani backend; za distribucijo z integracijo resolvconf pisanje prek tega pomočnika.

Datoteke ne naredite nespremenljive. Atribut nespremenljivosti ustavi legitimne obnovitve DHCP in posodobitve VPN skupaj s tistimi, s katerimi ste se borili, in pusti sistem v stanju, ko naslednja nadgradnja paketov ali ponovna povezava povzroči okvaro, ki je nihče ne more razložiti iz konfiguracije. Skriva spor o lastništvu, kar je prav tisto, kar ste poskušali rešiti.

Kjer morata dve komponenti resnično sobivati, jima dajte različne naloge. Pustite upravitelju omrežja, da poseduje konfiguracijo na ravni vmesnika, pustite odjemalcu VPN, da prispeva DNS in domene za posamezno povezavo prek iste integracije, in odstranite tretjo skripto, ki datoteko piše neposredno. Dokumentacija systemd-resolved opisuje načine, ki jih podpira, in kaj vsak od njih razkrije v /etc/resolv.conf. Izberite način, ki ustreza količini politike, ki jo morate obdržati. Če je split DNS pomemben, ga stub ureditev z domenami za posamezno povezavo ohrani, medtem ko način, ki v datoteko kopira nadrejene strežnike, ga tiho splošči.

Preverite po ponovni povezavi, ne po urejanju

Datoteka, ki je videti pravilna takoj po vaši spremembi, ne dokazuje ničesar, ker se naslednji dogodek še ni zgodil. Sprožite zaporedje, ki jo je prej lomilo: spustite in dvignite tunel, obnovite najem DHCP ali preklopite vmesnik, nato znova preberite iste vrednosti.

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

Nato potrdite razliko, ki je pomembna: notranje ime se razreši prek notranjega strežnika, javno ime pa še vedno deluje. Konfiguracija, ki pošilja vse na notranji strežnik, je videti v redu, dokler nekdo ne poskusi priti v internet skozi tunel, konfiguracija, ki pošilja vse na javnega, pa pušča notranja imena.

V beležke uvajanja zapišite lastnika, backend in način simbolične povezave. Ta en odstavek spremeni prihodnjo nadgradnjo paketov iz incidenta v pregledno postavko in prepreči naslednji osebi, da bi isto sporo znova odkrila z ukazom chattr.