Redémarrer OpenVPN chaque jour ? Choisissez la panne, pas l’horloge

Vous héritez d’une tâche cron qui redémarre OpenVPN chaque jour à 04:10, et qui maintient les choses stables depuis un an. Elle déconnecte aussi un tunnel sain à une heure fixe et ne fait rien contre la panne qui se produit réellement à midi. Un redémarrage calendaire est une décision de maintenance. La reprise est une autre conception, avec un déclencheur précis.

Trois formes de panne exigent trois propriétaires différents. Choisissez d’abord la panne, et le mécanisme suivra.

Trois pannes, trois propriétaires

Un tunnel peut être opérationnel alors que son pair a disparu : le processus tourne, l’interface existe et rien d’utile ne la traverse. Un processus peut être mort alors que le pair va bien, et seul ce qui l’a lancé peut alors le relancer. Une application derrière le tunnel peut être cassée alors que le tunnel et le pair sont tous deux sains, et redémarrer le client élargit alors la panne sans toucher à la cause. Séparer ces trois cas, c’est toute la décision.

Chacun a son propre signal et son propre propriétaire. La vivacité relève du protocole VPN, le cycle de vie du processus relève du gestionnaire de services, et la santé de l’application relève d’une supervision au mandat étroit.

Ce qu’une option de vivacité peut faire et ne peut pas faire

keepalive est un auxiliaire qui se déploie en une paire ping et ping-restart, comme le décrit la référence des options de liaison, et les délais qu’il produit ne sont pas identiques côté serveur et côté client. Les valeurs poussées par un serveur peuvent aussi remplacer ce qu’un client a configuré localement, et c’est pourquoi un délai qui semble correct dans un fichier local n’est peut-être pas celui qui s’applique.

Cela en fait le bon outil pour un pair perdu et le mauvais outil pour un processus mort, car un processus terminé ne peut pas exécuter ses propres minuteries. Il ne dit rien non plus sur la réponse d’une application derrière le tunnel, car l’échange a lieu entre les deux extrémités du VPN. Copier une paire de délais depuis un autre déploiement sans vérifier le rôle, les interruptions attendues et le comportement de réauthentification, c’est ainsi qu’un tunnel stable se met à vaciller.

Ce que possède le gestionnaire de services

Si le démon s’arrête, le gestionnaire qui l’a lancé décide de la suite. Une politique de redémarrage liée à l’échec, avec un délai et une limite de fréquence de démarrage, gère une boucle de plantage sans la transformer en fork bomb. Ces réglages réagissent aux résultats du processus et aux délais, et ils ne détectent pas un processus vivant mais inutile. Ce n’est pas un manque à combler par une politique plus large ; c’est la frontière entre cycle de vie et vivacité.

La propriété compte autant que les réglages. Une connexion lancée par un gestionnaire de réseau de bureau devrait conserver le dispositif de reprise de ce gestionnaire, et ajouter une unité de service concurrente pour la même interface donne deux propriétaires à un seul tunnel. Choisissez-en un et écrivez lequel.

Quand un redémarrage planifié est légitime

Un redémarrage à heure fixe peut être une action de maintenance raisonnable : il a un propriétaire, une fenêtre, une instance nommée et un accès indépendant. Ce qu’il ne peut pas être, c’est une politique générale de fiabilité qui déconnecte aussi tout le monde à une heure fixe.

Si le redémarrage existe pour contourner une fuite connue ou un état bloqué, dites-le dans la description de l’unité, faute de quoi la personne suivante le gardera pour toujours.

Testez les cas qui comptent : le pair disparaît pendant que le processus reste actif, le processus se termine, une nouvelle tentative exige des identifiants frais, et le tunnel revient alors que l’application reste cassée. Observez quel composant réagit et quel état il laisse derrière lui.

La bonne question n’est pas à quelle fréquence redémarrer, mais ce qui devrait remarquer la panne en premier.