Trzy zegary w jednym logu VPN: klient, brama, kolektor

Os czasu incydentu VPN zwykle zaczyna się od dwóch znaczników czasu różniących się o kilka minut i od wyświetlacza pokazującego inną godzinę. Pokusa jest taka, aby wybrać jeden jako poprawny i przepisać drugi. Oba mogą być poprawne, bo zapisały je różne zegary o różnych zdarzeniach. Mit głosi, że VPN ma jeden zegar; praca polega na ustaleniu, który komponent zapisał każde pole.

Mit: VPN ma jeden zegar

Klient zapisuje zdarzenie, gdy próbuje połączenia. Brama zapisuje zdarzenie, gdy odbiera lub akceptuje tę próbę. Kolektor zapisuje czas przybycia, gdy odbiera wiadomość bramy. To trzy zdarzenia, a każde jest ostemplowane przez zegar, któremu ufał zapisujący komponent. Zlepianie ich w jedną oś czasu to wygoda, która ukrywa niezgodność, którą próbujesz wyjaśnić.

Liczby zwykle różnią się od sekund do minut i to jest normalne. Ważne jest, czy różnica to opóźnienie dostarczenia, przesunięcie zegara czy naprawdę inne zdarzenie. Aby zdecydować, na co patrzysz, potrzebne jest pochodzenie każdego pola, a nie mocniejsza opinia o tym, która maszyna ma rację.

Czytaj źródło przed wartością

Przed porównaniem wartości ustal, kto wytworzył każdą z nich i które to pole. Komunikat syslog niesie znacznik czasu od źródła, jak opisuje RFC 5424, a format może nieść także informacje o jakości czasu opisujące synchronizację i dokładność. Ten sam format pozwala źródłu nie wysłać żadnego znacznika czasu, gdy nie może odczytać czasu systemowego, co samo w sobie jest użytecznym sygnałem.

journalctl -o short-iso --utc -n 20
logger -t vpn-check "test event"

Klient może też wysłać wartość czasu jako metadane aplikacji, a usługa, która ją przechowuje, powinna oznaczyć ją jako zgłoszoną przez klienta, zamiast traktować ją jako niezależnie zweryfikowaną. To oznaczenie jest różnicą między dowodem a twierdzeniem. Eksportując logi do sprawy, trzymaj razem nazwę pola, źródło i przesunięcie. Sprowadzenie ich do wygodnego czasu lokalnego niszczy dokładnie tę informację, której potrzebujesz.

Zatrzymaj się, jeśli nie potrafisz powiedzieć, który komponent zapisał pole. Porównywanie go z czymkolwiek innym to zgadywanie.

Wyświetlanie strefy czasowej nie jest innym momentem

Ten sam moment pokazany jako 10:00Z i jako 18:00+08:00 nie jest rozbieżnością, a traktowanie go jako rozbieżności marnuje pół dnia. Przed porównaniem przekonwertuj oba na UTC i zachowaj oryginalny tekst obok konwersji. Ułamek dziesiętny po jednej stronie i całe sekundy po drugiej też nie są konfliktem. Precyzja to nie poprawność: wartość z milisekundami może wciąż pochodzić z zegara mylącego się o minuty.

date -u +%FT%TZ
timedatectl

Opóźnienie dostarczenia to inne zwykłe wyjaśnienie. Brama rejestruje, kiedy zaakceptowała połączenie, a kolektor rejestruje, kiedy wiadomość do niego dotarła, więc różnica między nimi to czas transportu. Ta różnica mówi coś o potoku logów, a nie o sesji VPN. Oznacz ją jako czas przybycia, a przestanie konkurować z czasem zdarzenia.

Koreluj bez przepisywania dowodów

Zachowaj oryginalne znaczniki czasu i dodaj kolumnę pochodną, jeśli potrzebujesz wspólnego widoku. Wyjaśnij konwersję w notatkach, zamiast edytować rekordy źródłowe, bo źródło jest tym, co sprawdzi późniejszy recenzent. Zachowaj czas przybycia kolektora osobno wszędzie, gdzie istnieje.

chronyc tracking
journalctl --utc -u openvpn-client@work -n 50 --no-pager

Zmiana zegara urządzenia nie jest kontrolą prywatności i nie przepisuje rekordów, które inny system już ma. Utrudnia też porównywanie dowodów wsparcia i może zepsuć kontrole certyfikatów i kodu, które zależą od czasu. Utrzymuj zegary zsynchronizowane do zwykłej pracy, a każde celowe odchylenie traktuj jako usterkę do zbadania. Jeśli dwa rekordy wyglądają na nie w kolejności, sprawdź synchronizację zegara i dostarczenie, zanim zbudujesz nową historię.

Mit, który trzeba porzucić, to istnienie jednego czasu VPN. Zapytaj, co zapisało każde pole i co się stało, gdy to zrobiło, a oś czasu staje się zbiorem oznaczonych obserwacji, a nie sprzecznością.