Keyfile ou Netplan : où le profil VPN est-il vraiment stocké ?

Trouver le fichier importé est la partie facile et souvent le mauvais point de départ. Ce qui compte, c’est le fichier que NetworkManager lit aujourd’hui comme connexion enregistrée, et cela dépend d’un identifiant de connexion ainsi que du backend de configuration réellement utilisé par les paquets installés. Modifier l’import avant d’avoir répondu à cette question, c’est ainsi qu’un VPN fonctionnel devient deux configurations à moitié correctes.

Le fichier importé n’est pas le profil enregistré

Trois noms flottent autour de chaque problème VPN : le nom de la connexion, le nom du fichier importé et l’interface virtuelle qui apparaît quand le tunnel monte. Aucun ne désigne la configuration enregistrée, et le nom d’une connexion peut être modifié tandis que le fichier derrière garde son identifiant d’origine.

Commencez par un inventaire en lecture seule et choisissez le VPN visé par identifiant plutôt que par libellé :

nmcli -f NAME,UUID,TYPE connection show

Laissez les noms d’hôtes des points de terminaison et les libellés d’identité hors de tout inventaire collé dans un ticket. La partie utile est le type et l’identifiant ; le reste est un contexte dont un inconnu n’a pas besoin. Masquez le reste avant de partager et dites que vous l’avez fait, pour que personne ne se demande ce que signifient les blancs.

Les emplacements du keyfile ne signifient pas la même chose

Avec le greffon keyfile natif, les fichiers de connexion peuvent apparaître dans trois répertoires, et la différence entre eux est la persistance, pas la commodité.

Modifier la copie d’exécution semble réussir jusqu’au prochain démarrage, où le changement s’évapore et le fichier paraît mystérieusement rétabli. Modifier la copie fournie par le paquet fonctionne jusqu’à ce qu’une mise à niveau la remplace, ce qui est une version plus lente et plus déroutante de la même leçon.

La documentation du keyfile ajoute un détail à respecter : ces fichiers peuvent contenir des clés privées et des phrases de passe, et NetworkManager ignore tout keyfile que des utilisateurs autres que root peuvent lire ou écrire. Élargir les permissions du répertoire pour chercher un réglage casse le comportement de chargement que vous vouliez inspecter.

Quand Netplan possède la persistance

Sur Ubuntu, l’intégration NetworkManager décrite dans la documentation de Netplan, disponible depuis 23.10, change l’emplacement de la copie durable. Pour les connexions non temporaires, elle écrit /etc/netplan/90-NM-<connection UUID>.yaml et génère un profil NetworkManager éphémère sous /run/NetworkManager/system-connections/.

C’est une intégration de distribution, pas une règle pour toute installation de NetworkManager. Confirmez que les paquets installés l’utilisent réellement avant d’aller chercher un fichier YAML. Rappelez-vous aussi qu’un profil d’exécution peut être une représentation générée d’autre chose plutôt que la source qu’il vaut la peine de modifier. Deux commandes de vérification économisent une heure à modifier le mauvais fichier.

L’exemple documenté enregistre une connexion OpenVPN via le type Netplan nm-devices avec des données de transit NetworkManager. Le fait que Netplan n’ait pas d’interprétation dédiée d’un champ VPN donné ne signifie pas que votre VPN enregistré est perdu ; cela signifie que le champ voyage comme des données opaques.

Les interfaces transitoires ne sont pas des profils

L’activation crée des connexions et interfaces virtuelles temporaires qui n’étaient pas censées persister. L’intégration n’écrit délibérément pas de nouveau fichier YAML pour chacune, donc leur absence de /etc/netplan ne dit rien sur le fait que le profil parent soit enregistré.

Si vous traquez un fichier qui apparaît et disparaît, vous regardez probablement l’un de ceux-ci plutôt que votre configuration. Vérifiez qu’il survit à un redémarrage avant de tirer une conclusion de son contenu. Un fichier d’exécution qui disparaît au redémarrage vous dit qu’il n’a jamais été la source, et cette seule observation réoriente toute l’enquête. Elle explique aussi pourquoi une modification semblait réussir sur le moment.

Secrets et propriété

Un profil peut référencer un certificat ou une clé stockés ailleurs, et un mot de passe peut appartenir à NetworkManager, être fourni par un agent secret de session utilisateur, ou ne pas être enregistré volontairement. Localiser un seul fichier règle donc très peu de chose sur ce qu’exigera un démarrage sans surveillance.

Inspectez les références et les indicateurs de secrets sans imprimer de valeurs secrètes. Une ouverture de session de bureau peut rendre disponible un agent absent au démarrage, et copier un fichier d’exécution généré ne reproduit pas cet agent. Le symptôme pratique est un tunnel qui se connecte quand quelqu’un se connecte et échoue quand la machine démarre seule. Ce schéma pointe vers la propriété des secrets, pas vers le routage.

Effectuez les changements approuvés via le gestionnaire qui possède la connexion, puis vérifiez à la fois l’identifiant enregistré et la connexion effective. Gardez un seul propriétaire persistant, car modifier l’import, un keyfile généré et une source YAML séparément laisse trois explications concurrentes de ce que la prochaine reconnexion utilisera. Choisissez celle qui persiste réellement, ne modifiez qu’elle et notez dans le ticket quel fichier vous avez traité comme faisant autorité. La personne suivante vous remerciera pour une ligne de provenance.