Application VPN du fournisseur ou NetworkManager : à qui appartient l’état ?
Un profil nomme un greffon, pas le comportement du client du fournisseur. Cartographiez qui détient l’enrôlement, le DNS, le blocage et les mises à jour avant de basculer un portable géré.
Importer un profil n’est pas la même chose que remplacer un client. NetworkManager stocke un type de greffon avec des données et des secrets propres au greffon, et c’est le greffon propriétaire de ce type qui décide de ce que la connexion peut faire. Tout ce que l’application du fournisseur empile par-dessus, de l’enrôlement au blocage permanent, vit hors du fichier. La sûreté du basculement dépend des couches sur lesquelles vous comptez réellement.
Le fichier nomme un greffon, pas un ensemble de fonctions
La référence des réglages VPN de NetworkManager décrit un type de service qui sélectionne le greffon, plus un dictionnaire de données opaque et un dictionnaire de secrets que seul le greffon interprète. Le profil est un contrat avec une implémentation, non la description d’un comportement que n’importe quel client pourrait reproduire. Deux clients peuvent parler le même protocole et différer tout de même sur ce qu’ils négocient et sur les chemins de données qu’ils activent. L’étiquette d’un protocole vous dit ce qu’est le tunnel, jamais ce que le client alentour en fait.
Comparez donc des exigences, pas des enveloppes. La question n’est pas de savoir si l’alternative peut se connecter, car elle le peut en général ; elle est de savoir si chaque exigence qui rendait le client d’origine acceptable survit au transfert. Écrivez ces exigences avant d’installer quoi que ce soit, sinon la comparaison tourne à la chasse à ce qui casse en premier.
Ce que l’application du fournisseur ajoute autour du tunnel
Les clients de fournisseur regroupent couramment l’enrôlement et les contrôles de posture de l’appareil, un parcours à second facteur avec sa propre interface, le blocage permanent, un canal de mise à jour et des outils de support. Une partie se tient à côté du protocole, et une autre est un produit distinct qui partage seulement un installeur. NetworkManager peut remplacer le tunnel et son routage, et des scripts de répartiteur peuvent déclencher des actions quand la connexion change d’état. Il ne reproduit pas un moteur de blocage, un parcours de renouvellement de certificat ni une hypothèse sur l’utilisateur autorisé à monter la connexion.
Plus de composants ne veut pas dire plus sûr, et moins ne veut pas dire plus faible. La question est de savoir quel composant applique la politique que l’on vous a dit de suivre. Si un auditeur demande ce qui bloque le trafic quand le tunnel tombe, la réponse doit nommer quelque chose qui le fait vraiment, et un profil qui ne fait que se connecter n’est pas cette réponse.
Où la propriété diffère réellement
Lisez ceci comme une carte de propriété et non comme une liste de vérification, car les défaillances ci-dessous sont des trous de propriété et aucune quantité de configuration client ne les comble. Chaque ligne nomme la couche, le camp qui la détient habituellement aujourd’hui et l’endroit où le trou apparaît en premier.
| Layer | Vendor application | NetworkManager connection | Where the gap shows up |
|---|---|---|---|
| Enrollment and posture | built into the client | absent unless something else supplies it | a managed device fails its next posture check |
| Address and resolver authority | the client sets both | the plugin plus dispatcher scripts | names resolve through the wrong resolver after a state change |
| Blocking on drop | a bundled engine | nothing by default | traffic continues in the clear after the tunnel dies |
| Upgrade path | the vendor's own channel | the distribution package and its plugin | a plugin update changes behaviour with no vendor note |
| Diagnostics and support | vendor tooling with client state | journal and dispatcher output | support cannot see why negotiation failed |
Associez chaque ligne à une observation que vous pouvez répéter, pas à une impression sur le client. Un nom résolu par le résolveur prévu, une route qui disparaît quand le tunnel s’arrête et une connexion bloquée après une coupure simulée sont trois observations qui couvrent ensemble l’essentiel du tableau. Écrivez l’observation à côté de l’exigence qu’elle prouve, et gardez celles qui ont échoué, car une observation ratée est la seule partie du dossier qui prédit l’incident suivant.
Basculer sans superposer la propriété
Faire tourner en même temps le client du fournisseur et une connexion NetworkManager pour le même service est la façon la plus courante dont ces comparaisons tournent mal. Les deux installent des routes, les deux peuvent définir le DNS et les deux peuvent toucher l’état du pare-feu. Ce que vous mesurez alors est un troisième agencement qui ne correspond au comportement documenté d’aucun des deux clients.
nmcli -f NAME,UUID,TYPE connection show
nmcli connection show work --show-secrets | grep -E "^vpn\."
journalctl -u NetworkManager -b --since "10 min ago"La première commande vous dit si le profil est seulement de type VPN. La seconde montre le type de service du greffon et quels secrets sont stockés, ce qui compte quand une clé est attendue d’un agent plutôt que du fichier. Le journal est l’endroit où un greffon chargé mais incapable de négocier le dira. Si aucun des trois ne montre de problème, le trou se situe dans les couches de politique au-dessus du tunnel, non dans la connexion.
Déconnectez l’ancien client avant d’activer la nouvelle connexion, gardez des extrémités et un compte identiques, et notez quel composant détient les routes, les réglages du résolveur et le blocage. Cette note est ce qui empêche la prochaine mise à jour de finir avec deux propriétaires.