keepalive w OpenVPN czy restart w systemd: co przywraca tunel?

Z tunelem mogą pójść źle trzy różne rzeczy, i wymagają one trzech różnych reakcji. Partner przestaje odpowiadać, proces demona umiera albo aplikacja za tunelem przestaje obsługiwać. Konfiguracja, która przy każdym z nich restartuje usługę, nie jest starannym nadzorem; to jedno tępe działanie zastosowane do niepowiązanych awarii. Porównanie tego, co każdy mechanizm naprawdę może zaobserwować, czyni podział pracy oczywistym.

Trzy awarie, które wyglądają jak jedna

Cisza partnera oznacza, że drugi koniec przestał wysyłać, a OpenVPN może to wykryć samodzielnie, bo posiada puls. Śmierć procesu oznacza, że demon zakończył działanie, co zauważa menedżer usług, a OpenVPN nie może. Awaria aplikacji oznacza, że tunel jest w porządku, a coś za nim nie, i żaden z dwóch pozostałych mechanizmów nie ma sposobu, by to wiedzieć. Każda wymaga innej reakcji i żadna nie jest tym samym, co zauważenie, że tunel działa.

To różne sygnały z różnych warstw, a każdy ma właściciela, który może na niego działać bez zgadywania. Mieszanie ich daje system, który restartuje się na objawy, których nie potrafi zinterpretować.

Zapisz trzy przypadki, zanim zmienisz jakikolwiek licznik czasu. Sama lista zwykle pokazuje, że od jednego mechanizmu wymaga się pokrycia wszystkich trzech.

W co keepalive naprawdę się rozwija

Dyrektywa keepalive to skrót, a rozwinięcie różni się w zależności od trybu. Na serwerze keepalive 10 60 staje się lokalnym pingiem co dziesięć sekund, lokalnym terminem restartu wynoszącym 120 sekund i wartościami 10 oraz 60 wysyłanymi do klientów. Termin serwera jest celowo podwojony, aby klient miał szansę zrestartować się, zanim serwer się podda. Czytaj rozwiniętą formę w działającej konfiguracji, a nie skrót w profilu.

To podwojenie jest powodem, dla którego każdy opis twierdzący, że oba końce restartują się po sześćdziesięciu sekundach, jest błędny. Wyjaśnia też, dlaczego oba końce nie migoczą równocześnie, gdy ścieżka się pogarsza.

Puls to ruch partnerski OpenVPN, a nie sonda ICMP do jakiegoś publicznego hosta. Odpowiedź dowodzi tylko, że odległy koniec tunelu żyje. Nie mówi nic o bazie danych ani usłudze internetowej, której użytkownik naprawdę potrzebuje.

Czego Restart=on-failure nie obserwuje

Przeczytaj zainstalowaną jednostkę, zanim dodasz nadpisanie. Restart=on-failure reaguje na udokumentowane warunki awarii procesu, co nie jest tym samym, co obserwowanie stanu połączenia. Nie uruchamia się dlatego, że rozpoczęło się wewnętrzne ponowne połączenie, a czyste wyjście ma inną semantykę niż awaria.

To rozróżnienie ma znaczenie, ponieważ wewnętrzny restart utrzymuje ten sam proces przy życiu. Jednostka nic nie widzi, tunel sam się odtwarza i to jest prawidłowy wynik.

Ustaw RestartSec i limity uruchomień świadomie, inaczej pętla awarii będzie uderzać w bramę i zakopywać prawdziwy błąd pod komunikatami o restarcie. Limit restartów, który zadziała, pozostawia jednostkę w stanie awarii, co jest widoczne, a nieograniczona pętla nie jest.

ping-restart i ping-exit nie są wymienne

ping-restart wyzwala wewnętrzny restart OpenVPN i zachowuje proces. ping-exit kończy proces przy tym samym rodzaju terminu, co przekazuje decyzję menedżerowi usług. Wykluczają się wzajemnie, a wybór drugiego zmienia to, kto jest właścicielem odzyskiwania. Różnica polega na tym, kto decyduje o ponownej próbie i ile stanu przetrwa tę próbę.

Jeśli wybierzesz wyjście po terminie, jednostka potrzebuje pasującej polityki restartu i obsługi stanu wyjścia, inaczej awaria żywotności wygląda jak trwałe zatrzymanie. Opcje trwałości mogą też zachować interfejsy i trasy przez wewnętrzny restart, ale nie przez wyjście procesu.

Wybierz jeden cykl życia na wdrożenie i zapisz dlaczego. Profil noszący obie dyrektywy to profil, który się nie zdecydował.

Testuj każdą awarię jako osobny przypadek

Symuluj cichego partnera, zabitego demona i niedostępną aplikację w zatwierdzonym oknie, a następnie sprawdź, które odzyskiwanie zadziałało. Cichy partner powinien dać wewnętrzne ponowne połączenie, zabity proces restart jednostki, a awaria aplikacji żadne z nich. Gdy dwa przypadki dają tę samą akcję, własność jest nadal mieszana.

Powtarzane odzyskiwanie też nie jest naprawą. Odrzucone dane logowania albo dwóch klientów dzielących jedną skuteczną nazwę będą nadal się zastępować, a szybsze liczniki czasu tylko przyspieszają to migotanie.