Jak mierzyć czas działania klienta OpenVPN za pomocą hooków up i down

Pulpit prosi o liczbę mówiącą, jak długo połączenie jest aktywne, a OpenVPN jej nie podaje. Klient wie, kiedy jego tunel się podniósł, ale tylko jeśli coś zapisze ten moment, zanim stan sesji zostanie utracony. Obsługiwanym miejscem jest hook up, a wartością wartą zapisania jest surowa sekunda epoch, a nie sformatowany ciąg. Wszystko po tym to arytmetyka plus kilka reguł kolejności, które decydują, czy liczba pozostaje uczciwa.

Potwierdź, że hooki naprawdę się uruchamiają

Udowodnij, że hook się wyzwala, zanim cokolwiek wokół niego zaprojektujesz. Minimalna konfiguracja klienta wymaga script-security 2 oraz jawnych ścieżek up i down; bez linii bezpieczeństwa OpenVPN odmawia uruchomienia skryptu i mówi to wprost. Dodaj up-restart i down-pre jednocześnie, aby ścieżki restartu i demontażu zachowywały się przewidywalnie.

Spraw, aby pierwsza wersja hooka dopisywała swoje środowisko do pliku i nie robiła nic więcej. To pokazuje nazwy zmiennych, które twoja kompilacja naprawdę eksportuje, na przykład dev i script_type, zamiast tych, które pamiętasz z innej wersji. Wykonaj jedno połączenie i jedno rozłączenie, a potem przeczytaj plik. Jeśli nic się nie pojawi, zatrzymaj się tutaj, bo projekt znacznika czasu na hooku, który nigdy nie działa, będzie przez tygodnie wyglądał jak awaria monitoringu.

Sprawdź, jako który użytkownik działa hook. Gdy ustawione są user i group, OpenVPN zrzeka się uprawnień przed uruchomieniem skryptów, więc katalog, w którym root może pisać, może być zamknięty dla hooka. Wybieraj ścieżkę z punktu widzenia usługi, a nie swojej powłoki.

Zapisz jedną wartość epoch i usuń ją świadomie

Hook up potrzebuje jednej linii, date +%s > /run/openvpn-client.started, ze ścieżką dopasowaną dla każdej instancji. Wartość epoch unika późniejszych pytań o język, strefę czasową i format, i jest to ta sama liczba, którą agent monitorujący może porównać z własnym zegarem.

Usuwanie jest równie ważne jak zapis. Hook down powinien opróżnić lub usunąć plik, a down-pre sprawia, że dzieje się to przed zamknięciem interfejsu, co usuwa okno, w którym plik opisuje tunel, którego już nie ma. up-restart odświeża następnie znacznik przy wewnętrznym restarcie, zamiast zostawiać pierwotną wartość. Bez tej pary restart po przekroczeniu limitu ping daje liczbę, która wciąż rośnie, gdy tunel się odtwarza.

Wybierz miejsce o właściwym czasie życia. Plik w /run znika przy ponownym rozruchu, co odpowiada rzeczywistości, natomiast plik w /tmp może zostać nieprzewidywalnie wyczyszczony, a ten w katalogu konfiguracji przetrwa w sposób wprowadzający w błąd. Ustaw uprawnienia tak, aby tylko użytkownik usługi i czytelnik monitoringu mogli go czytać.

Oblicz czas działania bez zaufania do linii logu

Odczytaj zapisaną sekundę, odczytaj bieżącą sekundę, odejmij. Gdy pliku brak lub jest pusty, uczciwa odpowiedź brzmi, że żaden tunel nie jest aktywny, a nie że czas działania wynosi zero, ponieważ te dwa stany powinny wywoływać różne alerty. Trzymaj surowe sekundy w ładunku monitoringu, a dni i godziny formatuj w warstwie prezentacji. Formater, który zaokrągla wewnątrz eksportera, wyrzuca precyzję, której ktoś będzie chciał podczas incydentu.

Parsowanie znaczników czasu z logu to kuszący skrót i zawodzi na trzy sposoby: format zależy od ustawionych opcji, rotacja usuwa historię, a ponowne połączenia pojawiają się jako osobne sesje, a nie jeden ciągły tunel. Hook zapisuje zdarzenie raz, w chwili, gdy ono następuje.

Gdy sprawdzenie działa na innym hoście, wysyłaj znacznik czasu, a nie czas trwania, aby czytelnik zastosował własny zegar. Wtedy mały wynik ujemny czyta się jako różnica zegarów, a nie jako zepsuty hook.

Pokryj ponowne połączenia, restarty i wiele instancji

Dwa tunele na jednym hoście wymagają dwóch plików, kluczowanych nazwą instancji, której usługa już używa. Wspólna ścieżka oznacza, że najnowsze połączenie nadpisuje czas startu każdego profilu, a objawem jest liczba, która skacze wstecz, gdy startuje drugi tunel.

Zachowanie przy ponownym połączeniu zasługuje na własny test, bo właśnie tam wiarygodny projekt po cichu raportuje coś złego. Wymuś restart, zrywając peera lub wysyłając sygnał do procesu, a potem porównaj stan interfejsu z plikiem. Znacznik czasu powinien przesunąć się do przodu w chwili, gdy tunel wraca.

Po stronie serwera plik stanu niesie wartość connected-since dla każdego klienta, która odpowiada na inne pytanie: kiedy serwer ostatnio widział tego peera. Używaj jej do kontroli krzyżowej, a nie jako zamiennika, bo znika wraz z sesją, którą opisuje. Żaden z pomiarów nie mówi nic o kondycji aplikacji za tunelem.

Uruchom trzy kontrole, które wyłapują błędy kolejności

Przetestuj zwykłe połączenie, wymuszone ponowne połączenie i czyste zatrzymanie, czytając listę interfejsów i plik razem po każdym. Znacznik, który nadal jest po czystym zatrzymaniu, albo plik twierdzący, że istnieje tunel, którego nie ma na liście interfejsów, wskazuje wprost na kolejność hooków. Wykonuj kontrole jako użytkownik usługi i ze ścieżkami usługi, bo powłoka roota może widzieć inny plik i dać pewną siebie błędną odpowiedź. Potem zostaw wolny pollowacz czytający plik i potwierdź, że nigdy do niego nie pisze.

Odpytywanie co sześćdziesiąt sekund pokrywa alerty, a żaden hook nie powinien zakładać, że ten pollowacz żyje. Trzymaj te dwie odpowiedzialności osobno, a liczba pozostanie wiarygodna, gdy którakolwiek strona zostanie wdrożona ponownie.