Ajoutez une seconde entrée de carte crypto pour la même paire d’adresses, pointez-la vers un autre pair, et vous avez écrit un plan de basculement. C’est le mythe, et il survit parce qu’il ressemble à toute autre liste ordonnée que vous avez configurée. La séquence dans une carte crypto décide quelle entrée revendique un nouveau flux, pas quelle entrée prend le relais quand un pair cesse de répondre. Rien dans cette liste ne surveille l’extrémité distante, donc la seconde entrée reste là sans rien revendiquer du tout.

Le mythe : l’ordre signifie secours

Une liste ordonnée avec deux entrées et une définition partagée donne l’impression de primaire et de secondaire. La ressemblance s’arrête à la syntaxe. La documentation ASA de Cisco décrit la carte crypto comme le modèle de politique qui fait correspondre le trafic protégé et nomme l’agencement des pairs pour celui-ci, et la correspondance se fait contre l’entrée qui revendique le flux en premier. La disponibilité d’un pair distant ne fait pas partie de cette évaluation.

Ce que vous avez construit est une politique qui ne sera jamais consultée pour ce flux, plus un commentaire dans un journal de changement qui affirme une redondance.

La séquence revendique le flux, et une seule fois

Chaque entrée contient une liste de contrôle d’accès ou une définition de flux protégé, et chaque nouveau paquet sortant est comparé à ces définitions dans l’ordre de séquence. La première entrée dont la définition correspond possède le flux et son pair. Une seconde entrée avec une définition identique n’obtient jamais son tour, parce que la première a déjà correspondu ; une seconde entrée avec une définition plus étroite ne sert que les flux que la première n’a pas revendiqués.

Ce comportement est utile lorsque vous découpez délibérément des exceptions dans une politique large, et il est inutile comme mécanisme de basculement. Vérifiez ce qui s’est réellement passé avec show crypto map et show crypto ipsec sa peer, puis suivez un paquet synthétique sur le chemin que vous croyez qu’il emprunte. La trace nommera l’entrée qui l’a revendiqué, et c’est la seule réponse qui compte.

La sélection de route et la propriété de la politique sont des décisions distinctes

Une table de routage répond où le paquet est transféré. La politique crypto répond quelle protection et quel pair s’appliquent au trafic sélectionné. Dupliquer une paire source et destination sous un autre pair change la seconde décision et laisse la première intacte, donc les réponses peuvent encore suivre l’ancienne passerelle tandis que le paquet sortant prend le nouveau pair. Cette asymétrie produit un tunnel qui se déclare actif et ne laisse rien passer.

Gardez aussi le contrat réciproque avec l’extrémité distante : identité acceptée, plages d’adresses protégées, une route de retour pour les préfixes intéressants et l’autorisation du service. Un choix de sortie alternatif que l’autre côté n’attend pas n’est pas un chemin alternatif, c’est la moitié d’un.

Ce dont un vrai chemin alternatif a besoin

Choisissez un mécanisme conçu pour la tâche : un groupe pris en charge de pairs candidats, un tunnel routé avec une statique flottante ou une adjacence de routage dynamique par-dessus, ou toute conception de redondance que votre plateforme documente pour ce service. Notez ensuite quel composant détecte la panne et quel composant sélectionne l’alternative, car ce sont deux fonctions différentes et souvent deux équipes différentes.

La traduction d’adresses peut aussi donner à un site une seconde adresse présentée, mais elle change en même temps les sélecteurs, la journalisation et les règles d’accès basées sur la source. Traitez cela comme une exigence explicite plutôt que comme un contournement pour deux entrées ambiguës.

Testez trois états, pas un

La configuration n’est terminée que lorsqu’elle a une réponse défendable pour le fonctionnement normal, pour l’état de défaillance du primaire et pour le retour au primaire. Testez les trois et notez quelle entrée de politique et quel pair a servi chacun. Un test qui s’arrête après le premier état prouve que la conception fonctionne quand rien ne va mal, et c’est l’état que vous n’aviez pas besoin de vérifier.

Distinguez aussi le chevauchement configuré de la coexistence légitime d’associations anciennes et nouvelles pendant une régénération de clés. Plusieurs SA actives sont normales et temporaires ; deux entrées qui se disputent un flux sont permanentes et invisibles.

Articles similaires