Godzinne zerwanie OpenVPN: renegocjacja czy prawdziwe ponowne połączenie?

Sześćdziesiąt minut, albo trzydzieści, albo sto dwadzieścia: zerwanie, które wypada w okrągłym interwale, prawie nigdy nie jest siecią. OpenVPN odświeża zgodnie z licznikiem materiał kluczy chroniący kanał danych, a krótszy niż zakładany licznik wygląda dokładnie jak łącze, które ciągle zawodzi. Użytkownicy zgłaszają zerwane połączenie, podczas gdy log zgłasza udaną wymianę kluczy. Poniższa instrukcja oddziela to odświeżenie od prawdziwego restartu, odczytuje wartość faktycznie obowiązującą i zmienia ją dopiero wtedy, gdy koszt leży na stole.

Wykonuj kroki po kolei, bo pierwszy decyduje, czy reszta strony w ogóle cię dotyczy. Jeśli przeskoczysz naprzód, spędzisz wieczór na strojeniu licznika z powodu usterki, która nie ma z nim nic wspólnego.

Odróżnij miękkie zerwanie od restartu

Wiersz logu to cała diagnoza. Renegocjacja zapisuje miękkie zerwanie, a potem świeżą wymianę kluczy w tym samym tunelu: interfejs zachowuje adres, trasy nie są dodawane ponownie, a ustanowione sesje TCP zwykle przeżywają z pauzą. Prawdziwy restart rozrywa sesję, odbudowuje interfejs, może przydzielić inny adres klienta i zabija każde długotrwałe połączenie. Oba zdarzenia są zwyczajne; tylko jedno z nich tłumaczy przerwane połączenie.

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'soft reset|Connection reset|reneg|TLS Error'
openvpn --version | head -n 1

Wiersz wersji ma znaczenie, bo sformułowania w logu zmieniają się między wydaniami, a komunikat, który pamiętasz z 2.3, w 2.6 może być sformułowany inaczej. Czytaj własny log, a nie wyciąg z forum kogoś innego. Cytuj dokładny wiersz, gdy prosisz o pomoc, bo parafraza gubi szczegół identyfikujący zdarzenie. Jeśli adres interfejsu nie zmienia się w trakcie zdarzenia, a lista sesji przeżywa, widzisz odświeżenie i pozostałe sekcje mają zastosowanie.

Czytaj obowiązujący licznik, nie swój plik

reneg-sec to liczba sekund między renegocjacjami kanału danych, a jego wartość domyślna to 3600. Każda strona niesie własną wartość, i to mniejsza z dwóch faktycznie wyzwala odświeżenie. Ta jedna reguła wyjaśnia większość zgłoszeń: profil klienta ustawiający dużą liczbę i tak jest resetowany co godzinę, dopóki serwer zachowuje wartość domyślną.

grep -Rn --include='*.conf' -E 'reneg-sec|reneg-bytes' /etc/openvpn
# server side, including included files
grep -Rn -E '^reneg-sec' /etc/openvpn/server/

Przeczytaj też efektywną konfigurację serwera, łącznie ze wszystkim, co wypycha, zanim wyciągniesz wniosek z pliku klienta. Potem zwiększ szczegółowość i obserwuj jeden interwał od początku do końca: poziom 3 pokazuje już wiersze renegocjacji, a znaczniki czasu mówią, czy zdarzenie powtarza się co 3600 sekund, czy podąża za aktywnością.

Zmieniaj to tam, gdzie faktycznie jest wypychane

Krążące lekarstwo to jedna linia w profilu klienta i mniej więcej w połowie przypadków to złe miejsce. Ponieważ wygrywa niższa wartość strony, klient, który ustawi licznik na zero, nadal może zostać zrenegocjowany przez serwer, który się nie zmienił.

# on both ends, or on the side that owns the pushed configuration
reneg-sec 0

Gdy profile są generowane centralnie, edytuj szablon, a nie wdrożoną kopię, inaczej następne uruchomienie provisioningu przywróci właśnie usuniętą wartość. Sprawdź, obserwując dwa interwały, a nie jeden: jedna cicha godzina pasuje też do licznika ustawionego na 7200.

Zdecyduj też, co się dzieje przy wdrożeniu mieszanym. Jeśli najpierw wdrożysz zmianę na klientach, zostaje okno, w którym serwer nadal wyzwala odświeżenie; jest to nieszkodliwe, ale mylące, jeśli patrzysz w logi po potwierdzenie. Zmień najpierw stronę z mniejszą wartością, a objaw zniknie w punkcie, którego oczekujesz.

Co oddajesz, wyłączając renegocjację

Regularna renegocjacja ogranicza, jak długo jeden zestaw kluczy kanału danych chroni ruch. Wyłączenie licznika nie psuje tunelu, a na domowym routerze lub bramie małego biura praktyczna ekspozycja jest skromna. To nadal wymiana i warto ją nazwać, zanim jej dokonasz. Zmienia się to, jak długo jeden zestaw kluczy chroni sesję, a nie to, czy tunel w ogóle działa.

Rozsądnym przypadkiem wyłączenia jest reset, który psuje coś, czego nie da się wznowić: połączenie, które się urywa, sesja pulpitu zdalnego, którą trzeba odtworzyć, kopia zapasowa zaczynająca od początku. Jeśli pauza jest niewidoczna dla użytkowników, zachowanie wartości domyślnej nic nie kosztuje i zachowuje otrzymaną rotację kluczy.

Wolij naprawić przyczynę, gdy wzorzec na to pozwala. Odświeżenie, które zawodzi w połowie, choć pierwszy uścisk dłoni się udał, wskazuje na ścieżkę, a nie na licznik: szukaj problemu z rozmiarem pakietu w większej wymianie kanału sterowania, zapory stanowej, która zrzuca strumień, albo propozycji, która udaje się tylko za pierwszym razem. Każdy z nich zostawia ślad w tym samym logu, który właśnie przeczytałeś. Wyłączenie licznika ukrywa ten dowód.

Gdy interwał wskazuje gdzie indziej

Dwaj sąsiedzi w konfiguracji dają podobne objawy i różne poprawki. ping-restart restartuje tunel, gdy przez ustawiony okres nic nie nadchodzi, a ping-exit całkowicie wyłącza klienta. Zerwanie w bezczynności bez żadnej renegocjacji w logu należy do tych, albo do urządzenia NAT, które pozwoliło mapowaniu UDP wygasnąć według własnego harmonogramu.

Routery konsumenckie, mobilne hotspoty i NAT klasy operatorskiej pozwalają bezczynnym sesjom UDP wygasać, nie mówiąc o tym nikomu. Ta awaria podąża za bezczynnością, a nie za zegarem, i to jest znak: sesja, która zrywa się po dziesięciu cichych minutach i przeżywa godzinę równego ruchu, nie renegocjuje.

Zapisz trzy rzeczy, zanim zmienisz czwartą: zmierzony interwał, znalezioną obowiązującą wartość i polecenie, które ją pokazało. Jeśli interwał przesuwa się wraz z licznikiem, mechanizm jest zidentyfikowany, a poprawka to decyzja o powyższej wymianie. Jeśli się nie przesuwa, przywróć ustawienie i dalej patrz na keepalive, stan NAT i utratę pakietów.