Haltigu du Linuksajn servojn konkurencantajn pri /etc/resolv.conf

DNS daŭre returniĝas, la rekonekto de la VPN malfaras vian korekton, kaj iam iu en la teamo proponas ŝlosi la dosieron. Tiu sinsekvo estas simptomo, ne solvo: du komponantoj ambaŭ kredas posedi /etc/resolv.conf, kaj la venkanto estas tiu, kiu skribas laste. Ŝlosi la dosieron ne solvas la posedkonflikton; ĝi nur kaŝas ĝin dum ĝi rompas la komponanton, kiun vi fakte volis. Trairu la kvar kontrolojn sube en ordo, kaj riparu la aranĝon je la nivelo, kiu posedas ĝin, ne je la dosiero.

Kontrolo 1: ĉu ĝi estas simbola ligilo, kaj al kio

Komencu per la dosiero mem, ĉar la vojo, kiun vi redaktas, eble tute ne estas la dosiero. Simbola ligilo en la rultempan dosierujon de solvilo kondutas tute alie ol ordinara dosiero, kiun klienta skripto reskribas:

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

Ligilo al stub-vojo de systemd-resolved signifas, ke la enhavo de la dosiero estas generata, kaj mana redakto estos anstataŭigita ĉe la sekva evento. Ordinaran dosieron kun nameserver-linioj kutime skribas tiu kliento aŭ DHCP-hoko, kiu ruliĝas ĉe konekto. Ambaŭ estas legitimaj; gravas scii, kiun vi havas, antaŭ ol vi ŝanĝas ion ajn.

Kontrolo 2: kiu demono ruliĝas

Eltrovu, kio efektive aktivas, ne kio estas instalita. Sur moderna distribuo povas ĉeesti pluraj solviloj, kaj respondas tiu, kiu tenas la pordon 53 sur la loopback-interfaco:

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

La statusa eligo nomas la DNS-servilojn laŭ ligilo kaj la enkursigajn domajnojn, kio estas la mapo, kiun vi bezonas por split DNS. Se internaj nomoj devas iri al interna servilo kaj ĉio alia al publika, tiu politiko vivas en la domajnoj laŭ ligilo, kaj platigi ĝin en statikan nameserver-liston en la dosiero silentigas la distingon.

La propra agordo de NetworkManager decidas, kiun el tiuj backend-oj ĝi uzas. Ĝia agordo dns= en la ĉefa agorda dosiero elektas inter sia interna solvilo, dnsmasq, systemd-resolved kaj none, kaj distribuo eble elektis por vi. Legu tiun agordon antaŭ ol decidi, kion “ripari DNS” signifas sur ĉi tiu gastigo.

Kontrolo 3: kion la VPN-kliento rajtas skribi

Ĉi tie kutime vivas la konflikto. VPN-kliento, kiu rekte reskribas la solvilan dosieron, batalos kontraŭ ajna servo, kiu ankaŭ prizorgas ĝin, kaj la perdanto estas tiu, kiu ruliĝas unue. Lastatempaj eldonoj de OpenVPN povas transdoni DNS-agordojn al systemd-resolved anstataŭ reskribi la dosieron, kio estas la kunlabora konduto, kiun vi volas; pli malnovaj skriptoj kaj mane skribitaj hokoj ofte vokas malnovan helpilon aŭ simple anstataŭigas la dosieron.

La situacio de WireGuard similas laŭ formo: la interfaca agordo mem ne administras DNS, tion faras la iloj ĉirkaŭ ĝi, per solvila helpilo aŭ la resolved-integriĝo. Se du tiaj helpiloj estas instalitaj, ambaŭ provos apliki sian bildon de la mondo ĉe konekto.

Legu la supren kaj malsupren hokojn de la kliento anstataŭ diveni. Kelkaj linioj da shell en /etc/openvpn/up.sh aŭ ekvivalenta dosierujo klarigas konduton, kiu alie aspektas hazarda, kaj ili ankaŭ estas la loko, kie vi povas igi la klienton kunlabori anstataŭ konkurenci.

Kontrolo 4: ripari ĝin ĉe la posedanto, ne ĉe la dosiero

Post kiam vi scias la posedanton, agordu DNS tra la subtenata interfaco de tiu posedanto. Por systemd-resolved tio signifas agordojn laŭ ligilo kaj enkursigajn domajnojn anstataŭ statika dosiero; por NetworkManager ĝi signifas la DNS-agordojn de la konekta profilo kaj la elektitan backend-on; por distribuo kun resolvconf-integriĝo ĝi signifas skribi tra tiu helpilo.

Ne faru la dosieron neŝanĝebla. La neŝanĝebla atributo haltigas legitimajn DHCP-renovigojn kaj VPN-ĝisdatigojn kune kun tiuj, kontraŭ kiuj vi batalis, kaj ĝi lasas la sistemon en stato, kie la sekva pakaĝisdatigo aŭ rekonekto produktas fiaskon, kiun neniu povas klarigi el la agordo. Ĝi kaŝas la posedkonflikton, kio estas ĝuste tio, kion vi provis solvi.

Kie du komponantoj vere devas kunekzisti, donu al ili malsamajn taskojn. Lasu la retadministrilon posedi la agordon je interfaca nivelo, lasu la VPN-klienton kontribui DNS kaj domajnojn laŭ ligilo tra la sama integriĝo, kaj forigu la trian skripton, kiu rekte skribas la dosieron. La dokumentaro de systemd-resolved priskribas la reĝimojn, kiujn ĝi subtenas, kaj kion ĉiu el ili montras en /etc/resolv.conf. Elektu la reĝimon, kiu kongruas kun kiom da politiko vi devas konservi. Se split DNS gravas, la stub-aranĝo kun domajnoj laŭ ligilo konservas ĝin, dum la reĝimo, kiu kopias upstream-servilojn en la dosieron, silentigas ĝin.

Kontrolu post rekonekto, ne post la redakto

Dosiero, kiu aspektas ĝusta tuj post via ŝanĝo, pruvas nenion, ĉar la sekva evento ankoraŭ ne okazis. Ekfunkciigu la sinsekvon, kiu antaŭe rompis ĝin: mallevu kaj relevu la tunelon, renovigu la DHCP-luon aŭ ŝaltu la interfacon, kaj poste relegu la samajn valorojn.

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

Poste konfirmu la distingon, kiu gravas: la interna nomo solviĝas tra la interna servilo, dum la publika nomo ankoraŭ funkcias. Agordo, kiu sendas ĉion al la interna servilo, aspektas bone ĝis iu provas atingi la interreton tra la tunelo, kaj agordo, kiu sendas ĉion al la publika, likas internajn nomojn.

Notu la posedanton, la backend-on kaj la simbolligan reĝimon en la deplojaj notoj. Tiu unu alineo transformas estontan pakaĝisdatigon de incidento en revizian eron, kaj ĝi malhelpas la sekvan personon remalkovri la saman konflikton per komando chattr.