Zastavte dvě služby Linuxu, které soupeří o /etc/resolv.conf

DNS se stále vrací do původního stavu, opětovné připojení VPN maže vaši opravu a někdo v týmu nakonec navrhne soubor zamknout. Tahle posloupnost je symptom, ne řešení: dvě komponenty se obě domnívají, že vlastní /etc/resolv.conf, a vyhrává ta, která zapíše jako poslední. Zamčení souboru konflikt vlastnictví neřeší, jen ho skrývá, a přitom bourá komponentu, kterou jste vlastně chtěli. Proveďte čtyři kontroly níže v pořadí a uspořádání opravte na úrovni, která ho vlastní, ne na souboru.

Kontrola 1: je to symbolický odkaz a kam

Začněte samotným souborem, protože cesta, kterou upravujete, nemusí být vůbec soubor. Symbolický odkaz do běhového adresáře resolveru se chová úplně jinak než obyčejný soubor, který přepisuje klientský skript:

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

Odkaz na stub cestu systemd-resolved znamená, že obsah souboru se generuje, a ruční úprava bude při další události přepsána. Obyčejný soubor s řádky nameserver obvykle zapisuje ten klient nebo DHCP hook, který běží při připojení. Obojí je legitimní; důležité je vědět, které z toho máte, než cokoli změníte.

Kontrola 2: který daemon běží

Zjistěte, co je skutečně aktivní, ne co je nainstalované. V moderní distribuci může být přítomno několik resolverů a odpovídá ten, který drží port 53 na rozhraní loopback:

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

Výstup stavu uvádí DNS servery pro jednotlivá připojení a směrovací domény, což je mapa, kterou pro split DNS potřebujete. Pokud vnitřní jména musí jít na vnitřní server a vše ostatní na veřejný, tato politika žije v doménách jednotlivých připojení, a její zploštění do statického seznamu nameserver v souboru tuto distinkci tiše ztrácí.

Vlastní konfigurace NetworkManageru rozhoduje, který z těchto backendů používá. Jeho nastavení dns= v hlavním konfiguračním souboru volí mezi jeho interním resolverem, dnsmasq, systemd-resolved a none, a distribuce mohla zvolit za vás. Přečtěte si toto nastavení, než rozhodnete, co „oprava DNS“ na tomto hostiteli znamená.

Kontrola 3: co smí VPN klient zapisovat

Právě tady konflikt obvykle žije. VPN klient, který soubor resolveru přepisuje přímo, se bude přít s každou službou, která ho také spravuje, a prohrává ten, kdo běží první. Nedávná vydání OpenVPN umějí předat nastavení DNS systemd-resolved místo přepisování souboru, což je kooperativní chování, které chcete; starší skripty a ručně psané hooky často volají zastaralý pomocný nástroj nebo soubor prostě přepíšou.

Situace s WireGuardem je tvarově podobná: konfigurace rozhraní sama DNS nespravuje, dělají to nástroje kolem ní, přes pomocník resolveru nebo integraci s resolved. Pokud jsou nainstalováni dva takoví pomocníci, oba se při připojení pokusí prosadit svůj pohled na svět.

Čtěte hooky pro zapnutí a vypnutí klienta, místo abyste hádali. Několik řádků shellu v /etc/openvpn/up.sh nebo ekvivalentním adresáři vysvětluje chování, které jinak vypadá náhodně, a je to také místo, kde můžete klienta přimět spolupracovat místo soupeřit.

Kontrola 4: opravte to u vlastníka, ne v souboru

Jakmile vlastníka znáte, nakonfigurujte DNS přes rozhraní, které tento vlastník podporuje. Pro systemd-resolved to znamená nastavení pro jednotlivá připojení a směrovací domény místo statického souboru; pro NetworkManager to znamená nastavení DNS v profilu připojení a zvolený backend; pro distribuci s integrací resolvconf to znamená zápis přes tohoto pomocníka.

Nedělejte soubor neměnným. Atribut neměnnosti zastaví legitimní obnovy DHCP a aktualizace VPN spolu s těmi, proti kterým jste bojovali, a nechá systém ve stavu, kdy další upgrade balíčků nebo opětovné připojení vyvolá selhání, které nikdo z konfigurace nevysvětlí. Skrývá konflikt vlastnictví, tedy přesně to, co jste se snažili vyřešit.

Kde dvě komponenty skutečně musí koexistovat, dejte jim různé úkoly. Ať správce sítě vlastní konfiguraci na úrovni rozhraní, ať VPN klient přispívá DNS a doménami pro jednotlivá připojení přes stejnou integraci, a odstraňte třetí skript, který soubor zapisuje přímo. Dokumentace systemd-resolved uvádí režimy, které podporuje, a co každý z nich v /etc/resolv.conf zpřístupňuje. Vyberte režim, který odpovídá množství politiky, jež potřebujete udržet. Pokud záleží na split DNS, stub uspořádání s doménami pro jednotlivá připojení ho zachová, zatímco režim, který do souboru kopíruje upstream servery, ho tiše zplošťuje.

Ověřujte po opětovném připojení, ne po úpravě

Soubor, který vypadá správně hned po vaší změně, nic nedokazuje, protože další událost ještě nenastala. Spusťte posloupnost, která ho dřív rozbíjela: sundejte a znovu zvedněte tunel, obnovte DHCP lease nebo přepněte rozhraní, a pak znovu přečtěte stejné hodnoty.

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

Potom potvrďte rozdíl, na kterém záleží: vnitřní jméno se přeloží přes vnitřní server, zatímco veřejné jméno stále funguje. Konfigurace, která posílá vše na vnitřní server, vypadá dobře, dokud se někdo nepokusí dostat tunelem na internet, a konfigurace, která posílá vše na veřejný, prozrazuje vnitřní jména.

Zapište vlastníka, backend a režim symbolického odkazu do poznámek k nasazení. Ten jediný odstavec promění budoucí upgrade balíčků z incidentu v položku k revizi a zabrání dalšímu člověku znovu objevit stejný konflikt příkazem chattr.