Deux appareils, un certificat OpenVPN : la boucle de reconnexion

Un tunnel qui monte puis redémarre toutes les demi-minutes n’est généralement pas un problème de chiffrement ni de MTU. C’est une identité utilisée deux fois. Le serveur voit un nom commun familier, prend la nouvelle session pour la plus récente, et l’appareil plus ancien découvre qu’il a été remplacé. Côté client, cela ressemble à un délai d’inactivité expiré et à un redémarrage, ce qui explique pourquoi l’enquête commence si souvent au mauvais endroit.

Partez de l’intervalle de redémarrage

L’intervalle est un indice avant tout le reste. Une cadence régulière qui correspond à la fenêtre ping-restart pointe vers une session remplacée plutôt que vers un chemin défaillant, car les pannes de chemin sont rarement aussi régulières. Notez l’écart exact entre les redémarrages et la ligne de motif dans le journal du client. Un délai expiré suivi d’un redémarrage raconte une autre histoire qu’une poignée de main ratée.

Vérifiez quand les redémarrages ont commencé par rapport à un second appareil. Un nouvel ordinateur portable, un téléphone ou un profil copié sur une machine de secours sont les déclencheurs habituels, et le moment correspond souvent au jour où quelqu’un l’a configuré.

Notez l’intervalle et le motif. Les deux sont des preuves, et les deux coûtent peu à recueillir.

Lisez ce que le serveur a dit de la seconde connexion

Sur un serveur que vous contrôlez, le journal nomme le nom commun et montre une seconde connexion qui arrive. Sans duplicate-cn, cette arrivée remplace la session existante pour le même nom, et le message le dit généralement clairement. Avec duplicate-cn, les deux sessions coexistent et le symptôme change : les clients restent connectés mais partagent un seul jeu de réglages par client et une seule décision de révocation. Lisez les deux entrées ensemble, car le remplacement n’est visible que dans l’ordre.

Sur un service hébergé, vous n’avez peut-être aucun journal de serveur. L’indice est alors le moment : un tunnel stable qui tombe chaque fois qu’une autre machine se connecte, sans rien dans le journal du client au-delà du délai expiré.

Comparez les blocs de certificat et de clé des deux profils, pas seulement le nom d’hôte distant. Les profils copiés ne diffèrent généralement que par le nom de fichier.

Séparez l’identité côté serveur

Émettez un certificat par appareil via l’autorité qui signe pour ce serveur. Avec Easy-RSA, cela signifie un nom de client distinct pour chaque appareil, et le profil est ensuite construit à partir de ce certificat et de sa clé. Le nom commun devient l’identité de l’appareil, ce qui est exactement ce qui manquait au serveur. Nommez-les d’après l’appareil plutôt que la personne, afin qu’un remplacement produise un nouveau nom.

La clé partagée du canal de contrôle est autre chose. tls-crypt ou tls-auth protège le canal de contrôle de chaque client et est destiné à être partagé. Ce n’est pas une identité de client, et la remplacer ne corrigera pas un certificat dupliqué.

Gardez le certificat, la clé et tout fichier de configuration par client sous le même nom commun, sinon la correspondance casse à la prochaine connexion. Une incohérence à cet endroit produit un client qui s’authentifie puis ne reçoit rien.

Maintenez les adresses et les réglages alignés après la séparation

Les adresses fixes introduisent une seconde façon d’entrer en collision. Si le serveur les attribue via ifconfig-pool-persist ou un fichier par client, ces enregistrements pointent encore vers l’ancien nom. Deux appareils peuvent se retrouver avec la même adresse de tunnel même après la séparation des certificats, et cette panne ne ressemble pas à la boucle d’origine.

Mettez à jour la correspondance en même temps que le certificat, puis reconnectez les deux appareils et comparez leurs adresses attribuées. Une adresse dupliquée se manifeste par des pertes intermittentes plutôt que par une reconnexion propre.

Poussez les réglages qui doivent différer par appareil via le fichier propre à cet appareil, pas via un modèle partagé. Un modèle partagé rend aussi le prochain doublon plus difficile à repérer.

Retirez proprement l’ancienne identité

Révoquez le certificat quand le matériel est retiré ou manquant, au lieu de supprimer le profil de l’ancienne machine. La révocation produit une nouvelle CRL, et le serveur a besoin de ce fichier là où crl-verify pointe. Avec cette directive en place, une CRL absente ou illisible fait rejeter tous les clients par le serveur, alors testez un compte connu après chaque mise à jour.

Tenez un inventaire qui relie chaque certificat à une personne ou un appareil, avec les dates d’émission et de révocation. Cet inventaire répond qui a encore accès sans lire les noms de fichiers, et il empêche le prochain profil copié de relancer la boucle.