L'import dans NetworkManager échoue avec les fichiers OpenVPN et WireGuard

J'ai choisi Importer depuis un fichier… dans les Paramètres de GNOME, j'ai choisi un profil qui fonctionne avec le client du fournisseur, et la boîte de dialogue s'est fermée sans rien ajouter à la liste. Sur un second portable, l'import s'est terminé, la connexion est apparue sous le nom du profil, puis elle a échoué à la première demande d'authentification. NetworkManager n'exécute jamais votre fichier .ovpn ou wg-quick tel quel. Il confie le fichier à un analyseur, l'analyseur le convertit au format de connexion propre à NetworkManager, et à partir de là le tunnel est construit à partir de cet objet analysé : secrets, routes, DNS et tout le reste. La bonne question n'est donc pas pourquoi le fichier est cassé, mais si l'analyse a eu lieu et ce qu'elle a conservé.

Ce que l'import fait réellement du fichier

Pour OpenVPN, l'analyseur vit dans le paquet du greffon, et la connexion qu'il crée pointe vers un service D-Bus tel que org.freedesktop.NetworkManager.openvpn. Pas de greffon, pas d'analyseur : le type est inconnu de nmcli, et la liste graphique d'ajout de VPN peut ne montrer aucune entrée d'import. WireGuard diffère sur un point important : NetworkManager possède ses propres réglages WireGuard depuis la série 1.30, il n'y a donc pas de paquet de greffon séparé, mais le lecteur wg-quick n'existe que dans les versions qui l'incluent.

Dans tous les cas, le fichier n'est lu qu'une fois. Le résultat est écrit sous forme de keyfile dans /etc/NetworkManager/system-connections/, nommé d'après la connexion, possédé par root et illisible par les autres utilisateurs parce qu'il contient le matériel de clé. Ce keyfile est désormais la connexion ; modifier ensuite le .ovpn d'origine ne change rien.

Trois symptômes relèvent de trois étapes différentes. Pas d'entrée d'import ou un type inconnu signifie que le greffon ou la version manque. Une erreur d'import qui nomme une directive signifie que l'analyseur a lu le fichier et en a rejeté une partie. Une connexion qui existe mais ne s'active jamais signifie que l'objet analysé est incomplet ou que le serveur la refuse. Déterminez lequel vous avez avant de modifier quoi que ce soit.

Confirmez le greffon avant de déboguer le profil

Un greffon manquant ressemble exactement à un profil corrompu, alors vérifiez d'abord le paquet. Sous Debian et Ubuntu, la prise en charge d'OpenVPN est fournie par network-manager-openvpn plus un assistant de bureau ; sous Fedora, les paquets sont NetworkManager-openvpn et NetworkManager-openvpn-gnome ; sous Arch, c'est networkmanager-openvpn.

dpkg -l network-manager-openvpn-gnome | tail -n 2
rpm -q NetworkManager-openvpn
pacman -Q networkmanager-openvpn

Importez ensuite depuis un chemin absolu : nmcli connection import type openvpn file /home/you/profile.ovpn. Les chemins relatifs fonctionnent généralement, mais un shell qui a changé de répertoire transforme un import rapide en détour. Pour WireGuard, vérifiez nmcli --version et assurez-vous que le côté noyau existe avec modprobe wireguard ; un import qui réussit sur une machine sans le module vous laisse avec une connexion dont l'interface n'apparaît jamais. La référence nmcli documente la sous-commande import et les noms de type acceptés. Si type wireguard est rejeté d'emblée, la version est antérieure à la fonction, et le bon geste est un paquet de la distribution ou un backport — pas de copier la configuration dans un répertoire arbitraire en espérant que quelque chose la lise.

Lisez la connexion OpenVPN, pas le .ovpn

Une fois la connexion créée, lisez les réglages analysés au lieu de relire le fichier : nmcli connection show "Work VPN" | grep -E '^vpn\.'. Vous voulez le remote et le port, le transport, le matériel d'identité — ca, cert, key, tls-auth ou tls-crypt — et la méthode d'authentification. Sur un profil avec mot de passe de clé privée, ajoutez sudo nmcli --show-secrets connection show "Work VPN" et regardez les secret flags : 0 vaut none, donc le secret est dans le keyfile ; 1 vaut agent-owned ; 2 vaut not-saved, ce qui signifie qu'il n'est jamais écrit dans le keyfile ; 4 vaut not-required, ce qui signifie qu'aucun secret n'est nécessaire. Ce sont des bits, pas une échelle, donc 3 vaut simplement agent-owned plus not-saved. Un secret qui vous demande une fois par session est agent-owned (1), l'agent le demandant ; il n'existe pas de numéro de flag distinct pour cela. Un décalage de flags est la raison habituelle pour laquelle un profil se connecte depuis l'applet du bureau et échoue depuis un script ou au démarrage.

