Erreur OpenVPN : option tls-remote ou keysize non reconnue

Tout commence souvent par un profil qui se connectait depuis des années, ouvert dans un client plus récent, et qui échoue avant même que le tunnel ne démarre. Le terminal affiche quelque chose comme Options error: Unrecognized option ... in client.ovpn:130: tls-remote, avec une version entre parenthèses à la fin. Lisez-le comme une plainte de l’analyseur : le fichier contient une directive que ce client ne connaît plus.

Ce seul message explique pourquoi régénérer les clés, retaper le mot de passe ou vérifier le serveur ne sert à rien. L’échec se produit pendant que le client lit sa propre configuration, avant d’ouvrir une socket. Le travail utile consiste à identifier la directive rejetée et à la remplacer par l’équivalent actuel.

Lisez la ligne fautive avant de modifier quoi que ce soit

Lancez le client vous-même au lieu de le démarrer depuis une icône de la zone de notification, afin que le message soit visible et le chemin du profil sans ambiguïté. Ouvrez le fichier à la ligne indiquée et regardez le jeton que le client a nommé. Le numéro de ligne est celui du profil, pas une version, ce qui trompe les gens parce que le même nombre apparaît entre parenthèses comme identifiant de version.

Les anciens générateurs de profils n’émettaient pas une seule mauvaise directive, mais plusieurs. Corrigez la première erreur, relancez le client et attendez l’apparition de la suivante. Cette séquence est normale et n’indique pas que les modifications ont empiré les choses.

Ce qui est arrivé à keysize et tls-remote

keysize demandait une longueur de clé de chiffrement à l’époque où le profil choisissait le chiffrement explicitement. OpenVPN 2.4 l’a déclaré obsolète, et les clients ultérieurs l’ont retiré de la table des options, si bien que l’analyseur rejette désormais la ligne au lieu de l’ignorer. La négociation moderne déduit la longueur de clé du chiffrement sélectionné, et c’est pourquoi il ne reste rien à contrôler pour la directive.

tls-remote a été supprimé dans la 2.4. Il comparait le certificat du serveur à un nom attendu, et son remplaçant est verify-x509-name, qui est plus strict sur la façon dont le nom est mis en correspondance. L’ancienne directive a disparu, donc un profil qui la porte ne s’analysera jamais sur un client actuel.

Corrigez une directive par tentative. Si le profil précise aussi un chiffrement que le client ne propose pas, cela produit une autre erreur plus tard, et mélanger les deux changements dans une seule modification empêche de savoir lequel a cassé la poignée de main. Reconnectez-vous après chaque modification et conservez le texte de l’erreur. Cette habitude laisse aussi une solution de repli fonctionnelle si une modification aggrave les choses.

Réécrivez la vérification de l’identité du serveur

Le remplaçant prend le nom attendu et un mode de comparaison. verify-x509-name vpn.example.edu name exige que le sujet du certificat soit exactement égal à cette valeur. Les autres modes font correspondre un préfixe ou une chaîne de sujet complète, et choisir le mauvais mode transforme un profil fonctionnel en échec de vérification net.

Si l’ancien argument tls-remote était le nom commun complet du serveur, une comparaison exacte name est généralement correcte. S’il s’agissait d’une valeur partielle, utilisez le mode préfixe plutôt que de raccourcir le nom attendu, car une correspondance exacte plus courte ne vérifiera pas. Quand la valeur d’origine n’est pas consignée, demandez à l’exploitant du serveur le sujet qu’il publie.

Ne rendez pas la vérification muette pour faire disparaître l’erreur. Supprimer la vérification de l’identité du serveur transforme un problème de profil réparable en tunnel non vérifié, ce qui est exactement le risque que la directive existait pour éviter.

Profil corrigé, modification locale ou client plus ancien

Quand le serveur appartient à quelqu’un d’autre, la voie la plus propre est un profil actuel venant de cette personne. Votre copie vient d’un générateur plus ancien, et son export utilise déjà les directives actuelles. Un seul téléchargement élimine toute la catégorie d’erreurs et garde les modifications futures au même endroit.

Quand vous possédez les deux extrémités, modifiez une copie et gardez l’original. Changez une directive, enregistrez, connectez-vous et notez la version du client testée. Gardez une courte note à côté de chaque modification, car un profil modifié sur plusieurs sessions est difficile à auditer de mémoire. Les exécutions en ligne de commande sur le fichier modifié rendent cette boucle rapide, car l’erreur va directement au terminal.

Épingler ou revenir à un client antérieur à la 2.4 fait aussi disparaître le message, et avec un appareil qui ne sera jamais mis à jour, ce peut être le seul palliatif viable. Traitez-le comme temporaire : un vieux client sur un poste actuel signifie généralement une vieille bibliothèque et une configuration non prise en charge, ce qui est un problème reporté plutôt que résolu.

Une fois le tunnel monté, relisez tout le profil. Les profils qui portaient une directive supprimée en portent souvent une autre, et la seconde ne se révèle qu’après la disparition de la première.