Migrer un VPN : licences, fonctions et politique dans un seul registre

Les sessions qui fonctionnent encore sur l’ancien concentrateur donnent l’impression d’une preuve que la migration est presque terminée. Elles ne sont qu’une ligne d’inventaire, et la moins intéressante. Ce dont le basculement a besoin, c’est d’un registre qui relie la passerelle cible, le client pris en charge, le droit acheté et la politique d’admission appliquée en un seul artefact dont quelqu’un est responsable. Sans lui, la migration n’est qu’une suite d’hypothèses qui, prises séparément, paraissent raisonnables.

Quatre colonnes, pas une liste de contrôle

Ce que le matériel peut supporter, ce que le contrat autorise et ce que le jeu de règles permet sont trois questions distinctes, et les mélanger produit un plan que personne ne peut auditer. Gardez-les dans des colonnes séparées et exigez que chacune cite sa source. Un appareil qui accepte une connexion prouve qu’un appareil peut se connecter, et cela n’explique rien sur l’étendue des fonctions ni sur la base de comptage. Trois colonnes qui se contredisent sont bien plus utiles qu’un paragraphe qui sonne sûr de lui.

Le registre est terminé quand les quatre colonnes sont remplies par quelqu’un qui a le droit de les remplir. Une colonne signée par le mauvais propriétaire est une rumeur avec une date dessus.

Plateforme et droit

Consignez la passerelle prise en charge, les systèmes d’exploitation du client, le chemin d’authentification et les outils d’administration. Ne maintenez pas un client obsolète en vie simplement parce que son ancien profil s’ouvre encore, car ce profil est une promesse de compatibilité que le fournisseur peut ne plus honorer. Comparez la déclaration de support actuelle à la version que vous prévoyez de déployer.

Pour le droit, consignez le produit, le type de licence, la durée et la base de comptage, puis réconciliez-le auprès du propriétaire du compte. Déduire des droits d’un compteur de sessions historique, c’est ainsi qu’une organisation découvre un manque après le basculement plutôt qu’avant.

Les guides de commande des fournisseurs montrent pourquoi ces distinctions comptent. Le guide de commande de Secure Client de Cisco, par exemple, sépare les niveaux Advantage, Premier et VPN Only, chacun avec sa propre mesure et son étendue de fonctions. Utilisez l’accord en vigueur plutôt que de traduire mécaniquement une ancienne étiquette.

Fonctions et politique appliquée

Énumérez les capacités dont le déploiement a réellement besoin : modes de tunnel autorisés, évaluation des appareils, intégration de l’authentification et tout autre module. Vérifiez le support et le droit de chacune séparément, car une fonction peut être prise en charge sans licence, ou sous licence et non prise en charge sur la version choisie. Seule une ligne qui répond oui aux deux questions compte.

Lorsque la cible est un ASA, la colonne des fonctions se lit sur l’équipement et non dans un contrat, alors capturez la passerelle avant le jour du basculement. show vpn-sessiondb summary donne l’inventaire des sessions actives et les comptes sur lesquels votre droit est mesuré, show vpn-sessiondb detail anyconnect montre quel type de client et quel profil chaque session attribuée a réellement utilisé, et show running-config webvpn capture la configuration de la passerelle dont ces sessions dépendent, et c’est la seule partie du registre qu’aucun document de licence ne peut contenir.

show vpn-sessiondb summary
show vpn-sessiondb detail anyconnect
show running-config webvpn

Après le basculement, exécutez les trois mêmes commandes sur la nouvelle passerelle et comparez-les aux copies capturées. Que les comptes de sessions bougent est attendu ; un type de client ou une strophe webvpn qui apparaît d’un côté et pas de l’autre est la trouvaille, et elle appartient au registre avec une explication, pas à un commentaire de ticket. Conservez les captures brutes autant que les différences, car le prochain relecteur voudra voir ce qui a été comparé. Chez un autre fournisseur, l’équivalent est la table de sessions et l’export de profils de cette plateforme, dans un format qui ne correspondra pas, alors comparez les questions qu’on lui pose plutôt que le texte.

Ensuite, associez les utilisateurs et les appareils aux règles de la cible, aux permissions de ressources et au comportement de rejet. Une licence qui active une fonction n’est pas une configuration qui l’exerce, et l’écart entre les deux est là où vivent la plupart des surprises de migration.

Écrivez les cas de rejet avec le même soin que les cas autorisés. Un plan qui ne prouve que la connexion d’un administrateur a testé le chemin le plus facile et aucune des frontières.

Acceptez des deux côtés de la décision

Avant le basculement, exécutez un plan d’acceptation approuvé sur les types de clients prévus, les méthodes d’authentification et les ressources. Incluez un appareil ou une identité qui doit être rejeté, et confirmez quelle règle l’a sélectionné et ce que la session résultante peut atteindre. Convenez des cas de refus avant l’ouverture de la fenêtre de changement, pour que personne ne puisse les abandonner discrètement sous la pression du temps. Un plan sans cas de refus a testé le chemin heureux et rien d’autre.

Gardez un chemin de retour arrière et une voie d’administration qui ne dépend pas de ce qui est migré. Conservez la configuration et les enregistrements d’identité en sécurité, et laissez derrière les réglages cryptographiques obsolètes plutôt que de les emporter. Ne collez jamais d’identifiants de licence ni d’enregistrements d’utilisateurs dans des notes publiques.

Faites signer par le propriétaire le droit et la correspondance de politique ensemble. Le registre terminé répond à deux questions à la fois : ce que l’organisation a le droit de déployer, et quelles règles admettent et contraignent réellement ses utilisateurs.