Zabity openconnect: trasy i DNS nadal wskazują na tunel

Tunel jest wyłączony, ale maszyna nadal zachowuje się, jakby był włączony: zapytanie wisi, aż upłynie limit czasu, a trasa wskazuje interfejs, który już nie istnieje. To sygnatura procesu openconnect, który zginął, nie uruchamiając swojego pomocnika rozłączania. Stan sieci, który utworzył, jest nadal zainstalowany, i nic innego w systemie nie wie, jak go usunąć.

Przejdź maszynę w kolejności, w jakiej powstał stan: proces, łącze, trasa, resolver. Każdy krok mówi, czy klient naprawdę zniknął, czy tylko odłączył się od terminala, i ta różnica decyduje, czy w ogóle cokolwiek naprawiać.

Zacznij od procesu, nie od konfiguracji

Otwórz terminal i zapytaj, co jeszcze działa, zanim dotkniesz trasy. pgrep -a openconnect wypisuje każdą instancję wraz z jej argumentami, co pokazuje plik pid i skrypt, który jej dano. Proces, którego się nie spodziewałeś, wyjaśnia widmowy tunel szybciej niż jakikolwiek log.

Jeśli nic nie działa, spójrz na łącze. ip link show tun0 mówi, czy interfejs przetrwał, i ip route show dev tun0 wypisuje trasy nadal z nim związane. Następnie sprawdź resolver za pomocą resolvectl status. Zapisz wszystkie trzy wyniki, zanim je zmienisz, ponieważ właśnie ten zapis pozwala później odróżnić nieaktualny wpis od nowego.

Interfejs, który znika, zwykle zabiera ze sobą swoje trasy. Trasy, które przetrwały łącze, zwykle oznaczają, że proces nadal żyje albo że urządzenie należy do drugiego klienta.

To skrypt pomocniczy cofa zmiany

openconnect sam nie usuwa interfejsu, tras ani wpisów resolvera. Wywołuje zewnętrznego pomocnika, /etc/vpnc/vpnc-script w kompilacji upstream i /usr/share/vpnc-scripts/vpnc-script w pakietach Debian i Ubuntu, wybieranego za pomocą -s. Ten sam skrypt, który stawia tunel, jest tym, który go rozbiera.

Jeśli proces zakończy się bez wywołania tego pomocnika, stan pozostaje. Podręcznik OpenConnect wyraźnie stwierdza, że routing i usługa nazw nie będą działać poprawnie bez skryptu, i opisuje pomocnika jako komponent, który przy wyjściu rozbiera stan interfejsu. Dlatego ścieżka ma znaczenie, gdy uruchamiasz klienta z -s.

Który sygnał dociera do tej ścieżki, zmieniło się między wersjami. Podręcznik wersji 7.06 traktuje SIGTERM jako natychmiastowe wyjście, które pomija skrypt. Obecne kompilacje dokumentują INT i TERM jako czyste zatrzymanie, w którym sesja jest wylogowywana, a pomocnik działa. Czytaj sekcję SIGNALS tego pliku binarnego, który naprawdę masz, zamiast zakładać jedno z dwóch zachowań.

man openconnect | sed -n '/^SIGNALS/,/^LIMITATIONS/p'

Wyślij sygnał, który dokumentuje Twoja kompilacja

Gdy znasz sygnał, zatrzymaj proces według pid, a nie według wzorca.

pgrep -a openconnect
sudo kill -INT "$(cat /var/run/openconnect.pid)"

Następnie powtórz trzy kontrole z pierwszej części, zamiast ufać statusowi wyjścia. ip link show tun0 powinno się nie udać, ip route show dev tun0 nie powinno nic wypisywać, i resolvectl status nie powinno już wyświetlać łącza VPN.

SIGHUP nie jest przyciskiem stop: rozłącza, uruchamia skrypt i pozostawia sesję wznawialną z --cookie. SIGUSR2 wymusza natychmiastowe ponowne połączenie. SIGKILL całkowicie pomija sprzątanie, i dokładnie o tym stanie jest ten artykuł.

Napraw resolver bez zastępowania resolv.conf

W większości systemów Ubuntu /etc/resolv.conf jest dowiązaniem symbolicznym do systemd-resolved, a nie plikiem, który powinieneś edytować. Zastąpienie go psuje rozwiązywanie nazw dla każdej sieci, nie tylko VPN. Zamiast tego usuń rejestrację tunelu:

resolvectl revert tun0
resolvectl query example.com

Jeśli system używa resolvconf zamiast systemd-resolved, wpis dla interfejsu pozostaje, dopóki nie każe mu się zwolnić łącza, i resolvconf -d tun0 jest równoważnym działaniem. Sprawdź, który resolver jest używany, zanim wybierzesz polecenie.

Zapytanie wciąż skierowane do serwera za martwym łączem wisi, aż upłynie limit czasu, a to opóźnienie wygląda jak zepsuty serwer DNS, a nie pozostała trasa.

Uczyń następne rozłączenie nudnym

Utrzymuj tę samą ścieżkę pliku pid przy starcie i wyłączaniu, przekazując --pid-file za każdym razem, albo uruchom openconnect pod unittem którego KillSignal odpowiada sygnałowi, który dokumentuje Twoja wersja. Testowanie najpierw na pierwszym planie pokazuje komunikaty wyłączania, które wypisuje pomocnik.

Połącz się, rozłącz i uruchom trzy kontrole raz. Czyste wyjście nie zostawia ani łącza VPN, ani trasy VPN, ani wpisu resolvera VPN. Jeśli jedna z trzech przetrwa, wiesz już, który komponent nie posprzątał. Kolejne dochodzenie zaczyna się wtedy od tej odpowiedzi, a nie od wiszącego zapytania.