Zatrzymaj dwie usługi Linuksa walczące o /etc/resolv.conf

DNS wciąż wraca do poprzedniego stanu, ponowne połączenie VPN cofa twoją poprawkę, a w końcu ktoś z zespołu proponuje zablokowanie pliku. Ta sekwencja jest objawem, nie rozwiązaniem: dwa komponenty oba uważają, że posiadają /etc/resolv.conf, i wygrywa ten, kto pisze ostatni. Zablokowanie pliku nie rozwiązuje konfliktu własności, tylko go ukrywa, psując przy tym komponent, którego naprawdę chciałeś. Wykonaj cztery kontrole poniżej po kolei i napraw układ na poziomie, który jest jego właścicielem, a nie w pliku.

Kontrola 1: czy to dowiązanie symboliczne i dokąd

Zacznij od samego pliku, bo ścieżka, którą edytujesz, może wcale nie być plikiem. Dowiązanie symboliczne do katalogu roboczego resolvera zachowuje się zupełnie inaczej niż zwykły plik, który przepisuje skrypt klienta:

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

Dowiązanie do ścieżki stub systemd-resolved oznacza, że zawartość pliku jest generowana, a ręczna edycja zostanie nadpisana przy następnym zdarzeniu. Zwykły plik z liniami nameserver zwykle zapisuje klient lub hook DHCP uruchamiany przy połączeniu. Oba są legalne; ważne jest, aby wiedzieć, który masz, zanim cokolwiek zmienisz.

Kontrola 2: który demon działa

Sprawdź, co jest naprawdę aktywne, a nie co jest zainstalowane. W nowoczesnej dystrybucji może być obecnych kilka resolverów, a odpowiada ten, który trzyma port 53 na interfejsie loopback:

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

Wyjście statusu wymienia serwery DNS dla poszczególnych połączeń i domeny routingu, a to jest mapa potrzebna do split DNS. Jeśli nazwy wewnętrzne mają trafiać do serwera wewnętrznego, a wszystko inne do publicznego, ta polityka żyje w domenach poszczególnych połączeń, a spłaszczenie jej do statycznej listy nameserver w pliku po cichu gubi tę różnicę.

Własna konfiguracja NetworkManagera decyduje, którego z tych backendów używa. Ustawienie dns= w głównym pliku konfiguracyjnym wybiera między jego wewnętrznym resolverem, dnsmasq, systemd-resolved i none, a dystrybucja mogła wybrać za ciebie. Przeczytaj to ustawienie, zanim zdecydujesz, co oznacza „naprawianie DNS” na tym hoście.

Kontrola 3: co klient VPN może zapisywać

Tu zwykle żyje konflikt. Klient VPN, który bezpośrednio przepisuje plik resolvera, będzie walczył z każdą usługą, która również go utrzymuje, a przegrywa ten, który uruchamia się pierwszy. Najnowsze wersje OpenVPN mogą przekazać ustawienia DNS do systemd-resolved zamiast przepisywać plik, i to jest pożądane zachowanie kooperacyjne; starsze skrypty i ręcznie pisane hooki często wywołują przestarzałe narzędzie pomocnicze albo po prostu nadpisują plik.

Sytuacja WireGuarda jest podobna pod względem formy: sama konfiguracja interfejsu nie zarządza DNS, robią to narzędzia wokół niej, przez pomocnik resolvera lub integrację z resolved. Jeśli zainstalowane są dwa takie pomocniki, oba spróbują narzucić swój obraz świata przy połączeniu.

Czytaj hooki up i down klienta, zamiast zgadywać. Kilka linii shell w /etc/openvpn/up.sh lub równoważnym katalogu wyjaśnia zachowanie, które inaczej wygląda na losowe, i tam też można skłonić klienta do współpracy zamiast rywalizacji.

Kontrola 4: napraw to u właściciela, nie w pliku

Gdy znasz właściciela, skonfiguruj DNS przez obsługiwany przez niego interfejs. Dla systemd-resolved oznacza to ustawienia dla poszczególnych połączeń i domeny routingu zamiast statycznego pliku; dla NetworkManagera ustawienia DNS profilu połączenia i wybrany backend; dla dystrybucji z integracją resolvconf zapis przez ten pomocnik.

Nie czyń pliku niezmiennym. Atrybut niezmienności zatrzymuje legalne odnowienia DHCP i aktualizacje VPN wraz z tymi, z którymi walczyłeś, i pozostawia system w stanie, w którym następna aktualizacja pakietów lub ponowne połączenie powoduje awarię, której nikt nie potrafi wyjaśnić na podstawie konfiguracji. Ukrywa konflikt własności, czyli dokładnie to, co próbowałeś rozwiązać.

Tam, gdzie dwa komponenty naprawdę muszą współistnieć, daj im różne zadania. Pozwól menedżerowi sieci posiadać konfigurację na poziomie interfejsu, pozwól klientowi VPN wnosić DNS i domeny dla poszczególnych połączeń przez tę samą integrację, i usuń trzeci skrypt, który bezpośrednio zapisuje plik. Dokumentacja systemd-resolved opisuje obsługiwane tryby i to, co każdy z nich udostępnia w /etc/resolv.conf. Wybierz tryb odpowiadający ilości polityki, którą musisz zachować. Jeśli split DNS ma znaczenie, układ stub z domenami dla poszczególnych połączeń go zachowuje, podczas gdy tryb kopiujący serwery nadrzędne do pliku po cichu go spłaszcza.

Weryfikuj po ponownym połączeniu, nie po edycji

Plik, który wygląda poprawnie zaraz po twojej zmianie, niczego nie dowodzi, bo następne zdarzenie jeszcze nie nastąpiło. Wywołaj sekwencję, która kiedyś go psuła: opuść i podnieś tunel, odnow dzierżawę DHCP lub przełącz interfejs, a potem odczytaj ponownie te same wartości.

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

Następnie potwierdź różnicę, która ma znaczenie: nazwa wewnętrzna jest rozwiązywana przez serwer wewnętrzny, a nazwa publiczna nadal działa. Konfiguracja, która wysyła wszystko do serwera wewnętrznego, wygląda dobrze, dopóki ktoś nie spróbuje dostać się do internetu przez tunel, a konfiguracja wysyłająca wszystko do publicznego ujawnia nazwy wewnętrzne.

Zapisz właściciela, backend i tryb dowiązania symbolicznego w notatkach wdrożeniowych. Ten jeden akapit zamienia przyszłą aktualizację pakietów z incydentu w punkt do przeglądu i powstrzymuje następną osobę przed ponownym odkryciem tego samego konfliktu poleceniem chattr.