So messen Sie die Laufzeit des OpenVPN-Clients mit up- und down-Hooks

Ein Dashboard fragt nach einer Zahl dafür, wie lange die Verbindung schon steht, und OpenVPN liefert sie nicht. Der Client weiß, wann sein Tunnel hochkam, aber nur, wenn etwas diesen Moment festhält, bevor der Sitzungszustand verloren geht. Die unterstützte Stelle ist der up-Hook, und der Wert, den es zu speichern lohnt, ist eine rohe Epoch-Sekunde statt einer formatierten Zeichenkette. Alles danach ist Arithmetik, plus ein paar Ordnungsregeln, die entscheiden, ob die Zahl ehrlich bleibt.

Bestätigen Sie, dass die Hooks tatsächlich laufen

Beweisen Sie, dass der Hook auslöst, bevor Sie irgendetwas darum herum entwerfen. Eine minimale Client-Konfiguration braucht script-security 2 plus explizite Pfade up und down; ohne die Sicherheitszeile weigert sich OpenVPN, das Skript auszuführen, und sagt das deutlich. Fügen Sie up-restart und down-pre gleichzeitig hinzu, damit sich Neustart- und Abbau-Pfade vorhersehbar verhalten.

Lassen Sie die erste Version des Hooks seine Umgebung an eine Datei anhängen und sonst nichts tun. Das zeigt Ihnen die Variablennamen, die Ihr Build tatsächlich exportiert, etwa dev und script_type, statt derer, die Sie aus einer anderen Version kennen. Führen Sie eine Verbindung und eine Trennung aus, und lesen Sie dann die Datei. Erscheint nichts, hören Sie hier auf, denn ein Zeitstempel-Design auf einem Hook, der nie läuft, sieht wochenlang wie ein Überwachungsausfall aus.

Prüfen Sie, als welcher Benutzer der Hook läuft. Mit gesetztem user und group legt OpenVPN Privilegien ab, bevor es Skripte startet, sodass ein Verzeichnis, in das root schreiben kann, für den Hook gesperrt sein kann. Wählen Sie den Pfad aus Sicht des Dienstes statt aus Sicht Ihrer Shell.

Einen Epoch-Wert erfassen und bewusst löschen

Der up-Hook braucht eine Zeile, date +%s > /run/openvpn-client.started, mit einem pro Instanz angepassten Pfad. Ein Epoch-Wert vermeidet später Fragen zu Sprache, Zeitzone und Format, und es ist dieselbe Zahl, die ein Überwachungsagent mit seiner eigenen Uhr vergleichen kann.

Löschen ist genauso wichtig wie Schreiben. Der down-Hook sollte die Datei leeren oder entfernen, und down-pre sorgt dafür, bevor die Schnittstelle schließt, was das Fenster beseitigt, in dem die Datei einen Tunnel beschreibt, der schon weg ist. up-restart frischt den Stempel dann bei einem internen Neustart auf, statt den ursprünglichen Wert stehen zu lassen. Ohne dieses Paar ein Neustart nach Ping-Timeout ergibt eine Zahl, die weiter steigt, während der Tunnel sich neu aufbaut.

Wählen Sie einen Ort mit der richtigen Lebensdauer. Eine Datei unter /run verschwindet beim Neustart, was der Realität entspricht, während eine Datei unter /tmp unvorhersehbar aufgeräumt werden kann und eine im Konfigurationsverzeichnis auf irritierende Weise überlebt. Setzen Sie Rechte so, dass nur der Dienstbenutzer und der Überwachungsleser sie lesen können.

Laufzeit berechnen, ohne Logzeilen zu vertrauen

Lesen Sie die gespeicherte Sekunde, lesen Sie die aktuelle Sekunde, subtrahieren Sie. Fehlt die Datei oder ist sie leer, ist die ehrliche Antwort, dass kein Tunnel aktiv ist, nicht dass die Laufzeit null ist, denn diese beiden Zustände sollten unterschiedliche Alarme auslösen. Behalten Sie rohe Sekunden in der Überwachungsnutzlast und formatieren Sie Tage und Stunden in der Anzeigeschicht. Ein Formatierer, der im Exporter rundet, wirft Genauigkeit weg, die jemand während eines Vorfalls haben will.

Log-Zeitstempel zu parsen ist die verlockende Abkürzung, und sie scheitert auf drei Arten: das Format folgt den gesetzten Optionen, Rotation entfernt die Historie, und Neuverbindungen erscheinen als getrennte Sitzungen statt als ein durchgehender Tunnel. Der Hook zeichnet das Ereignis einmal auf, in dem Moment, in dem es geschieht.

Läuft die Prüfung auf einem anderen Host, senden Sie den Zeitstempel statt der Dauer, damit der Leser seine eigene Uhr anwendet. Ein kleines negatives Ergebnis liest sich dann als Uhrversatz statt als defekter Hook.

Neuverbindungen, Neustarts und mehrere Instanzen abdecken

Zwei Tunnel auf einem Host brauchen zwei Dateien, verschlüsselt mit dem Instanznamen, den der Dienst bereits verwendet. Ein gemeinsamer Pfad bedeutet, dass die jüngste Verbindung die Startzeit jedes Profils überschreibt, und das Symptom ist eine Zahl, die zurückspringt, wenn ein zweiter Tunnel startet.

Das Verhalten bei Neuverbindungen verdient einen eigenen Test, denn dort meldet ein plausibles Design still das Falsche. Erzwingen Sie einen Neustart, indem Sie den Peer verwerfen oder dem Prozess ein Signal senden, und vergleichen Sie dann den Schnittstellenzustand mit der Datei. Der Zeitstempel sollte im Moment der Rückkehr des Tunnels vorrücken.

Auf der Serverseite trägt die Statusdatei einen connected-since-Wert pro Client, der eine andere Frage beantwortet: wann der Server diesen Peer zuletzt gesehen hat. Nutzen Sie ihn zur Gegenprüfung statt als Ersatz, denn er verschwindet mit der Sitzung, die er beschreibt. Keine der beiden Messungen sagt etwas über die Gesundheit der Anwendung hinter dem Tunnel.

Führen Sie die drei Prüfungen aus, die Ordnungsfehler fangen

Testen Sie eine normale Verbindung, eine erzwungene Neuverbindung und ein sauberes Stoppen, und lesen Sie nach jedem die Schnittstellenliste und die Datei zusammen. Ein Stempel, der nach einem sauberen Stopp noch vorhanden ist, oder eine Datei, die einen Tunnel behauptet, den die Schnittstellenliste nicht enthält, deutet direkt auf die Hook-Reihenfolge. Führen Sie die Prüfungen als Dienstbenutzer und mit den Pfaden des Dienstes aus, denn eine root-Shell kann eine andere Datei sehen und eine selbstsichere falsche Antwort geben. Lassen Sie dann einen langsamen Poller die Datei lesen und bestätigen Sie, dass er nie hineinschreibt.

Eine Abfrage alle sechzig Sekunden deckt die Alarmierung ab, und kein Hook sollte sich darauf verlassen, dass dieser Poller lebt. Halten Sie diese beiden Zuständigkeiten getrennt, und die Zahl bleibt verlässlich, wenn eine der Seiten neu ausgerollt wird.