ConnMan VPN : le menu manquant est un démon, pas un protocole

L’idée reçue est qu’un système ConnMan sans entrée VPN sur le bureau n’a aucune prise en charge VPN installée. En général, il dispose de la prise en charge du Wi-Fi et d’aucune pour le démon VPN, la configuration du fournisseur ou l’agent d’authentification, et ce sont trois absences distinctes. Le menu est une vue sur ces composants, pas la fonctionnalité elle-même. Vérifier la version et le packaging vous en apprend plus en une commande que n’importe quel nombre de rapports de bogue du bureau.

Le mythe : le menu est la fonctionnalité VPN

Commencez par la version installée de ConnMan et les paquets qui l’accompagnaient. Un rapport de bogue d’une version plus ancienne décrit un autre ensemble de fonctionnalités, et le citer finit généralement par la réinstallation d’un gestionnaire de réseau qu’il n’était pas nécessaire de remplacer.

Notez ce que vous avez réellement avant de changer quoi que ce soit : le binaire du démon, le répertoire des fournisseurs et la présence éventuelle d’un agent.

Quel démon possède le tunnel

Dans la documentation de ConnMan 1.41 pour Debian bookworm, connman-vpnd est le démon qui gère les connexions VPN aux côtés de connmand. Il répertorie des intégrations pour des assistants VPN nommés, dont OpenVPN et OpenConnect. Cette liste est une affirmation sur les assistants, pas la promesse que chaque protocole ou flux d’authentification fonctionnera. Lisez-la comme un menu de ce qu’il faut vérifier, non comme une garantie de compatibilité.

Faites ensuite correspondre l’intégration au protocole approuvé de la passerelle. Le mot Cisco ne vous dit pas si vous avez besoin d’une connexion à l’ancienne, de style vpnc, ou d’un flux compatible AnyConnect, et un mauvais choix produit un échec d’authentification qui ressemble à un problème d’identifiants.

Si un assistant autonome et ConnMan peuvent tous deux monter le tunnel, décidez lequel possède les routes, le DNS et le cycle de vie avant que l’un ou l’autre démarre.

Les réglages du démon ne sont pas ceux du fournisseur

La configuration générale du démon et celle d’un fournisseur particulier sont des fichiers différents, aux formats différents. Dans l’agencement bookworm documenté, le démon lit /etc/connman/connman-vpn.conf, tandis que les fichiers de provisionnement des fournisseurs résident sous /var/lib/connman-vpn/ avec un suffixe .config. Déposer un profil OpenVPN dans ce répertoire ne le transforme pas en fichier de provisionnement ConnMan. Le manuel du fournisseur pour cette version décrit les sections de fournisseur et les champs propres au type dont ces fichiers ont réellement besoin.

Ne traduisez que par le mappage pris en charge de l’intégration installée. La confiance dans le certificat, les références de clé privée, l’identité de la passerelle, les routes et les entrées d’authentification gardent chacun leur rôle, et un exemple pour un autre type de fournisseur n’est pas interchangeable simplement parce que les deux ont besoin d’une adresse de serveur.

Quand un fournisseur ne se charge pas, comparez ses champs au manuel de la version installée plutôt qu’à un exemple de blog.

L’agent d’authentification est une dépendance distincte

Une définition de fournisseur peut encore avoir besoin d’un agent pour obtenir des identifiants ou terminer un échange d’authentification. Pour son intégration OpenConnect, le même manuel explique que les valeurs liées à l’authentification qui manquent peuvent être demandées via l’API VPN Agent, et qu’un cookie de courte durée ne convient généralement pas comme secret de configuration permanent. Ce mécanisme ne garantit pas la prise en charge de chaque connexion dans le navigateur, de chaque demande MFA ou de chaque contrôle de posture de la passerelle. Confirmez l’ensemble du flux avec la personne responsable du déploiement.

Ne compensez pas un agent absent en écrivant un mot de passe ou un jeton de session dans un fichier largement lisible. Cela transforme une intégration manquante en exposition d’identifiants, et le second problème survit au premier.

Si la passerelle exige une connexion interactive, l’agent fait partie de la conception et non d’un ajout facultatif.

Vérifiez quatre résultats, pas un seul

Après un provisionnement autorisé, vérifiez quatre choses séparément : le fournisseur est sélectionné, la connexion est authentifiée, les routes effectives sont celles que vous vouliez, et le résolveur se comporte comme prévu. Un démon en cours d’exécution, un fournisseur listé et une application qui atteint sa ressource sont trois résultats différents, et seul le dernier est le véritable objectif de l’utilisateur. Les consigner séparément vous dit quelle étape corriger.

Incluez dans ce contrôle le comportement de reconnexion et la politique d’état indisponible requise, car un tunnel qui monte une fois et ne se rétablit jamais n’est pas déployé. Gardez la configuration réseau de base fonctionnelle récupérable pendant que vous modifiez l’intégration VPN.

Remplacer le gestionnaire Wi-Fi pour obtenir un bouton est un changement bien plus important que l’opération manquante requise, et c’est généralement le mythe qui gagne.