Dlaczego OpenVPN umiera po wybudzeniu laptopa?

Uśpienie może zabić sesję OpenVPN i pozostawić tun0. Przetestuj tunel, a następnie uruchom ponownie jednostkę z hooka uśpienia systemd, a nie urządzenie.

Uśpij maszynę, wybudź ją, a następnie zanim dotkniesz jakiejkolwiek konfiguracji, sprawdź trzy rzeczy w tej kolejności: czy tun0 nadal istnieje, czy trasa do adresu wewnętrznego nadal go wybiera i czy serwer nadal wymienia ten peer. Urządzenie, które przetrwa uśpienie, podczas gdy trasa wskazuje gdzie indziej, jest pozostałością, a nie tunelem. Gdy trasa jest poprawna, a ruch mimo to umiera, usterka leży powyżej tunelu i restart klienta tego nie zmieni. Automatyzacja restartu ma sens dopiero po tym, jak ręczny test pokaże, który z tych trzech przypadków masz.

ip -br address show tun0
ip route get 10.20.0.10
journalctl -u openvpn-client@office -b --no-pager | tail -30

Odtwórz wybudzenie, zanim je zautomatyzujesz

Uśpienie częściej kończy zaszyfrowaną sesję, niż usuwa urządzenie. Strumień UDP, który utrzymywał tunel przy życiu, zatrzymuje się, serwer może odrzucić peera, a klient albo to zauważa i łączy się ponownie, albo zachowuje interfejs, za którym nic nie ma. Sama kontrola interfejsu dowodzi niewiele, ponieważ nieaktualne urządzenie wygląda dokładnie jak działające dopóki pakiety nie muszą przez nie przejść. Uruchom wyszukanie trasy plus jedno prawdziwe żądanie przez tunel, a potem przeczytaj dziennik wokół momentu wybudzenia.

Jeśli klient wraca sam, hook dodaje zamieszanie zamiast niezawodności. Jeśli nigdy się nie podnosi, automatyzacja jest uczciwym rozwiązaniem.

Gdzie naprawdę mieszka hook uśpienia systemd

Wiele starszych poradników wskazuje /etc/pm/sleep.d, katalog należący do pm-utils, którego uśpienie oparte na systemd nigdy nie konsultuje. systemd czyta hooki z /usr/lib/systemd/system-sleep/ i /etc/systemd/system-sleep/, przekazując najpierw fazę, a potem operację, więc pre i post to jedyne wartości, na które hook się rozgałęzia. Trzymaj lokalną kopię pod /etc zamiast edytować plik z pakietu i pamiętaj, że skrypt działa jako root w środku przejścia, więc musi szybko wracać.

#!/bin/sh
case "$1" in
  post)
    systemctl --no-block try-restart [email protected]
    ;;
esac
exit 0

try-restart dotyka jednostki tylko wtedy, gdy jest już aktywna, więc tunel, który celowo wyłączyłeś, pozostaje wyłączony przez całe wybudzenie. --no-block powstrzymuje hook przed czekaniem, gdy klient negocjuje, co ma znaczenie, gdy sieć jeszcze nie wstała. Razem oba przełączniki oznaczają hook, który po cichu zawodzi, zamiast wstrzymywać całą sekwencję wybudzenia. Gdy jednostka jest już zatrzymana, nie dzieje się zupełnie nic, i to jest dokładnie ten wynik, którego tam chcesz.

Przywróć usługę, zostaw tun0 w spokoju

Ręczne opuszczenie tun0 zostawia demona pilnującego interfejsu, którego już nie posiada, a następna zmiana stanu daje mylące błędy. Celuj w usługę lub jej profil połączenia, a nie w interfejs; najpierw sprawdź dokładną nazwę jednostki, bo pakiety dystrybucji, OpenVPN 3 i NetworkManager wybierają różne. Profil NetworkManager wraca, gdy to połączenie zostanie przetworzone ponownie, więc jednostka systemd nie jest tam celem. Czymkolwiek jest mechanizm, powinna to być ta sama czynność, którą zweryfikowałeś ręcznie.

Restart instaluje ponownie trasy, które klient wypchnął przy połączeniu. Większość wybudzeń tego chce. Maszyna, w której dodałeś własne ścieżki, nie, więc sprawdź je ponownie, zamiast zakładać, że odzyskiwanie je przywróciło, i zapisz je tam, gdzie następne wybudzenie może je znaleźć.

Poradź sobie z czasem, którego nie kontrolujesz

Połączenie bezprzewodowe i DHCP często kończą się po uruchomieniu hooka, więc restart może się nie udać, gdy nie ma jeszcze drogi do serwera. Poczekaj chwilę na ten adres, spróbuj jeszcze raz i zapisz wynik.

Rozwiązywanie nazw to osobny wyścig, ponieważ stos sieciowy pulpitu może przywrócić DNS już po podniesieniu tunelu. Testuj zapytania osobno z resolvectl query internal.example, zamiast wnioskować o nich z działającej trasy. Tunel, który poprawnie routuje i niczego nie rozwiązuje, to problem DNS, a nie problem hooka.

Utrzymuj decyzję hooka widoczną, zapisując fazę, nazwę jednostki i wynik w dzienniku. Zanotuj w notatkach maszyny, który test wybudzenia przeprowadziłeś, aby działające odzyskanie dało się odróżnić od szczęśliwego. Wybierz najmniej zakłócającą czynność, która przywraca usługę, i pozwól klientowi, który podnosi się sam, zrobić to. Pełny restart zrywa sesje w toku, co jest realnym kosztem na laptopie, który budzi się kilka razy dziennie.

Powiązane artykuły