Co se v přehledu počítá jako úspěšné přihlášení k VPN?

Tři přehledy o stejné VPN se mohou rozcházet, aniž by byl některý z nich chybný, protože každý si pod úspěšným přihlášením představuje něco jiného. Jeden počítá spojení, která dorazila na server, druhý počítá identity, které přijal krok ověření, a třetí počítá relace, které dokončily inicializaci. Vybrat si jedno z nich před sběrem dat je rozdíl mezi metrikou a argumentem.

Užitečná otázka není, která definice je obecně správná, ale na který výsledek bude čtenář reagovat.

Tři různé události nesou stejný název

Server přijme transportní spojení, jakmile se dokončí handshake, což se stane dříve, než je předložen jakýkoli údaj o přihlášení. Tato událost říká, že port je dostupný a síťová cesta funguje, a neříká nic o tom, kdo se připojil. Ověření je pozdější krok, který může selhat, a může také uspět pro identitu, které není nikdy povolen vstup do sítě.

Inicializace přichází po ověření a tunel, který inicializaci dokončil, může zbytek dne zůstat nečinný. Požadavek aplikace je jediná událost, která dokazuje, že se uživatel dostal k něčemu, co chtěl. Tyto fáze se vnořují, takže počet té nejširší vždy převýší počet té nejužší. Nic v posloupnosti událostí nedokazuje, že uživatel byl produktivní, pouze že se každá brána otevřela v pořadí.

Dokumentace produktu obvykle stavy výslovně pojmenovává. OpenVPN poznámky k rozhraní pro správu oddělují TCP spojení, výsledek ověření a dokončenou inicializaci, což je přesně rozlišení, které přehled potřebuje. Stav označený jako connected nedosvědčuje, že sdílení souborů nebo operace s databází později uspěla.

Počítejte relace, identity nebo požadavky

Rozhodněte o jednotce dřív, než rozhodnete o čísle. Počet relací odpovídá na to, kolikrát byla služba použita, počet identit na to, kolik různých účtů se objevilo, a počet požadavků na to, kolik práce bylo vykonáno. Dodavatelé to také počítají různě a nárok měřený v uživatelích nelze srovnávat s grafem měřeným v relacích. Volba špatné jednotky je důvod, proč plán kapacity skončí dimenzovaný na nesprávné množství.

Opětovná připojení jsou místem, kde počet relací tiše bobtná. Klient, který každých pár minut spadne a znovu se připojí, vytvoří pro jednoho člověka desítky záznamů relací, takže přehled, který počítá relace jako lidi, nadhodnotí využití právě v podmínkách, kdy je spolehlivost nejhorší. Zapište pravidlo: nová relace po opětovném připojení se počítá zvlášť, nebo pokračuje v předchozí v definovaném okně.

Adresy jsou nejslabší dostupná identita. Adresa tunelu může být o pár minut později přidělena jinému uživateli a dva uživatelé mohou sdílet jednu adresu přes překlad. Připojujte identifikátor účtu z události ověření, místo abyste osobu odvozovali z adresy v záznamu.

Otestujte definici na jednom skutečném dni

Vezměte jeden den záznamů a spočítejte stejný provoz třemi způsoby. Pokud jsou tři čísla blízko sebe, definice pro váš účel možná moc nezáleží; pokud se liší velkým násobkem, přehled musí uvést, kterou používá.

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

Spusťte stejné vytěžení v den se známým výpadkem a porovnejte tvar, ne součet. Den, kdy horní spojka kmitala, by měl ukázat skok v událostech připojení s mírným nárůstem různých účtů, a pokud ne, počítadlo pravděpodobně měří něco jiného, než přehled tvrdí.

Uchovejte samotný dotaz vedle výsledku. Dokumentovaný filtr může zopakovat kdokoli a číslo bez svého filtru není auditovatelné.

Uveďte, co událost prokazuje

Neúspěšný pokus si zaslouží vlastní kategorii, místo aby byl vklíněn na kteroukoli stranu. Mezi neúspěchy patří překlepy v heslech, klienti se zastaralým profilem a úmyslné sondování, a všechny tři mají jinou odezvu. Neúspěch není důkazem úspěšného průniku a není ani důkazem neškodnosti.

Napište závěr s takovou silou, jakou událost podporuje: tento účet se ověřil u této služby v tomto okně, z tohoto zdroje, a relace dosáhla inicializace. Cokoli o tom, co uživatel potom dělal, vyžaduje záznam na straně aplikace, ne další data z tunelu.

Když přehled dostane někdo, kdo bude rozhodovat o licencích, kapacitě nebo bezpečnosti, dejte definici na první řádek, ne do poznámky pod čarou. Definice je zjištění a číslo má smysl jen uvnitř ní.