OpenVPN signale ncp-disable comme inconnu : qu'est-ce qui l'a remplacé ?

Le client refuse de démarrer avec une erreur d'options qui nomme ncp-disable, alors que le profil fonctionnait sur la machine précédente. Ce message ne veut pas dire que l'option est mal orthographiée ni que le chiffrement est cassé. Il veut dire que le binaire devant vous ne connaît pas du tout la directive, et il y a deux raisons très différentes à cela. Laquelle s'applique décide si vous modifiez le profil ou si vous changez de client.

L'erreur peut venir d'un binaire plus récent

Une erreur d'option non reconnue concerne l'analyseur, pas le tunnel. OpenVPN 2.4 a ajouté des paramètres de chiffrement négociables, la 2.5 a déclaré obsolète l'interrupteur qui les désactivait, et la 2.6 l'a supprimé entièrement. Un profil écrit pour la 2.3 ou la 2.4 échoue donc sur un client actuel, même si rien dans le fichier n'a changé. La version qui se plaint est plus récente, pas plus ancienne.

Déterminez quel exécutable a produit le message avant de modifier quoi que ce soit. Un client de bureau embarque son propre moteur, tandis qu'un binaire en ligne de commande installé séparément a sa propre version. Les deux peuvent ne pas s'accorder sur la même machine.

openvpn --version règle la question pour le binaire que vous testez. Un client avec interface graphique n'expose peut-être pas cette commande ; dans ce cas, lisez son écran À propos ou la version de la bibliothèque embarquée.

Ce que l'option contrôlait réellement

La directive désactivait la négociation des paramètres cryptographiques, de sorte que les deux extrémités retombaient sur un comportement de sélection plus ancien, piloté par le réglage cipher. Elle n'a jamais désactivé le chiffrement et n'a jamais transformé le tunnel en texte clair. La lire comme un interrupteur de sécurité est le premier faux pas, et cela conduit à des changements qui dégradent la connexion au lieu de l'améliorer.

Une fois la négociation en place, la question équivalente est de savoir quels chiffrements chaque côté accepte d'utiliser. C'est une question de politique, et la politique vit dans data-ciphers à partir de la 2.5.

L'ancien nom ncp-ciphers appartient à la 2.4. Mélanger les deux noms entre pairs est une source fréquente d'échecs de négociation à sens unique. Un profil qui porte les deux est un profil modifié par deux personnes à des moments différents.

Remplacez la politique, pas l'orthographe

Définissez data-ciphers des deux côtés avec un choix partagé voulu et gardez la liste assez courte pour qu'un relecteur puisse raisonner dessus. Changer une ligne arbitraire ne prouve rien ; le résultat dépend de l'intersection des deux listes et de ce que la pile TLS prend en charge. Confirmez l'accord des pairs en lisant le résultat négocié plutôt que la configuration. Puis inscrivez les deux listes dans le registre de déploiement pour que le changement suivant parte d'un état connu.

Mettez le profil à jour par l'intermédiaire de son propriétaire. Ajouter une option d'ignorance pour masquer une directive obsolète laisse la question de politique sans réponse.

Si un pair plus ancien a réellement besoin d'un traitement de compatibilité, limitez-le à ce déploiement. Rétablir globalement un comportement obsolète n'est pas un prérequis pour connecter des pairs modernes. L'exception devrait nommer le pair pour lequel elle existe.

Deux lignes qui ressemblent à une liste de chiffrements sans en être une

Empiler deux lignes de chiffrement ne rétablit pas non plus la négociation, et le résultat est un profil qui ressemble à une liste tout en se comportant comme une valeur unique. Une ligne avec AES-256-CBC et la suivante avec CBC est une tentative courante. CBC seul nomme un mode, pas un algorithme, donc un analyseur peut l'accepter à un endroit et le rejeter au suivant. Les directives cipher répétées fixent la même option deux fois au lieu d'accumuler des candidats.

Vérifiez les noms acceptés avec openvpn --show-ciphers sur le binaire cible au lieu de copier une liste depuis un guide écrit pour une autre branche. La liste change d'une version à l'autre. Un nom valide dans une branche n'est pas forcément valide dans l'autre.

Si l'objectif était une comparaison de performances, consignez les algorithmes et la charge de travail. Passer à CBC n'est pas une mesure de l'absence de chiffrement.

Vérifiez ce que la connexion a réellement négocié

Établissez une nouvelle connexion et lisez la ligne du canal de données dans le journal, qui nomme le chiffrement utilisé. La suite du canal de contrôle est décidée séparément, donc la liste autorisée dans le fichier ne montre que ce qui a été proposé. Quand les deux pairs ont choisi quelque chose que vous n'attendiez pas, ce sont les listes qu'il faut regarder, pas l'interface du tunnel. Confirmez le résultat sur une seconde connexion après tout changement, car un redémarrage peut réutiliser une session mise en cache.

Conservez le résultat négocié dans le registre de déploiement à côté de la version du profil. C'est le fait qui répond à la question suivante : quel chiffrement protège réellement le trafic.