Was zählt in einem Bericht als erfolgreicher VPN-Login?

Drei Berichte über dasselbe VPN können voneinander abweichen, ohne dass einer davon falsch ist, weil jeder mit einem erfolgreichen Login etwas anderes meint. Der eine zählt Verbindungen, die den Server erreicht haben, ein anderer zählt Identitäten, die der Authentifizierungsschritt akzeptiert hat, und ein dritter zählt Sitzungen, die die Initialisierung abgeschlossen haben. Eine davon vor der Datenerhebung zu wählen, ist der Unterschied zwischen einer Metrik und einer Behauptung.

Die nützliche Frage ist nicht, welche Definition allgemein richtig ist, sondern auf welches Ergebnis der Leser reagieren wird.

Drei verschiedene Ereignisse tragen dieselbe Bezeichnung

Ein Server nimmt eine Transportverbindung an, sobald der Handshake abgeschlossen ist, und das geschieht, bevor irgendein Anmeldedatum vorgelegt wird. Dieses Ereignis sagt Ihnen, dass der Port erreichbar ist und der Netzwerkpfad funktioniert, und es sagt nichts darüber, wer sich verbunden hat. Die Authentifizierung ist ein späterer Schritt, der scheitern kann, und er kann auch für eine Identität gelingen, der nie Zugang zum Netz gewährt wird.

Die Initialisierung folgt der Authentifizierung, und ein Tunnel, der die Initialisierung abschließt, kann den Rest des Tages untätig bleiben. Eine Anwendungsanfrage ist das einzige Ereignis, das zeigt, dass ein Nutzer etwas erreicht hat, das er wollte. Diese Stufen sind ineinandergeschachtelt, daher übersteigt die Zählung der weitesten immer die der engsten. Nichts in der Ereignisfolge beweist, dass der Nutzer produktiv war, nur dass sich jedes Tor der Reihe nach öffnete.

Die Produktdokumentation benennt die Zustände meist ausdrücklich. Die OpenVPN Hinweise zur Management-Schnittstelle trennen die TCP-Verbindung, das Authentifizierungsergebnis und die abgeschlossene Initialisierung, und genau diese Unterscheidung braucht ein Bericht. Ein als connected bezeichneter Zustand belegt nicht, dass eine Dateifreigabe oder ein Datenbankvorgang später gelungen ist.

Zählen Sie Sitzungen, Identitäten oder Anfragen

Legen Sie die Einheit fest, bevor Sie die Zahl festlegen. Eine Sitzungszählung beantwortet, wie oft der Dienst genutzt wurde, eine Identitätszählung, wie viele verschiedene Konten auftraten, und eine Anfragezählung, wie viel Arbeit erledigt wurde. Anbieter zählen das ebenfalls unterschiedlich, und ein in Nutzern gemessener Anspruch lässt sich nicht mit einem in Sitzungen gemessenen Diagramm vergleichen. Die falsche Einheit zu wählen, führt dazu, dass ein Kapazitätsplan für die falsche Größe dimensioniert wird.

Neuverbindungen sind der Ort, an dem Sitzungszahlen still anschwellen. Ein Client, der alle paar Minuten abbricht und sich neu verbindet, erzeugt Dutzende Sitzungsdatensätze für eine Person, sodass ein Bericht, der Sitzungen als Personen zählt, die Nutzung genau unter den Bedingungen überschätzt, in denen die Zuverlässigkeit am schlechtesten ist. Schreiben Sie die Regel auf: Eine neue Sitzung nach einer Neuverbindung zählt getrennt, oder sie setzt die vorherige innerhalb eines definierten Zeitfensters fort.

Adressen sind die schwächste verfügbare Identität. Eine Tunneladresse kann Minuten später einem anderen Nutzer zugewiesen werden, und zwei Nutzer können sich über eine Übersetzung eine Adresse teilen. Hängen Sie die Konto-Kennung aus dem Authentifizierungsereignis an, statt eine Person aus einer Adresse in einem Protokoll abzuleiten.

Prüfen Sie die Definition an einem echten Tag

Nehmen Sie einen einzigen Tag Protokolle und zählen Sie denselben Verkehr auf drei Arten. Liegen die drei Zahlen nahe beieinander, spielt die Definition für Ihren Zweck vielleicht keine große Rolle; weichen sie um einen großen Faktor ab, muss der Bericht sagen, welche er verwendet.

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

Führen Sie dieselbe Extraktion an einem Tag mit bekanntem Ausfall durch und vergleichen Sie die Form statt die Summe. Ein Tag, an dem das Uplink flatterte, sollte einen Ausschlag bei Verbindungsereignissen mit einem bescheidenen Anstieg verschiedener Konten zeigen, und wenn nicht, misst der Zähler wahrscheinlich etwas anderes als der Bericht behauptet.

Bewahren Sie die Abfrage selbst neben dem Ergebnis auf. Jeder kann einen dokumentierten Filter nachvollziehen, und eine Zahl ohne ihren Filter ist nicht prüfbar.

Berichten Sie, was das Ereignis belegt

Ein fehlgeschlagener Versuch verdient eine eigene Kategorie, statt in eine der beiden Seiten gefaltet zu werden. Zu Fehlschlägen gehören vertippte Passwörter, Clients mit veraltetem Profil und gezieltes Sondieren, und alle drei haben unterschiedliche Reaktionen. Ein Fehlschlag ist kein Beleg für einen erfolgreichen Einbruch und auch kein Beleg für Harmlosigkeit.

Schreiben Sie die Schlussfolgerung mit der Stärke, die das Ereignis trägt: Dieses Konto hat sich bei diesem Dienst in diesem Zeitfenster von dieser Quelle aus authentifiziert, und die Sitzung erreichte die Initialisierung. Alles darüber, was der Nutzer danach tat, erfordert einen Datensatz auf der Anwendungsseite statt weiterer Tunneldaten.

Wenn der Bericht an jemanden geht, der über Lizenzierung, Kapazität oder Sicherheit entscheidet, setzen Sie die Definition in die erste Zeile statt in eine Fußnote. Die Definition ist der Befund, und die Zahl ergibt nur innerhalb ihrer einen Sinn.