Le moyen le plus rapide de voir ce que l'analyseur a abandonné est de demander au greffon de réécrire le fichier, puis de le comparer : nmcli connection export "Work VPN" /tmp/roundtrip.ovpn. Les directives qui disparaissent dans ce diff n'existeront pas au moment de la connexion. Les hooks sont les suspects habituels — script-security, up, down et route-up attendent un script exécuté avec des privilèges élevés et ne sont délibérément pas repris. N'abaissez pas la vérification et n'accordez pas de privilèges supplémentaires pour faire réussir un import ; une option non prise en charge reflète généralement l'ensemble des fonctions du greffon plutôt qu'un serveur injoignable. Déplacez ce comportement dans un script dispatcher de NetworkManager ou dans une politique côté serveur.

Vérifiez aussi que les champs d'identité ont survécu : la référence CA, remote-cert-tls et tout contrôle de nom sur lequel le profil comptait. Une connexion qui monte sans eux parle peut-être à ce qui répond sur cette adresse.

Lisez la connexion WireGuard, pas le fichier wg-quick

Un fichier wg-quick est un format à sémantique de shell ; la connexion importée est un ensemble de réglages. PrivateKey devient la clé privée de l'interface, Address devient une ou plusieurs adresses IPv4 et IPv6, DNS correspond aux propriétés de résolveur de NetworkManager, MTU correspond à wireguard.mtu (la valeur par défaut de wg-quick est 1420), et chaque bloc peer devient une entrée peer avec clé publique, endpoint, IP autorisées et keepalive persistant. Affichez ce qui a été stocké avec nmcli --show-secrets connection show wg0 ; si la liste des peers n'apparaît pas dans cette sortie, lisez le keyfile :

sudo sed -n '/^\[wireguard\]/,/^\[/p' /etc/NetworkManager/system-connections/wg0.nmconnection

Ce qui ne survit pas, c'est la moitié shell de wg-quick. PreUp, PostUp, PreDown, PostDown et Table relèvent du comportement de cet outil, pas d'attributs d'une interface WireGuard, donc rien ne les exécute après un import. Si l'original utilisait Table = off pour laisser la route par défaut tranquille, les versions récentes de NetworkManager exposent ip4-auto-default-route et ip6-auto-default-route dans le même but ; définissez-les explicitement au lieu de supposer que la connexion se comporte comme le script. Un hook qui poussait une route personnalisée a besoin de cette route dans les réglages de routage de la connexion, sinon elle manquera tout simplement.

Donnez à la connexion exactement un propriétaire

La panne classique qui suit est une connexion qui fonctionne jusqu'au prochain démarrage puis boucle. Souvent [email protected] était encore activé depuis une expérience précédente, ou un client du fournisseur lançait son propre démon, et deux propriétaires écrivaient des routes et du DNS pour la même destination. NetworkManager définit le résolveur par son propre chemin, wg-quick écrit via resolvconf, et le dernier écrivain gagne — la résolution de noms fonctionne, puis s'arrête, puis refonctionne. Vérifiez systemctl status wg-quick@wg0, nmcli connection show --active et ip link show type wireguard, puis désactivez le second propriétaire au lieu d'ajuster sa métrique.

Si vous avez vraiment besoin des deux, donnez-leur des interfaces distinctes et des IP autorisées disjointes, et laissez exactement l'un d'eux installer la route par défaut. Deux routes par défaut avec des métriques différentes ne sont pas un split tunnel ; c'est une course arbitrée par le service qui démarre en second. Et après une reconnexion, inspectez à nouveau l'état appliqué — une modification manuelle ponctuelle du résolveur qui fait fonctionner les choses ne prouve pas que l'import est complet.

Vérifiez avec du trafic et survivez à un redémarrage

Montez la connexion avec nmcli connection up "Work VPN", puis lisez l'état, l'adresse et les routes au lieu de faire confiance à l'icône : nmcli device show wg0 | grep -E 'GENERAL.STATE|IP4.ADDRESS|IP4.ROUTE', ip route show default, et une vraie résolution d'un nom qui ne se résout qu'à l'intérieur du tunnel. Un handshake ou un ping réussi prouve seulement que la cryptographie fonctionne ; il ne dit rien du forwarding, des préfixes de split tunnel ou du DNS privé, qui sont les parties qui cassent d'habitude.

Redémarrez ensuite et répétez. Le comportement d'autoconnect, une interface renommée et un greffon qui se charge après l'interface sont autant de pannes que vous ne voyez qu'au démarrage à froid. journalctl -u NetworkManager -b --no-pager | tail -n 40 montre ce que le démon a fait de cette connexion lors de ce démarrage. Pour un second poste, copiez le keyfile et gardez-le possédé par root en mode 600, ou utilisez nmcli connection export pour OpenVPN et réimportez le .ovpn obtenu — le chemin d'export n'a pas d'équivalent WireGuard, donc cette direction est une copie de fichier ou un import neuf depuis l'original protégé.

Version courte, dans l'ordre : confirmez le greffon ou la version de NetworkManager, importez depuis un chemin absolu, lisez les réglages analysés y compris les secret flags, comparez l'export OpenVPN à l'original, vérifiez les hooks et les routes côté WireGuard, désactivez tout second propriétaire, puis vérifiez après un redémarrage une résolution de nom et la table de routage. Quand une connexion passe tout cela, le fichier de profil qui l'a lancée peut retourner dans le stockage protégé.