DNS OpenVPN zostaje po SIGKILL: najpierw sprawdź właściciela

DNS przestaje rozwiązywać nazwy po zabiciu klienta OpenVPN, a pierwszym odruchem jest przepisanie /etc/resolv.conf. Ta zmiana może zepsuć działający resolver, podczas gdy prawdziwy nieaktualny stan jest gdzie indziej. Pierwsze pytanie brzmi, kto zarządza ustawieniami DNS zainstalowanymi przez tunel i czy wyjście, które pominęło sprzątanie, naprawdę miało znaczenie.

Trzy warunki decydują o naprawie: sygnał, który zakończył proces, komponent resolvera, który otrzymał ustawienia, oraz to, czy łącze tunelu nadal istnieje. Odpowiedz w tej kolejności, a poprawka zwykle przychodzi bez dotykania globalnego pliku.

Ustal, jaki rodzaj zakończenia nastąpił

W wydaniu Community OpenVPN zarówno SIGINT, jak i SIGTERM są prośbami o czyste zakończenie. SIGKILL nie da się przechwycić: nie można go zablokować ani obsłużyć, więc żadna procedura wyłączania nie ma szansy się uruchomić. Zwykłe Ctrl+C w terminalu na pierwszym planie generuje SIGINT, a nadzorca, który przestaje czekać, zwykle eskaluje do SIGKILL. Różnica ma znaczenie, bo tylko drugi przypadek gwarantuje, że haki zostały pominięte.

Uruchamianie w screen lub tmux nie zmienia tego, jaki sygnał wysyła Ctrl+C. Sprawdź, co proces faktycznie otrzymał, a nie co zwykle robi terminal.

Gdy tunel uruchamia usługa lub menedżer połączeń, zatrzymaj to jedno połączenie przez jego właściciela, zamiast zabijać pid. Menedżer może ponownie podnieść proces, zostawiając ci nowy tunel i mylący stan resolvera. Samodzielny proces potrzebuje tylko zwykłego żądania zakończenia, aby sprzątanie zostało wykonane.

Ustal, kto zarządza resolverem

systemd-resolved, skrypt w stylu resolvconf i zwykłe przepisanie pliku to trzej różni właściciele. Pierwszy trzyma ustawienia dla łącza w pamięci i odrzuca je, gdy interfejs znika. Drugi trzyma wpisy, które pozostają, dopóki coś ich nie usunie. Trzeci zapisuje plik i zostawia przywracanie temu, kto go zapisał.

Zidentyfikuj właściciela, zanim wybierzesz polecenie naprawcze. Ten sam objaw ma trzy różne poprawne odpowiedzi w zależności od tego, który jest używany.

VPN zarządzany przez NetworkManager może już zarządzać zmianami resolvera. Dodanie drugiego pomocnika na wierzchu tworzy dwóch właścicieli konkurujących o to samo łącze, a stan przegranego wraca przy następnym ponownym połączeniu. Jeśli odpowiedzialny jest menedżer, popraw ustawienie w menedżerze, a nie w skrypcie.

Co hak down może, a czego nie może

Skrypt down uruchamia się raz po zamknięciu urządzenia TUN/TAP. Dodanie down-pre odwraca tę kolejność i uruchamia skrypt, gdy urządzenie jeszcze istnieje, czego wymagają pomocnicy potrzebujący aktywnego łącza.

Żadna z dyrektyw nie sprawia, że hak uruchamia się po SIGKILL. Uprawnienia również nie są przywracane przez down-pre: jeśli demon zejdzie do user lub group albo wejdzie do chroot, hak działa z dostępem, jaki to mu pozostawi. Wywołany hak nadal może nie zdołać zaktualizować resolvera. Dokumentacja OpenVPN omawia sygnały i cykl życia wywołania zwrotnego.

Sprawdź błąd samego haka obok statusu wyjścia procesu. Brak sprzątania i nieudane sprzątanie wyglądają tak samo w resolverze, a różnie w logach.

Sprawdź stan, który naprawdę pozostaje

W systemie używającym systemd-resolved resolvectl status pokazuje, które łącze nadal przenosi serwery DNS VPN lub domeny routingu. To łącze może należeć do połączenia, którego już nie ma, albo do innego tunelu, który nadal działa.

Interfejs, który znika, zabiera ze sobą swoją konfigurację dla łącza, więc pominięty hak może współistnieć z czystym DNS. Jeśli łącze jest nadal zarejestrowane i należy wyłącznie do zatrzymanego połączenia, menedżer będący właścicielem powinien je usunąć. Jeśli starszy skrypt przepisał globalny plik resolvera, poszukaj zamiast tego udokumentowanego kroku przywracania tego skryptu.

Odzyskaj bez kradzieży innego łącza

Gdy ustawienia dla łącza są pod twoim zarządzaniem, resolvectl revert pobiera nazwę łącza i czyści konfigurację DNS w czasie działania dla tego interfejsu. To działanie w czasie działania, a nie edycja profilu, więc trwała konfiguracja połączenia pozostaje nietknięta. Wskaż złe łącze, a wyczyścisz DNS działającego tunelu, dlatego nazwa pochodzi z wyniku statusu.

Zanim go edytujesz, potwierdź, że /etc/resolv.conf jest zarządzanym dowiązaniem symbolicznym, następnie zatrzymaj klienta normalnie jeszcze raz i spójrz ponownie na DNS. Jeśli drugie zatrzymanie sprząta, wcześniejszym problemem było wymuszone wyjście, a nie konfiguracja.