Zastavte dve služby Linuxu, ktoré súperia o /etc/resolv.conf

DNS sa stále vracia do pôvodného stavu, opätovné pripojenie VPN ruší vašu opravu a nakoniec niekto v tíme navrhne súbor uzamknúť. Táto postupnosť je príznak, nie riešenie: dve komponenty sa obe domnievajú, že vlastnia /etc/resolv.conf, a vyhráva tá, ktorá zapíše ako posledná. Uzamknutie súboru konflikt vlastníctva nerieši, iba ho skrýva a pritom búra komponent, ktorý ste vlastne chceli. Vykonajte štyri kontroly nižšie v poradí a usporiadanie opravte na úrovni, ktorá ho vlastní, nie na súbore.

Kontrola 1: je to symbolický odkaz a kam

Začnite samotným súborom, pretože cesta, ktorú upravujete, nemusí byť vôbec súbor. Symbolický odkaz do behového adresára resolvera sa správa úplne inak ako obyčajný súbor, ktorý prepisuje klientsky skript:

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

Odkaz na stub cestu systemd-resolved znamená, že obsah súboru sa generuje, a ručná úprava bude pri ďalšej udalosti prepísaná. Obyčajný súbor s riadkami nameserver zvyčajne zapisuje ten klient alebo DHCP hook, ktorý beží pri pripojení. Oboje je legitímne; dôležité je vedieť, ktoré z toho máte, skôr než čokoľvek zmeníte.

Kontrola 2: ktorý démon beží

Zistite, čo je skutočne aktívne, nie čo je nainštalované. V modernej distribúcii môže byť prítomných niekoľko resolverov a odpovedá ten, ktorý drží port 53 na rozhraní loopback:

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

Výstup stavu uvádza DNS servery pre jednotlivé pripojenia a smerovacie domény, čo je mapa, ktorú pre split DNS potrebujete. Ak vnútorné mená musia ísť na vnútorný server a všetko ostatné na verejný, táto politika žije v doménach jednotlivých pripojení, a jej sploštenie do statického zoznamu nameserver v súbore túto odlišnosť ticho stráca.

Vlastná konfigurácia NetworkManageru rozhoduje, ktorý z týchto backendov používa. Jeho nastavenie dns= v hlavnom konfiguračnom súbore volí medzi jeho interným resolverom, dnsmasq, systemd-resolved a none, a distribúcia mohla zvoliť za vás. Prečítajte si toto nastavenie, skôr než rozhodnete, čo „oprava DNS“ na tomto hostiteľovi znamená.

Kontrola 3: čo smie VPN klient zapisovať

Práve tu konflikt zvyčajne žije. VPN klient, ktorý súbor resolvera prepisuje priamo, sa bude biť s každou službou, ktorá ho tiež spravuje, a prehráva ten, kto beží prvý. Nedávne vydania OpenVPN vedia odovzdať nastavenia DNS systemd-resolved namiesto prepisovania súboru, čo je kooperatívne správanie, ktoré chcete; staršie skripty a ručne písané hooky často volajú zastaraný pomocný nástroj alebo súbor jednoducho prepíšu.

Situácia s WireGuardom je tvarovo podobná: konfigurácia rozhrania sama DNS nespravuje, robia to nástroje okolo nej, cez pomocník resolvera alebo integráciu s resolved. Ak sú nainštalovaní dvaja takí pomocníci, obaja sa pri pripojení pokúsia presadiť svoj pohľad na svet.

Čítajte hooky pre zapnutie a vypnutie klienta, namiesto hádania. Niekoľko riadkov shellu v /etc/openvpn/up.sh alebo ekvivalentnom adresári vysvetľuje správanie, ktoré inak vyzerá náhodne, a je to aj miesto, kde môžete klienta prinútiť spolupracovať namiesto súperenia.

Kontrola 4: opravte to u vlastníka, nie v súbore

Keď vlastníka poznáte, nakonfigurujte DNS cez rozhranie, ktoré tento vlastník podporuje. Pre systemd-resolved to znamená nastavenia pre jednotlivé pripojenia a smerovacie domény namiesto statického súboru; pre NetworkManager nastavenia DNS v profile pripojenia a zvolený backend; pre distribúciu s integráciou resolvconf zápis cez tohto pomocníka.

Nerobte súbor nemenným. Atribút nemennosti zastaví legitímne obnovy DHCP a aktualizácie VPN spolu s tými, proti ktorým ste bojovali, a nechá systém v stave, keď ďalší upgrade balíkov alebo opätovné pripojenie vyvolá zlyhanie, ktoré nikto z konfigurácie nevysvetlí. Skrýva konflikt vlastníctva, teda presne to, čo ste sa snažili vyriešiť.

Kde dve komponenty skutočne musia koexistovať, dajte im rôzne úlohy. Nech správca siete vlastní konfiguráciu na úrovni rozhrania, nech VPN klient prispieva DNS a doménami pre jednotlivé pripojenia cez tú istú integráciu, a odstráňte tretí skript, ktorý súbor zapisuje priamo. Dokumentácia systemd-resolved uvádza režimy, ktoré podporuje, a čo každý z nich v /etc/resolv.conf sprístupňuje. Vyberte režim, ktorý zodpovedá množstvu politiky, ktorú potrebujete udržať. Ak záleží na split DNS, stub usporiadanie s doménami pre jednotlivé pripojenia ho zachová, zatiaľ čo režim, ktorý do súboru kopíruje upstream servery, ho ticho splošťuje.

Overujte po opätovnom pripojení, nie po úprave

Súbor, ktorý vyzerá správne hneď po vašej zmene, nič nedokazuje, pretože ďalšia udalosť ešte nenastala. Spustite postupnosť, ktorá ho predtým rozbíjala: zložte a znova zdvihnite tunel, obnovte DHCP lease alebo prepnite rozhranie, a potom znova prečítajte rovnaké hodnoty.

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

Potom potvrďte rozdiel, na ktorom záleží: vnútorné meno sa preloží cez vnútorný server, zatiaľ čo verejné meno stále funguje. Konfigurácia, ktorá posiela všetko na vnútorný server, vyzerá dobre, kým sa niekto nepokúsi dostať tunelom na internet, a konfigurácia, ktorá posiela všetko na verejný, prezrádza vnútorné mená.

Zapíšte vlastníka, backend a režim symbolického odkazu do poznámok k nasadeniu. Ten jediný odsek premení budúci upgrade balíkov z incidentu na položku na revíziu a zabráni ďalšiemu človeku znova objaviť ten istý konflikt príkazom chattr.