Le profil se télécharge, s'importe puis s'arrête à la ligne 12 du fichier avec un message Unrecognized option qui nomme keysize. Rien n'a changé du côté du compte, et le serveur accepte toujours d'autres clients. Ce qui a changé, c'est le client lui-même : Ubuntu 24.04 installe OpenVPN 2.6, alors que l'export a été écrit pour la 2.4. La réparation est une courte série de suppressions, et l'ordre compte car chaque option obsolète interrompt l'analyse avant même que la suivante ne soit lue.

Lisez la ligne d'erreur avant de toucher au fichier

OpenVPN nomme le fichier et la ligne où l'analyse s'est arrêtée, donc vous ne corrigez qu'un problème par exécution. Lancez le profil depuis un terminal plutôt que depuis un applet de bureau, car l'applet avale généralement stderr et le numéro de ligne est le seul repère fiable que vous obtenez : sudo openvpn --config /etc/openvpn/client/provider.ovpn. Corrigez cette ligne, relancez, et attendez-vous à ce que l'échec suivant nomme une autre option.

Une erreur d'analyse apparaît toujours avant toute poignée de main TLS, donc un message qui mentionne un certificat a déjà franchi l'étape de la syntaxe. Cette distinction vous évite de modifier un fichier qui n'échoue qu'à l'authentification. Lisez le premier mot du message plutôt que son milieu.

Trois classes d'échec, trois réparations différentes

Les anciens exports échouent de trois manières distinctes, et c'est justement les fondre en un seul problème qui pousse les gens à réinstaller des paquets qui n'ont jamais été cassés. La formulation du message vous dit dans quelle classe vous êtes avant que vous n'ouvriez le fichier.

  • Les erreurs d'analyse nomment un fichier et une ligne, et s'arrêtent avant qu'aucun trafic n'existe.
  • Les erreurs de négociation se connectent, puis signalent que les deux extrémités n'ont pas pu s'accorder sur un chiffrement commun ou un canal de données acceptable.
  • Les erreurs d'authentification vont le plus loin et nomment un certificat, un utilisateur ou un identifiant rejeté.

Modifier le profil ne corrige que la première classe. La négociation exige une décision aux deux extrémités du tunnel, et un identifiant rejeté n'est pas du tout un problème de syntaxe. Si votre message mentionne un chiffrement commun ou un canal de données, les suppressions ci-dessous ne changeront rien.

Supprimez les options que la 2.6 a retirées, dans cet ordre

Chacune de ces lignes arrête l'analyse à elle seule, donc le client les signale une par une. Descendez la liste et relancez après chaque suppression.

Supprimez d'abord keysize, car il n'a pas d'équivalent moderne et sa présence signale généralement un chiffrement que le client actuel refuse de toute façon. Supprimez ensuite ncp-disable, qui contrôlait la négociation des chiffrements, est devenu obsolète en 2.5 et a disparu en 2.6. Remplacez ns-cert-type server par remote-cert-tls server, qui exprime la même intention via une vérification prise en charge. L'historique des changements 2.6 liste les retraits restants à côté de leurs remplacements, donc tout ce que l'analyseur rejette encore a une réponse documentée.

Gardez une copie du profil d'origine avant la première modification. Les fournisseurs régénèrent les exports, et un diff avec le fichier intact est le moyen le plus rapide de séparer vos modifications des leurs. Si une suppression laisse le client démarrer mais que le tunnel échoue encore, vous êtes passé dans la classe de la négociation et les lignes restantes ne sont pas la cause. Mettez la version du client dans le nom du fichier pour que la personne suivante sache quelle version les modifications visent.

Ne gardez BF-CBC qu'en secours limité

Certains fournisseurs terminent encore sur BF-CBC, que la 2.6 d'OpenVPN ne négociera pas sans aide car le chiffrement a un bloc de 64 bits. La réparation étroite est une liste de secours plus l'ancien fournisseur OpenSSL, pas une rétrogradation de tout le client.

providers legacy default
data-ciphers AES-256-GCM:AES-128-GCM
data-ciphers-fallback BF-CBC

La première ligne charge l'ancien fournisseur pour qu'OpenSSL puisse encore instancier ce chiffrement, la deuxième conserve la négociation moderne pour les pairs qui la prennent en charge, et la troisième ne s'applique que lorsque le serveur n'offre rien de mieux. C'est un affaiblissement délibéré du tunnel, alors notez pourquoi il existe à côté du fichier. Demandez au fournisseur un export régénéré en même temps, car le secours est un pont et non une destination.

Ne vous rabattez pas sur --compat-mode comme réponse universelle. Il change plusieurs comportements à la fois, dont les valeurs par défaut de négociation et de renégociation, si bien que vous n'apprenez jamais quel changement comptait. Préférez les trois lignes explicites ci-dessus, car chacune énonce son propre effet.

Vérifiez avec le profil que le client charge réellement

Les connexions importées sont souvent copiées dans un répertoire système, donc modifier le fichier de votre dossier de téléchargements peut ne rien changer du tout. Trouvez la copie qui s'exécute : sudo grep -rl "remote " /etc/NetworkManager/system-connections /etc/openvpn. Lancez ensuite le tunnel et lisez la ligne de journal qui indique quel chiffrement de canal de données a réellement été choisi. Une connexion qui termine la poignée de main sur le secours vous dit que le serveur n'a jamais proposé quelque chose de moderne.

Testez depuis un réseau qui n'est pas celui attendu par le fournisseur, pour qu'un portail captif ou un réseau invité filtré ne se déguise pas en panne de profil. Notez la version du client à côté de toute demande d'assistance.

Une fois le tunnel monté, envoyez une requête qui doit le traverser et une qui ne doit pas, puis confirmez que la réponse du résolveur a changé comme prévu. Si le profil s'analyse désormais mais que la connexion échoue encore, vous avez laissé le problème de syntaxe derrière vous et le texte d'erreur nommera la nouvelle classe. Gardez le fichier modifié sous contrôle de version à côté d'une note nommant la version d'OpenVPN visée.

Articles similaires