Co liczy się jako udane logowanie VPN w raporcie?

Trzy raporty o tym samym VPN mogą się różnić, choć żaden z nich nie jest błędny, ponieważ każdy rozumie co innego przez udane logowanie. Jeden liczy połączenia, które dotarły do serwera, drugi liczy tożsamości przyjęte przez etap uwierzytelnienia, a trzeci liczy sesje, które zakończyły inicjalizację. Wybór jednego z nich przed zbieraniem danych to różnica między metryką a argumentem.

Użyteczne pytanie nie brzmi, która definicja jest poprawna ogólnie, lecz na który wynik czytelnik będzie działać.

Trzy różne zdarzenia noszą tę samą etykietę

Serwer przyjmuje połączenie transportowe, gdy tylko zakończy się uścisk dłoni, a dzieje się to przed przedstawieniem jakichkolwiek danych uwierzytelniających. To zdarzenie mówi, że port jest osiągalny i ścieżka sieciowa działa, a nie mówi nic o tym, kto się połączył. Uwierzytelnienie to późniejszy etap, który może się nie powieść, a może też udać się dla tożsamości, której nigdy nie wolno wejść do sieci.

Inicjalizacja następuje po uwierzytelnieniu, a tunel, który zakończył inicjalizację, może przez resztę dnia stać bezczynnie. Żądanie aplikacji to jedyne zdarzenie, które dowodzi, że użytkownik dotarł do czegoś, czego chciał. Te etapy są zagnieżdżone, więc liczba najszerszego zawsze przewyższy liczbę najwęższego. Nic w sekwencji zdarzeń nie dowodzi, że użytkownik był produktywny, tylko że każda brama otworzyła się po kolei.

Dokumentacja produktu zwykle nazywa stany wprost. notatki dotyczące interfejsu zarządzania OpenVPN rozdzielają połączenie TCP, wynik uwierzytelnienia i zakończoną inicjalizację, i to jest dokładnie to rozróżnienie, którego raport potrzebuje. Stan oznaczony jako connected nie poświadcza, że udostępnianie plików albo operacja na bazie danych później się powiodła.

Licz sesje, tożsamości albo żądania

Wybierz jednostkę, zanim wybierzesz liczbę. Liczba sesji odpowiada na pytanie, ile razy użyto usługi, liczba tożsamości – ile różnych kont się pojawiło, a liczba żądań – ile pracy wykonano. Dostawcy liczą to też inaczej, a uprawnienie mierzone w użytkownikach nie da się porównać z wykresem mierzonym w sesjach. Wybór złej jednostki sprawia, że plan pojemności zostaje zwymiarowany na niewłaściwą wielkość.

Ponowne połączenia to miejsce, w którym liczby sesji cicho puchną. Klient, który co kilka minut się urywa i łączy ponownie, wytwarza dziesiątki rekordów sesji dla jednej osoby, więc raport liczący sesje jak osoby przeszacuje użycie dokładnie w warunkach, w których niezawodność jest najgorsza. Zapisz regułę: nowa sesja po ponownym połączeniu liczy się osobno albo kontynuuje poprzednią w zdefiniowanym oknie.

Adresy to najsłabsza dostępna tożsamość. Adres tunelu może zostać przydzielony innemu użytkownikowi kilka minut później, a dwóch użytkowników może dzielić jeden adres przez tłumaczenie. Dołącz identyfikator konta ze zdarzenia uwierzytelnienia, zamiast wnioskować o osobie z adresu w logu.

Sprawdź definicję na jednym prawdziwym dniu

Weź jeden dzień logów i policz ten sam ruch na trzy sposoby. Jeśli trzy liczby są blisko siebie, definicja może nie mieć dużego znaczenia dla Twojego celu; jeśli różnią się o duży współczynnik, raport musi powiedzieć, której używa.

journalctl -u openvpn-server@server --since "2026-10-01" --until "2026-10-02" | grep -c "Initialization Sequence Completed"
journalctl -u openvpn-server@server --since "2026-10-01" --until "2026-10-02" | grep -c "Peer Connection Initiated"
awk '/VERIFY OK/ {print $NF}' /var/log/openvpn-server.log | sort -u | wc -l

Uruchom to samo wyciąganie w dniu ze znanym zakłóceniem i porównaj kształt, a nie sumę. Dzień, w którym łącze w górę drgało, powinien pokazać skok zdarzeń połączeń i umiarkowany wzrost różnych kont, a jeśli tak nie jest, licznik prawdopodobnie mierzy coś innego, niż twierdzi raport.

Zachowaj samo zapytanie obok wyniku. Każdy może odtworzyć udokumentowany filtr, a liczba bez swojego filtra nie jest audytowalna.

Zaraportuj, co ustala zdarzenie

Nieudana próba zasługuje na własną kategorię, zamiast być wciśniętą w którąkolwiek stronę. Niepowodzenia obejmują błędnie wpisane hasła, klientów z nieaktualnym profilem i celowe sondowanie, a wszystkie trzy wymagają innej reakcji. Niepowodzenie nie jest dowodem udanego włamania i nie jest też dowodem nieszkodliwości.

Napisz wniosek z siłą, którą zdarzenie uzasadnia: to konto uwierzytelniło się w tej usłudze w tym oknie, z tego źródła, a sesja dotarła do inicjalizacji. Wszystko o tym, co użytkownik zrobił potem, wymaga zapisu po stronie aplikacji, a nie więcej danych z tunelu.

Kiedy raport trafia do kogoś, kto podejmie decyzję o licencjonowaniu, pojemności albo bezpieczeństwie, umieść definicję w pierwszej linii, a nie w przypisie. Definicja jest ustaleniem, a liczba ma sens tylko w jej wnętrzu.