keepalive d'OpenVPN ou redémarrage systemd : lequel récupère ?

Trois choses différentes peuvent mal tourner avec un tunnel, et elles appellent trois réactions différentes. Le pair cesse de répondre, le processus du démon meurt, ou l'application derrière le tunnel cesse de servir. Une configuration qui redémarre le service à chacun de ces cas n'est pas une supervision soigneuse ; c'est une action grossière appliquée à des défaillances sans rapport. Comparer ce que chaque mécanisme peut réellement observer rend la division du travail évidente.

Trois défaillances qui ressemblent à une

Le silence du pair signifie que l'autre extrémité a cessé d'envoyer, et OpenVPN peut le détecter lui-même parce qu'il possède le battement. La mort du processus signifie que le démon s'est arrêté, ce que le gestionnaire de services remarque et qu'OpenVPN ne peut pas. La défaillance de l'application signifie que le tunnel va bien et que quelque chose derrière ne va pas, et aucun des deux autres mécanismes n'a le moyen de le savoir. Chacune exige une réaction différente, et aucune n'est la même chose que remarquer que le tunnel est actif.

Ce sont des signaux différents de couches différentes, et chacun a un propriétaire qui peut agir dessus sans deviner. Les mélanger produit un système qui redémarre sur des symptômes qu'il ne peut pas interpréter.

Écrivez les trois cas avant de changer le moindre minuteur. La liste elle-même montre généralement qu'on demande à un mécanisme de couvrir les trois.

À quoi keepalive s'étend réellement

La directive keepalive est un raccourci, et l'extension diffère selon le mode. Sur un serveur, keepalive 10 60 devient un ping local toutes les dix secondes, un délai de redémarrage local de 120 secondes et des valeurs 10 et 60 transmises aux clients. Le délai du serveur est délibérément doublé afin qu'un client ait une chance de redémarrer avant que le serveur n'abandonne. Lisez la forme étendue dans la configuration en cours, pas le raccourci du profil.

Ce doublement est la raison pour laquelle toute description affirmant que les deux extrémités redémarrent après soixante secondes est fausse. Il explique aussi pourquoi les deux extrémités ne battent pas en phase quand un chemin se dégrade.

Le battement est du trafic de pairs OpenVPN, pas une sonde ICMP vers un hôte public. Une réponse prouve seulement que l'extrémité lointaine du tunnel est vivante. Elle ne dit rien de la base de données ou du service web dont l'utilisateur a réellement besoin.

Ce que Restart=on-failure ne surveille pas

Lisez l'unité installée avant d'ajouter une dérogation. Restart=on-failure répond à des conditions documentées de défaillance du processus, ce qui n'est pas la même chose que surveiller l'état de la connexion. Il ne se déclenche pas parce qu'une reconnexion interne a commencé, et une sortie propre a une sémantique différente d'un plantage.

Cette distinction compte parce qu'un redémarrage interne maintient le même processus en vie. L'unité ne voit rien, le tunnel se rétablit seul, et c'est le résultat correct.

Fixez RestartSec et les limites de démarrage délibérément, sinon une boucle de plantages martèlera la passerelle et enterrera la vraie erreur sous des messages de redémarrage. Une limite de redémarrage qui se déclenche laisse l'unité en échec, ce qui est visible, alors qu'une boucle illimitée ne l'est pas.

ping-restart et ping-exit ne sont pas interchangeables

ping-restart déclenche le redémarrage interne d'OpenVPN et conserve le processus. ping-exit termine le processus sur le même type de délai, ce qui remet la décision au gestionnaire de services. Ils s'excluent mutuellement, et choisir le second change qui possède la récupération. La différence est qui décide de réessayer, et quelle quantité d'état survit à la tentative.

Si vous choisissez la sortie sur délai, l'unité a besoin d'une politique de redémarrage et d'un traitement du statut de sortie qui correspondent, sinon une défaillance de vivacité ressemble à un arrêt définitif. Les options de persistance peuvent aussi préserver interfaces et routes lors d'un redémarrage interne, mais pas lors d'une sortie de processus.

Choisissez un cycle de vie par déploiement et écrivez pourquoi. Un profil qui porte les deux directives est un profil qui n'a pas décidé.

Testez chaque défaillance comme son propre cas

Simulez un pair silencieux, un démon tué et une application indisponible dans une fenêtre approuvée, puis vérifiez quelle récupération s'est déclenchée. Un pair silencieux devrait produire une reconnexion interne, un processus tué un redémarrage d'unité, et une panne d'application ni l'un ni l'autre. Quand deux cas produisent la même action, la propriété est encore mélangée.

La récupération répétée n'est pas non plus une réparation. Des identifiants rejetés ou deux clients partageant un nom effectif continueront de se remplacer, et des minuteurs plus rapides ne font qu'accélérer ce ballotement.