Pourquoi OpenVPN a-t-il cessé de se connecter après une mise à niveau d'Ubuntu ?

Les profils VPN qui fonctionnaient la semaine dernière cassent après une mise à niveau de version d'Ubuntu, et le journal mentionne rarement la mise à niveau. Ce qu'il nomme, c'est la couche qui a échoué : la poignée de main TLS, le chiffrement négocié pour le canal de données, le paquet installé, ou la copie d'OpenSSL que le binaire charge au démarrage. Chaque couche a sa forme d'erreur et sa réparation, ce qui fait du classement le premier travail et de l'édition le second. Tenez le profil pour innocent jusqu'à ce que le journal le nomme.

Quelle couche a échoué : poignée de main, chiffrement, paquet ou bibliothèque

Lisez le journal du client avant de toucher au profil. la première erreur de la sortie est celle qui identifie la couche ; tout ce qui s'imprime ensuite découle généralement de cette première panne. Quand le client ne démarre pas du tout, le journal VPN est le mauvais fichier à ouvrir.

Les plaintes sur les certificats et les signatures, ou un message sur la longueur de clé, viennent du canal de contrôle et de la politique de bibliothèque qui le régit. Un avertissement qui commence par DEPRECATED OPTION relève plutôt de la négociation du canal de données.

Une ligne du type Unrecognized option est une troisième catégorie : le nouveau binaire n'accepte plus une directive que l'ancien tolérait, il faut donc réécrire le profil et non assouplir la bibliothèque. Les échecs d'empaquetage ont encore une autre allure, car ils surviennent avant l'exécution du moindre code de tunnel. Un binaire absent, un greffon qui ne se charge pas ou un dépôt pointant vers un nom de code erroné produisent tous cette forme. Quatre symptômes, quatre endroits où regarder, et presque aucun recouvrement entre les réparations.

Quand la poignée de main échoue, la politique TLS rejette le certificat

Ubuntu 22.04 a fait passer le système à OpenSSL 3, et le niveau de sécurité par défaut de cette branche est plus strict sur les signatures de certificats et les tailles de clés que ne l'était 20.04. Un certificat CA signé avec un condensat plus ancien, ou une clé sous le seuil actuel, échoue désormais pendant la poignée de main. Comme rien n'est encore authentifié, l'erreur se lit comme un mot de passe erroné ou un serveur mort.

La réparation étroite attache une chaîne de chiffrement à cette seule connexion. Dans l'éditeur de bureau, ouvrez le profil, passez aux paramètres avancés et mettez DEFAULT:@SECLEVEL=0 dans le champ de chiffrement TLS. Le fichier de clés de NetworkManager prend la même valeur sous [vpn]:

[vpn]
tls-cipher=DEFAULT:@SECLEVEL=0

Redémarrez NetworkManager et reconnectez-vous, car le démon met en cache les profils analysés et continuerait sinon d'utiliser la copie qu'il détient déjà. Sachez ce que fait la ligne avant de la garder : ce réglage est un seuil portant sur plusieurs paramètres de certificats et de clés, non un nom de chiffrement ; l'abaisser élargit donc ce que le profil accepte. Notez quel serveur l'a exigé et retirez le réglage dès que l'exploitant réémet du matériel à jour. Modifier /etc/ssl/openssl.cnf atteint le même seuil pour tout programme qui lit ce fichier, bien au-delà du VPN.

OpenVPN 2.6 exige le chiffrement listé pour la négociation

Ubuntu 22.10 a livré OpenVPN 2.6, et dans cette version --cipher cesse de choisir seul le canal de données. Le chiffrement doit aussi figurer dans la liste data-ciphers négociée, sinon le client imprime un avertissement d'obsolescence puis échoue à monter le tunnel.

Le greffon NetworkManager de la même époque n'écrivait encore que l'ancienne directive. Ce détail scinde le diagnostic, car un profil corrigé à la main peut se connecter depuis un shell et continuer d'échouer depuis l'applet de bureau. Ajoutez la liste au fichier de connexion sous [vpn]:

