Dlaczego klient OpenVPN zostaje wyłączony po jednym przekroczeniu limitu czasu

Poniedziałkowy poranek: tunel, który powstał w piątek, zniknął, interfejs nadal jest na liście, a w dzienniku nie ma nic o tym, że ktoś to zauważył. Host jest online, pulpit jest zielony, a wszystko, co wysłał przez weekend, wyszło przez interfejs fizyczny. Brakuje tu dwóch niezależnych decyzji: jednej o tym, czy proces klienta przetrwa chwilową awarię, i drugiej o tym, czy coś nad nim uruchomi proces ponownie po jego zakończeniu. Naprawienie tylko jednej zostawia drugą lukę otwartą.

Zacznij od tego, co jednostka naprawdę zrobiła, a nie od tego, co twierdzi monitoring. systemctl status openvpn-client@office i journalctl -u openvpn-client@office -n 50 pokazują powód zakończenia i ostatnią linię, którą klient zapisał przed odejściem.

Proces zakończył się, zanim ktokolwiek to zauważył

Klient, który znika bez błędu, zwykle zakończył się celowo. To zachowanie określa profil, a nie menedżer usług: ping-exit kończy proces, gdy tylko druga strona przestaje odpowiadać, natomiast ping-restart zachowuje proces i ponownie łączy się w jego wnętrzu. Limity sesji i liczniki bezczynności dają z zewnątrz ten sam obraz: bez tunelu i bez alarmu.

Dwie dyrektywy ping nie mogą występować razem w jednym profilu, więc wybierz jedną i zapisz wybór. Spójrz też na serwer, bo jego własny ping-exit zamyka sesję niezależnie od tego, o co prosił klient, a tylko dziennik serwera zapisuje, kto podjął tę decyzję.

Wybór między ping-exit i ping-restart

Wybierz ping-restart dla laptopa lub zdalnej lokalizacji, która ma się sama wyleczyć, a ping-exit zachowaj na przypadki, gdy martwy tunel musi zatrzymać proces, aby coś innego mogło na niego zareagować. Liczby są mniej ważne niż relacja: ping 10 z ping-restart 60 oznacza dziesięć sekund ciszy przed sondowaniem i sześćdziesiąt przed restartem, co jest agresywne na tracącym łączu mobilnym, a rozsądne na kablowym. Zapisz powód obok linii, bo inaczej następny czytelnik uzna, że wartości domyślne były zamierzone.

Następnie potwierdź, że to naprawdę proces zakończył się. Jednostka, która zgłasza aktywność, gdy tunel jest martwy, to inna awaria, omówiona niżej.

Nadzór, który naprawdę restartuje jednostkę

Na hoście systemd najmniejszą trwałą zmianą jest jeden plik drop-in: Restart=on-failure i RestartSec=10 w /etc/systemd/system/[email protected]/restart.conf. Drop-in jest czytany tylko wtedy, gdy systemd ponownie wczytuje własne definicje, więc uruchom potem systemctl daemon-reload. Sprawdź za pomocą systemctl show -p Restart -p ExecMainStatus openvpn-client@office, zamiast zakładać, że wartość dotarła. Instancja w nazwie pliku musi być profilem, który jednostka naprawdę ładuje, więc plik napisany dla office nic nie robi dla openvpn-client@home.

on-failure ignoruje jeden przypadek: czyste zakończenie ze statusem zero. Niektóre ścieżki demontażu kończą się tak, więc czytaj zapisany status, zamiast ufać sformułowaniu strony podręcznika. Jeśli twój klient poddaje się z zerem, potrzebujesz Restart=always, a ceną jest to, że naprawdę zepsuty profil wraca raz za razem, aż zadziała limit szybkości uruchamiania i dziennik się zapełni.

Restart=always uruchamia się także po celowym zatrzymaniu. Użyj systemctl stop do konserwacji i zamaskuj jednostkę, jeśli ma pozostać wyłączona podczas twojej pracy.

Złap wyciek, gdy tunel jest wyłączony

Nadzór przywraca tunel; nie powstrzymuje ruchu przed wyjściem, gdy tunelu nie ma. persist-tun utrzymuje urządzenie i jego trasy między ponownymi połączeniami, co jest wygodne i otwiera okno. Urządzenie przeżywa, trasy nadal na nie wskazują, a pakiety wyciekają niechronione i niezgłoszone. To wybór polityki, a nie neutralna wartość domyślna.

Gdy host w ogóle nie może wysyłać niechronionych pakietów, może to zagwarantować tylko zapora. Reguła wyjściowa, która pozwala na interfejs tunelu i adres serwera VPN, a wszystko inne odrzuca, obowiązuje nadal po śmierci klienta, i nic w konfiguracji samego klienta nie może filtrować ruchu, którego klient nie przenosi.

Sprawdź to, celowo zatrzymując klienta. Uruchom systemctl stop openvpn-client@office, potem curl -m 5 https://example.com, który powinien zawieść, a nie powieść się przez łącze fizyczne. Sukces oznacza, że brakuje reguły zapory albo jest zbyt permisywna.

Połącz się ponownie, potwierdź, że tunel znów przenosi ruch, i dopiero wtedy dodaj sprawdzenie do monitoringu. Odpytywanie ip addr z cron dla urządzenia tun to nadzór, który zawodzi najczęściej, bo z persist-tun urządzenie żyje dłużej niż sesja, a sonda zgłasza zdrowie, gdy nic nie jest przenoszone.