Clé statique ou TLS pour une liaison OpenVPN entre deux pairs ?

Deux machines qui ne parlent qu’entre elles peuvent conserver cette topologie et obtenir malgré tout des clés de trafic négociées. La forme du réseau et le mode de protection sont des choix indépendants, et c’est les confondre qui pousse les gens à tenter de renouveler un secret statique en remplaçant un fichier pendant que les deux démons continuent de tourner. Remplacer le fichier de clé sous une paire en fonctionnement ne renouvelle rien. Le mode à clé statique, qu’OpenVPN 2.6 marque comme obsolète, ne tient qu’une seule clé pendant toute la durée de vie du tunnel, si bien que le fichier sur disque et la clé en mémoire ne concordent de nouveau qu’après le redémarrage des deux extrémités. Si le renouvellement automatique est l’exigence, le mode de protection doit changer.

Ce que le mode à clé statique ne peut pas faire

En mode secret, les deux pairs partagent une clé pré-partagée qui chiffre et authentifie directement le tunnel. Il n’y a pas de poignée de main, donc aucun mécanisme permettant à un côté de proposer de la nouvelle matière de clé, de prouver une identité ou de se remettre d’une divergence sans intervention de l’opérateur. Les deux propriétés découlent de l’absence de canal de contrôle plutôt que d’une option manquante, et aucun indicateur de configuration n’en ajoute un à ce mode.

Le manuel d’OpenVPN 2.6 indique explicitement que la clé persiste jusqu’à ce qu’une nouvelle soit générée. C’est acceptable pour une liaison de laboratoire ou une paire fixe d’appareils dotée d’une procédure de renouvellement documentée, et inacceptable partout où un secret de longue durée constitue un risque réel. Un remplacement de fichier ne crée pas de nouvelle clé pour une paire en fonctionnement ; il crée deux pairs en désaccord. Remplacer le fichier ajoute donc une interruption sans ajouter de renouvellement.

Il n’existe pas non plus de notion d’identité de pair au-delà de la possession du fichier. Quiconque détient la clé est un pair, et rien dans le tunnel n’enregistre quel côté est lequel, si bien que la révocation est tout ou rien.

Passer à TLS sans reconcevoir la liaison

Le mode TLS ajoute un canal de contrôle et, avec lui, la capacité de négocier les clés du canal de données. Dans un déploiement point à point, un côté prend le rôle de serveur et l’autre celui de client, mais la topologie reste une liaison entre deux pairs : chaque côté connaît le point de terminaison de l’autre, et aucun pool ni service multi-utilisateur n’apparaît. Les rôles sont un détail de la poignée de main, pas une nouvelle architecture.

Donnez à chaque machine sa propre identité. Chaque côté a besoin d’un certificat et d’une clé privée, de l’ancre de confiance qui valide l’autre, et d’une règle de vérification de pair qui nomme qui est attendu. Ne réutilisez pas la clé privée d’un pair sur l’autre pour gagner du temps ; cela transforme deux identités en une et supprime la possibilité de révoquer chaque côté séparément. L’enrôlement est l’endroit où faire cela correctement, car le corriger plus tard signifie réémettre des certificats.

Gardez le contrat réseau inchangé pendant que la protection change. Les mêmes adresses de tunnel, routes et services autorisés devraient s’appliquer avant et après, afin qu’une défaillance pendant la migration soit un problème de protection et non une surprise de routage déguisée. Notez les adresses et les routes avant le changement ; les comparer ensuite est plus rapide que de les reconstruire de mémoire.

Certains déploiements protègent aussi le canal de contrôle par sa propre clé statique, qui ne se renouvelle pas avec le canal de données. Cette clé garde la poignée de main plutôt que la charge utile, si bien que sa compromission expose la négociation et non le trafic. Stockez-la à part de la matière du canal de données et attribuez-lui une date de remplacement dont une personne nommée est responsable. La renouveler implique de redémarrer les deux pairs dans une fenêtre coordonnée, ce qui lui vaut une entrée d’agenda plutôt qu’un souvenir.

Qui renouvelle quoi, et quand

En mode TLS, le renouvellement est piloté par des limites configurées : un intervalle de temps, un nombre d’octets ou un nombre de paquets. Le contrôle temporel documenté est ce sur quoi la plupart des déploiements s’appuient, et la valeur effective la plus basse entre les deux pairs peut déclencher le remplacement, si bien que l’augmenter d’un seul côté ne retiendra pas l’événement. Les limites fondées sur le volume existent parce qu’une liaison chargée peut épuiser une clé bien avant l’horloge. Aucune des deux limites n’est un contrôle de santé, et aucune ne vous dit qu’un renouvellement a réussi.

C’est pourquoi diagnostiquer une renégociation récurrente à partir d’un seul fichier de configuration est trompeur. Lisez les réglages sur les deux pairs, puis regardez la transition dans le journal au lieu de supposer une panne. Un renouvellement qui se termine proprement ressemble à une courte rafale de trafic du canal de contrôle, pas à une déconnexion.

Gardez les objets séparés dans votre tête. Le certificat prouve l’identité à long terme et est remplacé selon un calendrier que vous contrôlez. La clé du canal de données est rafraîchie automatiquement, et un échange d’authentification distinct, si le déploiement en exige un, suit la politique du compte et peut nécessiter ses propres dispositions pour les échanges ultérieurs.

Désactiver entièrement le renouvellement, en réglant l’intervalle à zéro, n’est pas une solution à un journal bruyant. Cela transforme un événement sain du cycle de vie en clé permanente, ce qui vous ramène à la propriété que vous cherchiez à quitter.

Accepter le changement

Construisez la nouvelle configuration à partir de l’exemple pris en charge de la version installée, et non d’un ancien extrait minimal dont les algorithmes et les chemins de fichiers ont été hérités d’ailleurs. Coordonnez le basculement pour que les deux pairs changent ensemble, et conservez un chemin de récupération approuvé au cas où un côté ne démarre pas. Coupez la liaison délibérément plutôt que d’attendre une panne pour tester le retour arrière. Un retour arrière que vous avez répété vaut plus qu’un retour arrière que vous avez décrit.

Testez trois choses : la vérification initiale d’identité réussit, le flux applicatif prévu fonctionne et un renouvellement contrôlé se produit sans perte de trafic. Lisez ensuite la transition dans le journal pour ce qu’elle prouve réellement : un nouvel identifiant de clé signifie que les pairs ont achevé un remplacement, pas que le tunnel s’est reconnecté. Traitez-la comme la preuve d’une étape et vérifiez les compteurs de trafic avant de déclarer la migration terminée.

Ce qu’une promesse de zéro interruption masquerait, c’est la défaillance que vous n’avez pas encore vue. Un renouvellement qui échoue, un certificat qui expire ou un défaut de chemin peuvent encore perturber la liaison, et aucun n’est écarté par une exécution de test propre. La propriété pour laquelle il vaut la peine de concevoir est plus étroite et plus utile : le remplacement courant des clés cesse d’être un échange manuel de fichier.