Pourquoi ajouter opt-verify ne corrigera pas votre erreur de chiffrement OpenVPN
L’option vérifiait la cohérence des chaînes d’options et a disparu en 2.7. Un profil qui se parse encore ne prouve rien sur la couche de chiffrement, TLS ou de certificat.
Vous trouvez une suggestion d’ajouter opt-verify, vous ajoutez la ligne, et l’erreur de chiffrement reste exactement là où elle était. Ce résultat est prévisible, car l’option n’a jamais négocié de chiffrement. C’était une vérification de cohérence des options, obsolète en 2.6 et supprimée en 2.7, et un profil qui se parse encore avec elle n’a pas pour autant imposé quoi que ce soit.
Il est utile de savoir ce que la ligne faisait auparavant avant de conclure qu’elle est la pièce manquante. L’historique explique aussi pourquoi elle ne peut pas aider maintenant.
Ce que l’option imposait autrefois
Le manuel de la 2.6 marque opt-verify comme obsolète et décrit le comportement antérieur : le serveur rejette les clients dont les options déclarées ne correspondent pas aux siennes, en comparant des éléments comme le type d’appareil et la MTU. Cette vérification dépend aussi du maintien de la vérification de cohérence des options, donc un serveur fonctionnant avec disable-occ ne l’a jamais eue. Notez sur quoi repose la comparaison : du texte décrivant la configuration d’un pair. Elle ne dit rien sur le chiffrement que le canal de données utilisera.
C’est la première raison pour laquelle l’indicateur ne peut pas réparer une erreur de chiffrement. Le choix du chiffrement est régi par la politique data-ciphers et par ce que les deux pairs prennent en charge, et une vérification textuelle de cohérence n’étend pas cette liste et n’effectue pas la négociation. La seconde raison est la portée : la vérification porte sur la compatibilité apparente des options déclarées, pas sur la qualité du chemin qui en résulte.
Ce que fait la 2.7 quand elle voit la ligne
En 2.7, l’option a disparu. L’analyseur reconnaît encore le nom, ce qui explique qu’un ancien profil se charge sans erreur de syntaxe, et il signale que l’option a été supprimée au lieu de la passer sous silence. Reconnaître un nom et imposer un comportement sont deux choses différentes, et seule la première se produit encore. Les notes de suppression en donnent la raison : une fois les paramètres négociables, deux pairs peuvent légitimement avoir des chaînes d’options différentes tout en s’accordant sur la connexion.
Un profil qui se parse n’est donc pas la preuve qu’une vérification d’admission a eu lieu. Si votre seul signal est que le client s’est connecté, vous avez appris que la syntaxe a été acceptée.
Où se situe réellement la défaillance
Conservez la première erreur concrète avant de changer quoi que ce soit, car les messages suivants en sont généralement les conséquences. Un échec de négociation du canal de données relève de la politique de chiffrement approuvée et des capacités que les deux pairs annoncent réellement. Un échec de version ou de suite TLS relève du canal de contrôle. Un rejet de certificat exige l’identité et la chaîne de confiance, pas un indicateur de compatibilité.
Identifiez aussi le moteur aux deux extrémités. Une application de bureau peut embarquer une compilation différente du binaire en ligne de commande avec lequel vous avez testé, et la prise en charge des options diffère entre eux. Consultez la documentation de ce moteur au lieu de supposer que tout programme important un profil se comporte de la même manière.
Remplacez l’intention, pas seulement la ligne
Si un serveur géré plus ancien s’appuyait réellement sur la vérification de cohérence, notez quelle contrainte il imposait avant la mise à niveau. Conserver une option ignorée dans un profil plus récent ne peut pas préserver cette politique, et supprimer des lignes sans discernement non plus.
Ne répondez pas à une ancienne suggestion selon laquelle tous les chiffrements sont désactivés en activant tous les algorithmes historiques.
Après une correction approuvée, examinez les résultats négociés sur une nouvelle connexion et testez l’application dont l’utilisateur a réellement besoin. Gardez la version du serveur et la politique effective à côté de ce résultat, afin que la personne suivante voie ce qui a été convenu plutôt que ce qui a simplement été accepté.
L’objectif est une contrainte prise en charge et un chemin authentifié qui fonctionne, pas un indicateur hérité qui se parse encore.