Un VPN secondaire appartient à un profil Wi-Fi, pas à tous

Configurez un VPN comme secondaire de la connexion Wi-Fi du domicile et tout fonctionne, jusqu'à ce que l'ordinateur portable rejoigne un autre point d'accès et que le tunnel reste inactif. La nouvelle connexion est un objet de configuration distinct doté de son propre UUID, et elle n'a aucune raison de connaître le lien que vous avez créé pour son prédécesseur. Rien n'est tombé en panne ; l'association n'a simplement jamais existé.

La référence des connexions de NetworkManager définit les secondaires comme des UUID qui s'activent avec une connexion de base donnée. Elle précise aussi que les profils VPN ordinaires n'implémentent pas l'activation automatique comme le font les connexions de base. Les deux affirmations mènent à la même conclusion : l'association est propre à chaque profil, et quelqu'un doit la créer pour chaque nouveau.

Ce qu'est réellement un secondaire

Une connexion de base possède une identité, un UUID et une liste de secondaires. Lorsqu'elle s'active, le gestionnaire active aussi ces secondaires dans l'ordre, et c'est ainsi qu'un VPN finit par suivre un réseau Wi-Fi sans clic manuel. La relation réside sur la connexion de base, écrite sous forme de chaînes UUID plutôt que de noms. Ce choix de représentation n'est pas fortuit ; c'est lui qui permet à l'association de survivre à un renommage.

Ce détail sur les noms compte plus qu'il n'y paraît. Renommer un profil VPN laisse son UUID intact, de sorte que les associations existantes continuent de fonctionner. Supprimer l'ancien profil et importer un nouveau produit un nouvel UUID, et toute association qui pointait vers l'ancien ne pointe plus vers rien.

Examinez la liste existante avant d'ajouter quoi que ce soit. Un profil domestique portant un secondaire n'est pas une règle qui correspond à chaque SSID ; c'est une ligne dans un objet, et elle ne sera pas consultée lorsqu'une autre base s'active.

Placez l'association là où les profils sont créés

Sur une machine personnelle, faites de l'attachement du secondaire prévu une partie de l'ajout de chaque profil Wi-Fi autorisé. C'est une habitude plutôt qu'une fonctionnalité, mais une habitude qui produit un état cohérent, et elle coûte une commande ou deux visites de dialogue par réseau. Tenez une courte note des réseaux censés porter le tunnel, car la liste est la politique.

Sur les appareils gérés, faites en sorte que le flux de provisionnement crée l'entrée Wi-Fi et son association VPN à la même étape, et appliquez le même traitement aux profils autorisés qui existent déjà. Distribuer un profil VPN seul laisse les relations de base non précisées, et c'est ainsi qu'un parc se retrouve avec un tunnel que la moitié des ordinateurs seulement utilisent.

Là où les utilisateurs peuvent encore créer des profils en dehors du chemin géré, décidez explicitement ce qu'il advient de ces entrées. Supposer qu'elles héritent d'une association n'est pas une politique ; c'est un espoir assorti d'un coût de support.

Planifiez le changement d'identité du VPN

La source de provisionnement a besoin de l'UUID du VPN prévu, pas d'un nom d'affichage que quelqu'un a deviné. Lorsque la maintenance remplace ce VPN par un objet fraîchement importé, mettez à jour le modèle de provisionnement et les associations existantes concernées dans la même modification. Un renommage n'est pas un remplacement, et traiter les deux comme équivalents est la façon dont un déploiement qui fonctionne casse une semaine plus tard.

Conservez l'UUID à côté de la raison pour laquelle il existe. Un futur ingénieur qui trouve un UUID nu dans une liste de secondaires n'a aucun moyen de dire s'il est à jour, et le supprimera probablement en rangeant.

L'activation n'est pas l'application forcée

Une demande de secondaire se produit au moment de l'activation. Elle ne bloque pas les applications pendant l'intervalle précédant la fin de l'authentification, et elle n'arrête pas le trafic après l'échec du tunnel. Ce sont des propriétés différentes, fournies par des mécanismes différents, et les confondre produit une conception qui paraît stricte dans le profil et se révèle permissive en pratique.

Bloquer le trafic direct est une fonctionnalité distincte avec sa propre configuration et ses propres modes de défaillance, et elle doit tenir compte du trafic qui doit atteindre le réseau avant qu'un tunnel puisse exister : portails captifs, pages de connexion, le point de terminaison lui-même. Une politique de blocage qui ne peut pas être satisfaite avant l'authentification enferme la machine hors du réseau dont elle a besoin.

Mettez cette distinction dans les instructions que les utilisateurs lisent réellement. Un nouveau réseau Wi-Fi peut demander le tunnel ; l'application forcée décide si quelque chose peut sortir lorsqu'il ne peut pas se connecter. Les utilisateurs à qui l'on n'explique que la première moitié signaleront la conception comme défaillante.

Testez avec un profil véritablement nouveau

Utilisez un réseau de test approuvé et un profil de base nouvellement créé, pas l'entrée domestique qui fonctionne déjà. Observez l'activation de la base, l'UUID secondaire demandé et toute invite d'authentification dans l'ordre, et notez à quelle étape cela se bloque lorsque cela se bloque. Un agent secret qui devient disponible après la connexion au bureau n'est pas automatiquement présent dans chaque contexte de démarrage, donc un redémarrage fait partie du plan de test. Vérifiez ensuite la ressource prévue et le chemin d'échec : le tunnel monte-t-il avant que l'application en ait besoin, et qu'arrive-t-il à cette application lorsque l'authentification échoue ?

Vérifiez ensuite la ressource prévue et le chemin d'échec : le tunnel monte-t-il avant que l'application en ait besoin, et qu'arrive-t-il à cette application lorsque le tunnel ne peut pas s'authentifier ? Ces deux observations sont les critères d'acceptation, et aucune des deux n'est visible dans le profil lui-même.