NM OpenVPN : le profil enregistré n’est pas votre fichier .ovpn

Le même .ovpn fichier se connecte depuis un shell et expire après son importation dans NetworkManager. La conclusion naturelle est que le VPN est cassé. L’explication la plus probable est plus petite : NetworkManager n’a pas conservé le fichier, il en a importé une partie dans une connexion enregistrée, et le tunnel en cours utilise à la place ces données enregistrées. Ce que le fichier dit maintenant n’a aucune importance pour ce que contient le profil.

Le fichier n’est pas le profil

L’importation est une traduction, pas un montage. Les options que le greffon comprend deviennent des clés du vpn.data dictionnaire de la connexion ; les options qu’il ne comprend pas sont abandonnées ou consignées ailleurs, et le chemin d’origine n’est qu’une référence. Modifier le fichier source ensuite ne change rien à la connexion déjà enregistrée.

Cet écart explique toute une famille de rapports : la clé partagée a été renouvelée, le fichier a été mis à jour, et le tunnel échoue toujours. Le profil enregistré pointe encore vers l’ancien chemin ou l’ancienne valeur, et la ligne de commande continue de fonctionner parce qu’elle lit le fichier que vous avez modifié. Deux clients, deux sources de vérité, et une seule a été mise à jour.

Lisez le profil enregistré, pas la boîte de dialogue

nmcli -f connection.id,connection.uuid,vpn.service-type,vpn.data connection show office-vpn

Utilisez l’UUID lorsque deux profils partagent un nom, et confirmez que le type de service est bien le OpenVPN greffon attendu, et non un autre type de VPN qui se trouve être installé. Comparez ensuite le point de terminaison, le transport et les références de certificat avec l’invocation qui fonctionne.

Une valeur visible dans un éditeur graphique ne prouve pas qu’elle a été persistée. Enregistrez, rouvrez et relisez-la via la ligne de commande ; des défauts d’enregistrement historiques sont une raison de vérifier les données stockées, pas la preuve que chaque version actuelle a le même bogue. La vérification coûte une commande.

Deux clés, et une direction qui compte

Pour une connexion utilisant l’authentification TLS, le greffon stocke le chemin de la clé partagée dans ta et la direction dans ta-dir, lorsque le déploiement en utilise une. Les deux vivent dans le dictionnaire de données du profil, et les deux doivent correspondre à ce que le serveur attend.

La direction est une décision côté serveur exprimée sur le client. En choisir une parce qu’un profil voisin la possède est la façon dont une clé qui fonctionne finit par échouer une poignée de main. Si la configuration du serveur est sans direction, le client ne devrait pas inventer de direction.

Le fichier de clé lui-même doit être lisible par le greffon dans le contexte où il s’exécute réellement. Un paquet confiné a une vue du système de fichiers différente de celle d’une installation de bureau ordinaire, donc un chemin qui existe dans votre shell peut être invisible pour le service.

Mettez à jour une entrée, pas le dictionnaire

nmcli connection modify office-vpn +vpn.data 'ta=/etc/NetworkManager/certs/office-ta.key'
nmcli connection modify office-vpn +vpn.data 'ta-dir=1'

Le plus initial met à jour des entrées individuelles du dictionnaire. Attribuer vpn.data sans lui remplace tout le dictionnaire, et c’est ainsi qu’une clé manquante devient cinq réglages cassés. Relisez le profil après la modification et confirmez que les autres entrées ont survécu. Un dictionnaire qui a perdu son point de terminaison distant et ses certificats est un après-midi bien plus long que celui que vous avez commencé.

Reconnectez-vous via les contrôles habituels et observez l’étape qui échoue. Si la porte de la clé partagée passe maintenant et que le client signale une erreur de certificat ou d’authentification utilisateur, vous avez progressé et la prochaine investigation est différente.

Ne confondez pas les modes du canal de contrôle

tls-auth, tls-crypt, et tls-crypt-v2 sont des dispositions différentes. Un fichier de clé qui se ressemble ne les rend pas interchangeables, et remplir les champs TLS-Auth parce qu’un autre profil contient une clé formatée produit un profil qui échoue d’une manière ressemblant à une mauvaise clé.

Utilisez le mappage du greffon qui correspond au mode dans la configuration du serveur. Lorsque le mode n’est pas clair, demandez au propriétaire du serveur plutôt que de deviner à partir de la première ligne du fichier.

Gardez un chemin de récupération lorsque le tunnel transporte votre session d’administration. Un changement enregistré n’est pas nécessairement un changement appliqué, et une importation réussie ne prouve pas que chaque option source était prise en charge. Les deux écarts valent la peine d’être connus avant de reconnecter le lien par lequel vous travaillez.