VPN-Server-Uptime: Was diese Zahl Ihnen nicht sagt

Eine öffentliche Knotenliste zeigt einen Server mit einer in Wochen gemessenen Uptime, also wählen Sie ihn, und die Verbindung scheitert beim ersten Versuch. Das ist keine falsche Werbung; es ist die falsche Frage an eine Zahl, die etwas anderes misst. Uptime gibt normalerweise an, wie lange ein Prozess, ein Container oder eine Maschine seit dem letzten Start läuft, und das ist eine Eigenschaft der Infrastruktur des Veröffentlichers, nicht Ihres Weges dorthin. Sie als Zuverlässigkeit zu behandeln ist derselbe Kategorienfehler, wie den Kilometerzähler eines Autos als Straßenbericht zu behandeln.

Was die Zahl misst

Auf einem Host mit einem modernen Dienstmanager ist der Zähler an ein Ereignis gebunden, das Sie tatsächlich lesen können: den Zeitstempel, zu dem die Einheit in den aktiven Zustand überging, oder die Startzeit der Maschine. Alles andere ist Arithmetik auf diesem Anker, und die Definition des Ankers variiert zwischen Veröffentlichern. Eine Liste kann bei einem Daemon-Neustart zurücksetzen, eine andere bei einem Neustart des Systems, und eine dritte bei einem manuellen Reset durch einen Betreiber, der einen sauberen Graphen wollte.

systemctl show -p ActiveEnterTimestamp --value openvpn-server@server
uptime -s
systemctl is-active openvpn-server@server

Diese drei Befehle beantworten drei verschiedene Fragen, und ein Verzeichnis, das eine Zahl zeigt, kann Ihnen nicht sagen, welche davon es verwendet hat. Ein roher Zähler aus zwei Listen ist daher gar kein Vergleich, bis Sie wissen, worauf jeder von ihnen zurücksetzt.

Ein Prozess kann laufen, während der Weg unten ist

Der Daemon lauscht. Das Zertifikat ist gültig. Der Prozess lebt seit dreiundzwanzig Tagen. Nichts davon garantiert, dass Pakete aus Ihrem Netz ihn erreichen, denn Erreichbarkeit ist eine Eigenschaft des gesamten Weges: der Uplink des Anbieters, das Peering zwischen seinem Netz und Ihrem, die Überlastung auf einer gemeinsamen Transitstrecke und die Firewall vor Ihrer eigenen Verbindung.

Ein Server kann aus einem anderen Grund laufen und nutzlos sein. Ein Knoten, der weit mehr Clients angenommen hat, als seine Bandbreite trägt, zeigt eine lange Uptime und ein schreckliches Erlebnis, weil der Zähler weder Kapazität noch Konkurrenz misst. Das ist die häufigste Art, wie ein Knoten mit hoher Uptime enttäuscht: nichts ist kaputt, alles ist beschäftigt.

Auch der umgekehrte Fall lohnt sich zu merken. Ein Knoten, der vor einer Stunde neu gestartet wurde, kann jetzt völlig gesund sein, und die Sortierung nach der größten Zahl schließt ihn still aus. Uptime ist keine Qualitätsbewertung, und wer sie als eine behandelt, wählt nach Alter statt nach Eignung.

Aktualität: Der Bericht ist älter als Ihr Versuch

Öffentliche Verzeichnisse sind Seiten, die aus regelmäßigen Prüfungen erzeugt werden, keine Live-Telemetrie. Die Uptime, die Sie lesen, wurde bei der letzten Aktualisierung berechnet, und die Verbindung, die Sie versuchen, geschieht danach. Dazwischen kann ein Anbieter eine Strecke ausfallen lassen, ein Zertifikat wechseln, eine Adresse verschieben oder einen Knoten außer Betrieb nehmen, und die Seite meldet weiter den letzten bekannten guten Zustand bis zum nächsten Durchlauf.

Diese Lücke wirkt auch in die andere Richtung. Ein als ausgefallen gemeldeter Knoten kann sich Minuten nach Erzeugung des Berichts erholt haben, ein sofortiger neuer Versuch bei einem anderen Knoten ist also nicht immer die bessere Wahl.

Die praktische Regel lautet, dass jedes gemeldete Feld eine Aussage über die Vergangenheit ist. Nutzen Sie es für eine Auswahlliste und prüfen Sie dann mit einer Messung, die Sie selbst in dem Moment vornehmen, der Ihnen wichtig ist.

Was Sie stattdessen testen sollten

Entscheiden Sie, was Sie von dem Knoten brauchen, und testen Sie das. Brauchen Sie Erreichbarkeit, sagt Ihnen ein TCP-Verbindungsversuch zum lauschenden Port in einer Sekunde mehr als jeder Zähler. Brauchen Sie einen funktionierenden Tunnel, handeln Sie einen aus. Brauchen Sie nutzbaren Durchsatz, übertragen Sie etwas Echtes und messen Sie es, denn Verbindungszeit und Durchsatz sind verschiedene Eigenschaften, und ein schneller Handshake sagt nichts über die zweite.

nc -vz -w 5 vpn.example.net 1194
curl -sS -o /dev/null -w '%{time_connect} %{time_appconnect} %{time_total}\n' https://vpn.example.net/
mtr -rwc 20 vpn.example.net

Wiederholen Sie den Test, statt einem einzelnen Versuch zu vertrauen. Zuverlässigkeit ist eine Verteilung über Zeit und Bedingungen, und eine erfolgreiche Verbindung ist eine Stichprobe der Größe eins. Eine Handvoll Versuche über die Stunden, in denen Sie die Verbindung tatsächlich nutzen, schlägt jede veröffentlichte Uptime mit großem Abstand.

Öffentliche Knotenlisten lesen, ohne getäuscht zu werden

Uptime trägt auch keine Information über die Dinge, die Menschen üblicherweise von einem VPN wollen: Gültigkeit des Zertifikats, wer den Ausgang betreibt, welche DNS-Richtlinie gilt und ob der Betreiber Verbindungsprotokolle aufbewahrt. Das sind getrennte Aussagen, die getrennte Belege brauchen, und ein langer Zähler ist für keine davon ein Beleg. Ein Knoten kann monatelang stabil sein und trotzdem eine schlechte Wahl für eine Datenschutzanforderung.

Wo eine Liste wirklich hilft, ist bei der Auswahl. Sortieren Sie nach dem, was Sie sicher brauchen, filtern Sie Knoten in Regionen heraus, die für die Aufgabe irrelevant sind, und testen Sie dann die drei oder vier, die übrig bleiben. Behalten Sie die Fehlerstufe jedes Versuchs statt eines bloßen Ja oder Nein, denn „TLS-Handshake fehlgeschlagen“ und „verbunden, aber kein Durchsatz“ führen zu völlig verschiedenen Schlüssen.

Der Rahmen zur Messung der Pfadleistung macht denselben Punkt in strengerer Form: Definieren Sie die Metrik, die Bedingungen und die Methode, bevor Sie Zahlen erheben. Auf eine Knotenliste angewendet heißt das, das Uptime-Feld ist Kontext. Die Messung, die Sie selbst vornehmen, ist die Entscheidung.