Wat telt als een geslaagde VPN-login in een rapport?

Drie rapporten over dezelfde VPN kunnen van mening verschillen zonder dat een ervan onjuist is, omdat elk iets anders verstaat onder een geslaagde login. Het ene telt verbindingen die de server bereikten, een ander telt identiteiten die de authenticatiestap accepteerde, en een derde telt sessies die de initialisatie voltooiden. Eén daarvan kiezen voordat u gegevens verzamelt, is het verschil tussen een metriek en een betoog.

De nuttige vraag is niet welke definitie in het algemeen juist is, maar op welke uitkomst de lezer gaat handelen.

Drie verschillende gebeurtenissen dragen hetzelfde label

Een server accepteert een transportverbinding zodra de handshake is voltooid, en dat gebeurt voordat er enige inloggegevens worden gepresenteerd. Die gebeurtenis vertelt u dat de poort bereikbaar is en dat het netwerkpad werkt, en ze vertelt niets over wie er verbinding maakte. Authenticatie is een latere stap die kan mislukken, en die kan ook slagen voor een identiteit die nooit toegang tot het netwerk krijgt.

Initialisatie komt na authenticatie, en een tunnel die klaar is met initialiseren kan de rest van de dag werkloos staan. Een verzoek van een toepassing is de enige gebeurtenis die aantoont dat een gebruiker iets bereikte wat hij wilde. Deze fasen zijn in elkaar genest, dus een telling van de breedste zal altijd die van de smalste overtreffen. Niets in de reeks gebeurtenissen bewijst dat de gebruiker productief was, alleen dat elke poort op zijn beurt openging.

Productdocumentatie benoemt de toestanden meestal expliciet. De OpenVPN notities over de beheerinterface scheiden de TCP-verbinding, het authenticatieresultaat en de voltooide initialisatie, en dat is precies het onderscheid dat een rapport nodig heeft. Een toestand met het label connected bewijst niet dat een bestandsserver of een databasebewerking later slaagde.

Tel sessies, identiteiten of verzoeken

Bepaal de eenheid voordat u het aantal bepaalt. Een sessietelling beantwoordt hoe vaak de dienst werd gebruikt, een identiteitstelling hoe veel verschillende accounts verschenen, en een verzoektelling hoe veel werk werd verricht. Leveranciers tellen dit ook verschillend, en een recht gemeten in gebruikers is niet te vergelijken met een grafiek gemeten in sessies. De verkeerde eenheid kiezen is hoe een capaciteitsplan op de verkeerde hoeveelheid wordt gedimensioneerd.

Herverbindingen zijn waar sessietellingen stilletjes opblazen. Een client die elke paar minuten wegvalt en opnieuw verbindt, levert tientallen sessieregistraties op voor één persoon, dus een rapport dat sessies als personen telt, overschat het gebruik juist in de omstandigheden waarin de betrouwbaarheid het slechtst is. Schrijf de regel op: een nieuwe sessie na een herverbinding telt apart, of ze zet de vorige voort binnen een gedefinieerd venster.

Adressen zijn de zwakste identiteit die beschikbaar is. Een tunneladres kan minuten later aan een andere gebruiker worden toegewezen, en twee gebruikers kunnen één adres delen via vertaling. Koppel de accountidentificatie uit de authenticatiegebeurtenis in plaats van een persoon af te leiden uit een adres in een log.

Test de definitie op één echte dag

Neem één dag aan logs en tel hetzelfde verkeer op drie manieren. Als de drie getallen dicht bij elkaar liggen, is de definitie voor uw doel misschien niet zo belangrijk; als ze met een grote factor verschillen, moet het rapport zeggen welke het gebruikt.

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

Draai dezelfde extractie op een dag met een bekende storing en vergelijk de vorm in plaats van het totaal. Een dag waarop de uplink haperde, zou een piek in verbindingsgebeurtenissen moeten tonen met een bescheiden stijging van verschillende accounts, en als dat niet gebeurt, meet de teller waarschijnlijk iets anders dan het rapport beweert.

Bewaar de query zelf naast het resultaat. Iedereen kan een gedocumenteerd filter reproduceren, en een getal zonder zijn filter is niet auditabel.

Rapporteer wat de gebeurtenis vaststelt

Een mislukte poging verdient een eigen categorie in plaats van in een van beide kanten te worden gevouwen. Mislukkingen omvatten verkeerd getypte wachtwoorden, clients met een verouderd profiel en opzettelijke verkenning, en de drie vragen om verschillende reacties. Een mislukking is geen bewijs van een geslaagde inbraak, en ook geen bewijs van onschadelijkheid.

Schrijf de conclusie met de kracht die de gebeurtenis ondersteunt: dit account authenticeerde zich bij deze dienst in dit venster, vanaf deze bron, en de sessie bereikte de initialisatie. Alles over wat de gebruiker daarna deed vereist een registratie aan de toepassingskant in plaats van meer tunnelgegevens.

Wanneer het rapport naar iemand gaat die een beslissing over licenties, capaciteit of beveiliging neemt, zet de definitie dan in de eerste regel in plaats van in een voetnoot. De definitie is de bevinding, en het getal heeft alleen daarbinnen betekenis.