Migration VPN d'IOS vers ASA : traduire l'accord, pas les commandes

Une configuration IOS qui arrive comme référence pour une migration vers ASA décrit un accord enveloppé dans la syntaxe d'une plateforme. Les adresses des pairs, les identités et les plages protégées constituent l'accord. Le porte-clés, le profil et la chaîne de cartes crypto sont la façon dont IOS l'exprime, tandis que l'ASA exprime la même intention via des groupes de tunnel et leurs attributs. Copier la seconde partie ne fonctionne jamais, et ne copier que la première laisse le travail à moitié fait.

Parcourez les cinq étapes ci-dessous dans l'ordre, et arrêtez-vous partout où les deux plateformes décrivent des choses différentes plutôt que des mots différents.

Étape 1 : séparez l'accord de la syntaxe

Rédigez la remise comme des exigences sur lesquelles les deux administrateurs s'accordent. Quatre lignes couvrent presque tout : où se trouve le pair et quel côté initie, comment chaque côté prouve son identité, quelle protection est acceptable, et quelles applications doivent survivre au tunnel. Aucune de ces lignes ne mentionne une commande.

Conservez le texte d'origine comme preuve et non comme instructions. Une ligne qui existe sur une plateforme et pas sur l'autre est une différence de syntaxe tant que vous n'avez pas vérifié si la même exigence peut être satisfaite autrement.

Étape 2 : nommez les objets sur chaque plateforme

Sur IOS XE, un porte-clés IKEv2 alimente un profil IKEv2, et ce profil est rattaché via une carte crypto ou un profil IPsec. Sur l'ASA, un groupe de tunnel contient le profil de connexion et ses attributs IPsec, et la carte crypto pointe vers lui, comme le décrit le guide du profil de connexion. Ce sont des graphes d'objets différents avec un héritage différent, et c'est pourquoi une correspondance ligne par ligne produit une configuration qui s'analyse et ne se connecte pas.

Construisez les objets cibles à partir des lignes d'exigences et non des lignes sources. Si les lignes sont complètes, la configuration cible est une décision de conception. Si elles ne le sont pas, aucune quantité de traduction de commandes ne fournira l'intention manquante.

Étape 3 : transportez l'identité, pas seulement les adresses

L'identité est la partie qui casse en silence. Un pair qui s'authentifie par adresse se comporte différemment de celui qui s'authentifie par sujet de certificat ou par FQDN, et les deux plateformes consignent cette attente à des endroits différents. Préservez l'identité prévue et la chaîne de confiance au lieu de remplacer un secret partagé parce que c'est plus facile à tester.

Gardez le secret prépartagé hors des notes de comparaison et des tickets. Consignez qui le détient et comment il circule par un canal approuvé, et rappelez-vous qu'un espace réservé tiré d'un exemple de documentation n'est pas l'identifiant du client.

Étape 4 : convenez de la protection avant la bascule

Ne reportez pas d'anciens paramètres cryptographiques parce qu'ils figurent dans le texte fourni. Convenez d'une intersection de suites que les deux pairs déployés prennent en charge actuellement, et confirmez-la avec l'autre administrateur avant la fenêtre de changement. Si cette intersection diffère de ce que le pair existant attend, il s'agit d'un changement coordonné et non d'une modification locale.

Écrivez l'ensemble convenu. Deux administrateurs ayant des souvenirs différents d'un appel téléphonique, voilà comment une bascule produit un décalage de phase deux.

Étape 5 : vérifiez le service, pas la syntaxe

Vérifiez d'abord les objets effectifs de la cible, puis l'association acceptée, puis un flux applicatif réel et sa réponse. Saisir une commande sans erreur prouve la syntaxe et rien d'autre. Un tunnel qui monte et ne transporte aucun trafic signifie généralement que les plages protégées ou la route de retour ne correspondent pas à l'autre côté, ce qui est un problème de ligne d'exigences et non de commande. Comparez les plages protégées des deux côtés avant de retoucher la carte crypto.

Consignez ce que vous avez vérifié, avec quelles adresses et de quel côté. Ce compte rendu transforme une affirmation ambiguë selon laquelle le VPN est actif en quelque chose que l'autre administrateur peut contrôler de façon indépendante.

Ce qu'il faut rendre

Envoyez la matrice des exigences, un résumé de la configuration cible et les résultats de vérification. Indiquez explicitement quels paramètres sources vous n'avez pas reportés et pourquoi. Cette liste est plus utile que la configuration traduite, car c'est là que commencera le prochain désaccord.

Conservez aussi le texte source avec le ticket. Il documente ce qui a été demandé, tandis que la matrice documente ce qui a été convenu.