data-ciphers=AES-256-CBC

Utilisez la valeur annoncée par le serveur, pas celle dont vous vous souvenez ; un serveur qui propose AES-256-GCM ne négociera pas avec une liste de client nommant seulement CBC. Redémarrez le gestionnaire et reconnectez-vous, puis répétez l'essai depuis un shell avec le chiffrement passé explicitement pour la négociation et le repli :

sudo openvpn --config client.ovpn --data-ciphers AES-256-CBC --data-ciphers-fallback AES-256-CBC

Si cette commande monte le tunnel, le serveur, les certificats et les identifiants sont tous sains, et la seule panne restante est l'option enregistrée du gestionnaire. Un avertissement sur la directive keysize relève du même nettoyage : commentez-la et gardez le fichier d'origine à côté du profil.

Les pannes de paquets et de greffons ressemblent aux pannes VPN

Tout échec après la mise à niveau n'est pas cryptographique. Un dépôt OpenVPN ajouté sous un nom de code que la version n'utilise pas produit un paquet qui ne s'installe jamais ; comparez donc ce que lsb_release -a rapporte avec le fichier de liste que vous avez ajouté. Un composant universe manquant ou une poche de sécurité produit un paquet introuvable. Les deux cas laissent le profil intact et le tunnel impossible.

Lisez l'erreur du gestionnaire de paquets avant le journal VPN. Si le client n'a jamais été installé, aucune édition du profil ne produira de poignée de main.

Les profils à deux facteurs qui cessent de demander sont la version greffon de la même histoire. Le défi vient d'un greffon d'authentification, et une mise à niveau qui l'a supprimé ou remplacé laisse le profil intact tandis que l'invite disparaît. Réinstallez le greffon pris en charge au lieu de supprimer le second facteur pour faire fonctionner la connexion.

Une bibliothèque de fournisseur peut se cacher derrière une erreur de politique

Un motif mérite d'être reconnu car il défait toute réparation de politique. Un outil de configuration d'un fournisseur matériel peut installer ses propres bibliothèques OpenSSL et les placer avant les copies du système dans le chemin de recherche du chargeur. Le client démarre alors contre une bibliothèque que personne n'a mise à jour, et l'échec de démarrage ressemble exactement à un certificat rejeté.

Réinstaller le paquet VPN ne change pas quelle bibliothèque est trouvée en premier, et abaisser le niveau TLS n'atteint pas une bibliothèque qui ne vient jamais du système. Demandez au chargeur quels objets cryptographiques le binaire résout réellement :

ldd /usr/sbin/openvpn | grep -i -E 'ssl|crypto'

Supprimez ou repointez la copie du fournisseur, puis relancez la même vérification. La version attendue doit être celle en usage avant de revenir au profil.

Épingler un client plus ancien achète du temps, pas une solution

Retenir la version précédente du client restaure le tunnel tant que la rétention dure. Cela gèle aussi les mises à jour de sécurité de ce paquet et programme la même casse pour la prochaine mise à niveau ; traitez donc cela comme un contournement daté, non comme une résolution.

Si vous l'épinglez quand même, retenez le paquet explicitement pour qu'une mise à niveau non surveillée ne puisse pas défaire l'épingle, notez la raison et la date de réexamen, et posez un rappel pour la prochaine version de profil du fournisseur. La condition à surveiller est un profil de serveur négociant un chiffrement actuel ; dès qu'il existe, l'épingle n'a plus de justification. Une épingle non consignée, en revanche, devient une panne que personne ne peut expliquer six mois plus tard, car la personne qui l'a appliquée est partie et le fichier n'enregistre rien.

La prochaine fois qu'un VPN meurt après une mise à niveau de version, posez cinq questions dans l'ordre : quelle couche a produit la première erreur, la politique TLS a-t-elle rejeté le certificat, le chiffrement est-il négociable dans les deux sens, le paquet et son greffon se sont-ils réellement installés, et quelle bibliothèque le processus charge-t-il. Ce n'est qu'une fois les cinq réponses propres qu'une rétrogradation a du sens.