Coupure horaire d’OpenVPN : renégociation ou vraie reconnexion ?

Soixante minutes, ou trente, ou cent vingt : une coupure qui tombe sur un intervalle rond n’est presque jamais le réseau. OpenVPN renouvelle selon un minuteur la matière de clés qui protège le canal de données, et un minuteur plus court que celui que vous supposiez ressemble exactement à un lien qui échoue sans cesse. Les utilisateurs signalent une connexion rompue alors que le journal signale un échange de clés réussi. Le guide ci-dessous sépare ce renouvellement d’un vrai redémarrage, lit la valeur réellement en vigueur et ne la change qu’une fois le coût sur la table.

Suivez les étapes dans l’ordre, car la première décide si le reste de la page vous concerne vraiment. Sautez en avant et vous passerez une soirée à régler un minuteur pour une panne qui n’a rien à voir avec lui.

Distinguez une réinitialisation douce d’un redémarrage

La ligne de journal est tout le diagnostic. Une renégociation écrit une réinitialisation douce puis un nouvel échange de clés dans le même tunnel : l’interface conserve son adresse, les routes ne sont pas rajoutées, et les sessions TCP établies survivent généralement avec une pause. Un vrai redémarrage déchire la session, reconstruit l’interface, peut attribuer une autre adresse de client et tue toute connexion de longue durée. Les deux événements sont ordinaires ; un seul explique un appel coupé.

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'soft reset|Connection reset|reneg|TLS Error'
openvpn --version | head -n 1

La ligne de version compte parce que la formulation du journal évolue entre les versions, et un message dont vous vous souvenez en 2.3 peut être formulé autrement en 2.6. Lisez votre propre journal plutôt qu’un extrait de forum pris chez quelqu’un d’autre. Citez la ligne exacte quand vous demandez de l’aide, car une paraphrase perd le détail qui identifie l’événement. Si l’adresse de l’interface ne change pas pendant l’événement et que la liste des sessions survit, vous voyez un renouvellement et les sections suivantes s’appliquent.

Lisez le minuteur effectif, pas votre fichier

reneg-sec est le nombre de secondes entre les renégociations du canal de données et sa valeur par défaut est 3600. Chaque pair porte sa propre valeur, et la plus petite des deux est celle qui déclenche réellement le renouvellement. Cette seule règle explique la plupart des signalements : un profil client qui fixe un grand nombre est quand même réinitialisé toutes les heures tant que le serveur garde la valeur par défaut.

grep -Rn --include='*.conf' -E 'reneg-sec|reneg-bytes' /etc/openvpn
# server side, including included files
grep -Rn -E '^reneg-sec' /etc/openvpn/server/

Lisez aussi la configuration effective du serveur, y compris tout ce qu’il pousse, avant de conclure à partir du fichier client. Montez ensuite la verbosité et observez un intervalle de bout en bout : le niveau 3 montre déjà les lignes de renégociation, et les horodatages disent si l’événement se répète toutes les 3600 secondes ou suit l’activité.

Changez-le là où il est réellement poussé

Le remède qui circule est une seule ligne dans le profil client, et c’est le mauvais endroit environ la moitié du temps. Comme la valeur la plus basse des pairs gagne, un client qui met le minuteur à zéro peut encore être renégocié par un serveur qui n’a pas changé.

# on both ends, or on the side that owns the pushed configuration
reneg-sec 0

Là où les profils sont générés de façon centralisée, modifiez le modèle plutôt que la copie déployée, sinon la prochaine exécution de provisionnement restaurera la valeur que vous venez d’enlever. Vérifiez en observant deux intervalles, pas un : une seule heure calme est compatible avec un minuteur réglé à 7200.

Décidez aussi de ce qui se passe lors d’un déploiement mixte. Déployer le changement d’abord sur les clients laisse une fenêtre où le serveur déclenche encore le renouvellement, ce qui est inoffensif mais déroutant si vous surveillez les journaux pour confirmer. Changez d’abord le côté qui porte la valeur la plus petite et le symptôme disparaît au point que vous attendez.

Ce que vous cédez en désactivant la renégociation

La renégociation régulière limite la durée pendant laquelle un seul jeu de clés du canal de données protège le trafic. Couper le minuteur ne casse pas le tunnel, et sur un routeur domestique ou une passerelle de petit bureau l’exposition pratique reste modeste. C’est tout de même un échange, et l’échange mérite d’être énoncé avant d’être fait. Ce qui change, c’est la durée pendant laquelle un jeu de clés protège une session, pas le fait que le tunnel fonctionne ou non.

Le cas raisonnable pour le désactiver est une réinitialisation qui casse quelque chose qui ne peut pas reprendre : un appel qui tombe, une session de bureau distant qu’il faut rétablir, une sauvegarde qui repart du début. Si la pause est invisible pour les utilisateurs, garder la valeur par défaut ne coûte rien et conserve la rotation de clés qui vous a été donnée.

Préférez corriger la cause quand le schéma le permet. Un renouvellement qui échoue en cours de route alors que la première poignée de main a réussi pointe le chemin plutôt que le minuteur : cherchez un problème de taille de paquet dans l’échange plus gros du canal de contrôle, un pare-feu à états qui jette le flux, ou une proposition qui ne réussit qu’à la première tentative. Chacun laisse une trace dans le même journal que vous venez de lire. Désactiver le minuteur cache cette preuve.

Quand l’intervalle pointe ailleurs

Deux voisins dans la configuration produisent des symptômes similaires et des correctifs différents. ping-restart redémarre le tunnel quand rien n’arrive pendant une période configurée, tandis que ping-exit coupe complètement le client. Une coupure d’inactivité sans aucune renégociation dans le journal appartient à ceux-ci, ou à un appareil NAT qui a laissé expirer la correspondance UDP selon son propre calendrier.

Les routeurs grand public, les points d’accès mobiles et le NAT opérateur laissent expirer les sessions UDP inactives sans prévenir personne. Cette panne suit l’inactivité plutôt que l’horloge, et c’est l’indice : une session qui tombe après dix minutes calmes et survit une heure de trafic régulier ne renégocie pas.

Notez trois choses avant d’en changer une quatrième : l’intervalle mesuré, la valeur effective trouvée et la commande qui l’a montrée. Si l’intervalle bouge quand le minuteur bouge, le mécanisme est identifié et le correctif est une décision sur l’échange ci-dessus. S’il ne bouge pas, remettez le réglage et continuez à regarder les keepalives, l’état du NAT et la perte de paquets.