OpenVPN réessaie sans fin après une erreur TLS : comment l’arrêter

Le client se connecte, échoue pendant la négociation TLS, attend et retente le même serveur avec le même résultat. Sous un superviseur qui redémarre un processus en échec, ces tentatives deviennent une boucle sans fin dans le journal, et la première ligne de diagnostic sort du champ. OpenVPN fournit une option qui transforme cet échec de négociation en une sortie visible plutôt qu’en une nouvelle tentative. C’est un réglage de diagnostic et de supervision, pas une réparation, alors associez-le à une politique qui laisse vraiment le processus s’arrêter.

Le cycle qui masque la première erreur

Ce que vous voyez est un bloc qui se répète et non une seule panne : une tentative de connexion, une erreur TLS, une pause, puis la même séquence. Chaque répétition pousse la ligne d’origine plus haut dans le journal. Si l’unité redémarre en cas d’échec, le cycle peut durer des heures sans que personne ne lise la cause. Le symptôme est la boucle, même si le défaut sous-jacent est un seul problème de négociation.

Les sessions interactives le tolèrent parce qu’un échec passager peut disparaître à la tentative suivante. Les connexions automatisées ne peuvent pas se permettre le même optimisme : le processus doit s’arrêter pour qu’un humain ou une supervision voie l’état.

Avant de changer quoi que ce soit, capturez un cycle complet. Notez l’adresse distante, l’étape TLS nommée dans l’erreur et si le processus sort réellement.

La machinerie de réessai derrière la boucle

Le réessai est la valeur par défaut parce que plusieurs délais indépendants partagent la même machinerie. connect-retry fixe l’écart entre les tentatives de connexion, connect-retry-max peut plafonner la fréquence d’essai de chaque entrée distante, et resolv-retry régit les recherches de noms répétées. Un échec de négociation TLS atteint cette machinerie comme un événement de transport, donc le client planifie une nouvelle tentative au lieu de signaler. La valeur par défaut aide sur une liaison instable et nuit à un défaut qui ne peut pas guérir.

L’option --tls-exit ne change que le cas de la négociation. Le manuel la décrit comme une sortie en cas d’échec de négociation TLS, ce qui est plus étroit qu’une sortie à chaque erreur. Les délais d’attente, les échecs de résolveur et les rejets d’authentification gardent leur propre comportement.

Faire sortir le client en cas d’échec TLS

Placez tls-exit dans le profil que le client charge réellement, ou passez --tls-exit au démarrage, puis exécutez-le une fois au premier plan. Lisez le code de sortie ainsi que la dernière ligne de journal, car c’est le code sur lequel agit un superviseur. Une sortie non nulle après un échec de négociation est le résultat attendu. Si le processus continue de réessayer au lieu de se terminer, l’option ne figure pas dans le profil que le client charge réellement.

Le superviseur décide si cette sortie est visible. Une unité systemd avec Restart=always ou Restart=on-failure redémarre le client, donc la boucle continue et l’option semble ne rien faire. Vérifiez la politique avant d’accuser le client :

systemctl show -p Restart -p RestartSec openvpn-client@office
journalctl -u openvpn-client@office -n 40 --no-pager

Restart=no laisse le processus s’arrêter, et Restart=on-failure redémarre encore après un code non nul. Si vous voulez que l’échec soit visible mais que le service se remette de plantages sans rapport, définissez Restart=on-failure et utilisez StartLimitBurst et StartLimitIntervalSec pour arrêter la tempête de redémarrages. Lisez ensuite l’état de l’unité pour confirmer le dernier code de sortie : systemctl status le rapporte, et le journal conserve la première erreur au-dessus des redémarrages.

Écrivez la décision dans l’unité ou dans les notes du profil. Un profil qui sort en cas d’échec TLS ressemble à un accident pour la personne suivante, sauf si la raison est consignée. Indiquez quels échecs doivent arrêter le processus et lesquels doivent être réessayés.

Le prouver avec un point de terminaison jetable

Pour voir le comportement avant de lui faire confiance, copiez le profil et pointez la copie vers un point de terminaison qui accepte une connexion TCP mais ne parle jamais OpenVPN. Un écouteur qui répond puis reste silencieux suffit. Avec tls-exit, le client devrait se terminer quand la poignée de main échoue ; sans elle, le même profil devrait continuer de boucler. Utilisez la copie, jamais le profil de travail.

Comparez les deux exécutions par le code de sortie et par la première ligne d’erreur, pas par leur durée. Le code dit si l’option s’est déclenchée, et la première ligne dit quelle étape a échoué.

Supprimez le profil de test quand vous avez terminé. Une copie avec un point de terminaison volontairement erroné est un piège pour quiconque démarre plus tard tous les profils du répertoire.

Les étapes que cette option n’atteint jamais

Un rejet d’authentification est une étape ultérieure. Si le serveur évalue le compte et le refuse, TLS a déjà été négocié, donc tls-exit ne se déclenche pas. Les réglages de réessai d’authentification sont le prochain endroit à regarder, et la raison du serveur compte plus que la dernière ligne du client. Un mauvais mot de passe et un certificat manquant peuvent produire des messages similaires côté client.

Une route manquante, un résolveur incorrect ou une passerelle injoignable sont aussi hors de l’option, car ce ne sont pas des échecs de négociation. La perte silencieuse de paquets est le cas le moins évident : selon l’avancement de l’échange, le client peut signaler un échec de négociation ou simplement expirer.

Gardez la distinction dans vos notes. Le réglage sert au diagnostic et à la supervision plutôt qu’à la réparation, donc il ne corrige pas une incompatibilité de chiffrement, un problème de certificat ni un mauvais port. Réparez d’abord la cause de la négociation échouée, puis décidez si une sortie immédiate convient encore au déploiement.