OpenVPN ponawia próby po błędzie TLS: jak to zatrzymać

Klient łączy się, ponosi porażkę podczas negocjacji TLS, czeka i ponownie próbuje tego samego serwera z tym samym wynikiem. Pod nadzorcą, który restartuje nieudany proces, te próby stają się nieskończoną pętlą w dzienniku, a pierwsza linia diagnostyczna znika z zasięgu. OpenVPN ma opcję, która zamienia tę porażkę negocjacji w widoczne zakończenie zamiast kolejnej próby. To ustawienie diagnostyki i nadzoru, a nie naprawa, więc połącz je z polityką, która naprawdę pozwala procesowi pozostać zatrzymanym.

Cykl, który ukrywa pierwszy błąd

To, co widzisz, to powtarzający się blok, a nie jedna awaria: próba połączenia, błąd TLS, pauza i potem ta sama sekwencja. Każde powtórzenie wypycha pierwotną linię wyżej w dzienniku. Jeśli jednostka restartuje się przy awarii, cykl może trwać godzinami, zanim ktokolwiek przeczyta przyczynę. Objawem jest pętla, choć zasadniczą usterką jest jeden problem negocjacji.

Sesje interaktywne to znoszą, bo przejściowa awaria może zniknąć przy następnej próbie. Połączenia automatyczne nie mogą pozwolić sobie na taki sam optymizm: proces musi się zatrzymać, aby człowiek lub monitor zobaczył stan.

Zanim cokolwiek zmienisz, zapisz jeden pełny cykl. Zanotuj zdalny adres, etap TLS wskazany w błędzie i to, czy proces w ogóle się kończy.

Mechanizm ponawiania za pętlą

Ponawianie jest domyślne, ponieważ kilka niepowiązanych limitów czasu używa tego samego mechanizmu. connect-retry ustala odstęp między próbami połączenia, connect-retry-max może ograniczyć, jak często próbowany jest każdy zdalny wpis, a resolv-retry kontroluje powtarzane wyszukiwania nazw. Porażka negocjacji TLS dociera do tego mechanizmu jako zdarzenie transportowe, więc klient planuje kolejną próbę zamiast raportować. Wartość domyślna pomaga przy niestabilnym łączu i szkodzi przy usterce, której nie można wyleczyć.

Opcja --tls-exit zmienia tylko przypadek negocjacji. Podręcznik opisuje ją jako zakończenie przy porażce negocjacji TLS, co jest węższe niż zakończenie przy każdym błędzie. Limity czasu, awarie resolvera i odrzucenia uwierzytelniania zachowują własne zachowanie.

Spraw, by klient kończył się przy awarii TLS

Umieść tls-exit w profilu, który klient naprawdę ładuje, albo podaj --tls-exit przy uruchamianiu, i uruchom go raz na pierwszym planie. Czytaj status wyjścia i ostatnią linię logu, bo to na status reaguje nadzorca. Wyjście niezerowe po porażce negocjacji to zamierzony wynik. Jeśli proces dalej próbuje zamiast się kończyć, opcji nie ma w profilu, który klient naprawdę ładuje.

Nadzorca decyduje, czy to wyjście jest widoczne. Jednostka systemd z Restart=always lub Restart=on-failure uruchamia klienta ponownie, więc pętla trwa, a opcja wygląda, jakby nic nie robiła. Sprawdź politykę, zanim obwinisz klienta:

systemctl show -p Restart -p RestartSec openvpn-client@office
journalctl -u openvpn-client@office -n 40 --no-pager

Restart=no pozwala procesowi pozostać zatrzymanym, a Restart=on-failure nadal restartuje po niezerowym statusie. Jeśli chcesz, aby awaria była widoczna, ale usługa podnosiła się po niepowiązanych awariach, ustaw Restart=on-failure i użyj StartLimitBurst oraz StartLimitIntervalSec, aby zatrzymać burzę restartów. Następnie odczytaj status jednostki, aby potwierdzić ostatni kod wyjścia: systemctl status zgłasza go, a dziennik zachowuje pierwszy błąd nad restartami.

Zapisz decyzję w jednostce lub w notatkach profilu. Profil, który kończy się przy awarii TLS, wygląda dla następnej osoby jak wypadek, chyba że przyczyna jest zapisana. Wskaż, które awarie mają zatrzymać proces, a które należy ponowić.

Udowodnij to jednorazowym punktem końcowym

Aby zobaczyć zachowanie, zanim mu zaufasz, skopiuj profil i skieruj kopię do punktu końcowego, który przyjmuje połączenie TCP, ale nigdy nie mówi OpenVPN. Wystarczy nasłuchujący, który odpowie i potem zamilknie. Z tls-exit klient powinien zakończyć się, gdy uścisk dłoni zawiedzie; bez tej opcji ten sam profil powinien dalej krążyć. Używaj kopii, nigdy działającego profilu.

Porównaj oba uruchomienia według statusu wyjścia i pierwszej linii błędu, a nie według tego, jak długo trwało każde. Status mówi, czy opcja zadziałała, a pierwsza linia mówi, który etap zawiódł.

Usuń profil testowy, gdy skończysz. Kopia z celowo błędnym punktem końcowym to pułapka dla każdego, kto później uruchomi każdy profil w katalogu.

Etapy, do których ta opcja nigdy nie dociera

Odrzucenie uwierzytelniania to późniejszy etap. Jeśli serwer oceni konto i je odrzuci, TLS jest już wynegocjowany, więc tls-exit nie zadziała. Ustawienia ponawiania uwierzytelniania to następne miejsce do sprawdzenia, a przyczyna serwera waży więcej niż ostatnia linia klienta. Błędne hasło i brakujący certyfikat mogą dawać podobne komunikaty po stronie klienta.

Brakująca trasa, zły resolver lub nieosiągalna brama też są poza tą opcją, bo nie są porażkami negocjacji. Cicha utrata pakietów to najmniej oczywisty przypadek: w zależności od tego, jak daleko zaszła wymiana, klient może zgłosić porażkę negocjacji albo po prostu przekroczyć limit czasu.

Zachowaj to rozróżnienie w notatkach. Ustawienie służy diagnostyce i nadzorowi, a nie naprawie, więc nie usuwa niezgodności szyfru, problemu z certyfikatem ani złego portu. Najpierw usuń przyczynę nieudanej negocjacji, potem zdecyduj, czy natychmiastowe zakończenie nadal pasuje do wdrożenia.