Comment mesurer la durée de fonctionnement du client OpenVPN avec les crochets up et down
OpenVPN n'a pas de compteur de disponibilité. Stockez un horodatage epoch depuis le crochet up, effacez-le sur down, soustrayez-le et gardez-le honnête à travers les redémarrages et les instances.
Un tableau de bord demande un chiffre indiquant depuis combien de temps la connexion est active, et OpenVPN ne le fournit pas. Le client sait quand son tunnel est monté, mais seulement si quelque chose enregistre ce moment avant que l'état de session ne soit perdu. L'endroit pris en charge est le crochet up, et la valeur qui mérite d'être stockée est une seconde epoch brute plutôt qu'une chaîne formatée. Tout le reste est de l'arithmétique, plus quelques règles d'ordre qui décident si le chiffre reste honnête.
Vérifiez que les crochets s'exécutent réellement
Prouvez que le crochet se déclenche avant de concevoir quoi que ce soit autour de lui. Une configuration client minimale nécessite script-security 2 ainsi que des chemins explicites up et down ; sans la ligne de sécurité, OpenVPN refuse d'exécuter le script et le dit clairement. Ajoutez up-restart et down-pre en même temps pour que les chemins de redémarrage et de démontage se comportent de façon prévisible.
Faites en sorte que la première version du crochet ajoute son environnement à un fichier et ne fasse rien d'autre. Cela vous indique les noms de variables que votre build exporte réellement, comme dev et script_type, plutôt que ceux dont vous vous souvenez d'une autre version. Lancez une connexion et une déconnexion, puis lisez le fichier. Si rien n'apparaît, arrêtez-vous ici, car une conception d'horodatage posée sur un crochet qui ne s'exécute jamais ressemblera à une panne de supervision pendant des semaines.
Vérifiez sous quel utilisateur le crochet s'exécute. Avec user et group définis, OpenVPN abandonne ses privilèges avant d'exécuter les scripts, si bien qu'un répertoire où root peut écrire peut être fermé au crochet. Choisissez le chemin du point de vue du service plutôt que de votre shell.
Enregistrez une seule valeur epoch et effacez-la délibérément
Le crochet up a besoin d'une ligne, date +%s > /run/openvpn-client.started, avec le chemin ajusté par instance. Une valeur epoch évite plus tard les questions de langue, de fuseau horaire et de format, et c'est le même nombre qu'un agent de supervision peut comparer à sa propre horloge.
L'effacement compte autant que l'écriture. Le crochet down doit vider ou supprimer le fichier, et down-pre fait en sorte que cela se produise avant la fermeture de l'interface, ce qui supprime la fenêtre où le fichier décrit un tunnel déjà disparu. up-restart rafraîchit ensuite l'horodatage lors d'un redémarrage interne au lieu de laisser la valeur d'origine en place. Sans cette paire, un redémarrage après expiration du ping produit un nombre qui continue de grimper pendant que le tunnel se rétablit.
Choisissez un emplacement avec la bonne durée de vie. Un fichier sous /run disparaît au redémarrage, ce qui correspond à la réalité, tandis qu'un fichier sous /tmp peut être nettoyé de façon imprévisible et qu'un fichier dans le répertoire de configuration survit d'une manière trompeuse. Réglez les permissions pour que seul l'utilisateur du service et le lecteur de supervision puissent le lire.
Calculez la disponibilité sans faire confiance aux lignes de journal
Lisez la seconde stockée, lisez la seconde courante, soustrayez. Quand le fichier est absent ou vide, la réponse honnête est qu'aucun tunnel n'est actif, et non que la disponibilité est nulle, car ces deux états devraient déclencher des alertes différentes. Gardez les secondes brutes dans la charge de supervision et formatez les jours et les heures dans la couche d'affichage. Un formateur qui arrondit à l'intérieur de l'exportateur jette une précision que quelqu'un voudra pendant un incident.
Analyser les horodatages du journal est le raccourci tentant, et il échoue de trois façons : le format suit les options définies, la rotation supprime l'historique et les reconnexions apparaissent comme des sessions distinctes plutôt qu'un seul tunnel continu. Le crochet enregistre l'événement une fois, au moment où il se produit.
Quand la vérification s'exécute sur un autre hôte, envoyez l'horodatage plutôt que la durée pour que le lecteur applique sa propre horloge. Un petit résultat négatif se lit alors comme un décalage d'horloge plutôt que comme un crochet cassé.
Couvrez les reconnexions, les redémarrages et les instances multiples
Deux tunnels sur un même hôte nécessitent deux fichiers, indexés par le nom d'instance que le service utilise déjà. Un chemin partagé signifie que la connexion la plus récente écrase l'heure de début de chaque profil, et le symptôme est un nombre qui recule quand un second tunnel démarre.
Le comportement de reconnexion mérite son propre test, car c'est là qu'une conception plausible signale discrètement la mauvaise chose. Forcez un redémarrage en abandonnant le pair ou en envoyant un signal au processus, puis comparez l'état de l'interface avec le fichier. L'horodatage devrait avancer au moment où le tunnel revient.
Côté serveur, le fichier d'état porte une valeur connected-since par client, qui répond à une autre question : quand le serveur a vu ce pair pour la dernière fois. Utilisez-la pour le recoupement et non comme un remplacement, puisqu'elle disparaît avec la session qu'elle décrit. Aucune des deux mesures ne dit quoi que ce soit sur la santé de l'application derrière le tunnel.
Exécutez les trois contrôles qui attrapent les erreurs d'ordre
Testez une connexion normale, une reconnexion forcée et un arrêt propre, en lisant la liste des interfaces et le fichier ensemble après chacun. Un horodatage encore présent après un arrêt propre, ou un fichier qui affirme un tunnel absent de la liste des interfaces, désigne directement l'ordre des crochets. Exécutez les contrôles en tant qu'utilisateur du service et avec les chemins du service, car un shell root peut voir un autre fichier et donner une réponse fausse avec assurance. Laissez ensuite un sondeur lent lire le fichier et confirmez qu'il n'y écrit jamais.
Une interrogation toutes les soixante secondes couvre l'alerte, et aucun crochet ne devrait compter sur la vie de ce sondeur. Gardez ces deux responsabilités séparées et le nombre reste fiable quand l'un ou l'autre côté est redéployé.