Zwei Crypto-Maps, ein Flow: Der spätere Eintrag ist kein Backup

Fügen Sie einen zweiten Crypto-Map-Eintrag für dasselbe Adresspaar hinzu, richten Sie ihn auf einen anderen Peer und Sie haben einen Failover-Plan geschrieben. Das ist der Mythos, und er überlebt, weil er wie jede andere geordnete Liste aussieht, die Sie konfiguriert haben. Die Reihenfolge in einer Crypto-Map entscheidet, welcher Eintrag einen neuen Flow beansprucht, nicht welcher Eintrag übernimmt, wenn ein Peer aufhört zu antworten. Nichts in dieser Liste überwacht die Gegenseite, also sitzt der zweite Eintrag dort und beansprucht überhaupt nichts.

Der Mythos: Reihenfolge bedeutet Ausweichen

Eine geordnete Liste mit zwei Einträgen und einer gemeinsamen Definition fühlt sich wie primär und sekundär an. Die Ähnlichkeit endet bei der Syntax. Die ASA-Dokumentation von Cisco beschreibt die Crypto-Map als das Policy-Modell, das geschützten Verkehr abgleicht und die Peer-Anordnung dafür benennt, und der Abgleich erfolgt gegen den Eintrag, der den Flow zuerst beansprucht. Die Verfügbarkeit eines entfernten Peers ist nicht Teil dieser Bewertung.

Was Sie gebaut haben, ist eine Policy, die für diesen Flow nie konsultiert wird, plus ein Kommentar in einem Änderungsdatensatz, der Redundanz behauptet.

Die Reihenfolge beansprucht den Flow, und nur einmal

Jeder Eintrag enthält eine Zugriffskontrollliste oder eine Definition eines geschützten Flows, und jedes neue ausgehende Paket wird in der Reihenfolge mit diesen Definitionen verglichen. Der erste Eintrag, dessen Definition passt, besitzt den Flow und seinen Peer. Ein zweiter Eintrag mit identischer Definition kommt nie zum Zug, weil der erste bereits gepasst hat; ein zweiter Eintrag mit engerer Definition bedient nur Flows, die der erste nicht beansprucht hat.

Dieses Verhalten ist nützlich, wenn Sie bewusst Ausnahmen aus einer breiten Policy herausschneiden, und es ist als Failover-Mechanismus nutzlos. Prüfen Sie, was tatsächlich passiert ist, mit show crypto map und show crypto ipsec sa peer, und verfolgen Sie dann ein synthetisches Paket über den Pfad, den es Ihrer Meinung nach nimmt. Die Verfolgung nennt den Eintrag, der es beansprucht hat, und das ist die einzige Antwort, die zählt.

Routenauswahl und Policy-Eigentum sind getrennte Entscheidungen

Eine Routing-Tabelle beantwortet, wohin das Paket weitergeleitet wird. Die Crypto-Policy beantwortet, welcher Schutz und welcher Peer für den ausgewählten Verkehr gelten. Das Duplizieren eines Quell- und Zielpaars unter einem anderen Peer ändert die zweite Entscheidung und lässt die erste unberührt, sodass Antworten möglicherweise noch dem alten Gateway folgen, während das ausgehende Paket den neuen Peer nimmt. Diese Asymmetrie erzeugt einen Tunnel, der sich als aktiv meldet und nichts durchlässt.

Halten Sie auch den Vertrag mit der Gegenseite wechselseitig: akzeptierte Identität, geschützte Adressbereiche, eine Rückroute für die interessanten Präfixe und die Erlaubnis für den Dienst. Eine alternative ausgehende Wahl, die die andere Seite nicht erwartet, ist kein alternativer Pfad, sondern die Hälfte eines solchen.

Was ein echter alternativer Pfad braucht

Wählen Sie einen Mechanismus, der für die Aufgabe entworfen wurde: eine unterstützte Gruppe von Peer-Kandidaten, einen gerouteten Tunnel mit einer Floating-Static- oder einer dynamischen Routing-Nachbarschaft darüber, oder welches Redundanzdesign Ihre Plattform für diesen Dienst auch dokumentiert. Schreiben Sie dann auf, welche Komponente den Ausfall erkennt und welche Komponente die Alternative auswählt, denn das sind zwei verschiedene Funktionen und oft zwei verschiedene Teams.

Adressübersetzung kann einem Standort auch eine zweite präsentierte Adresse geben, aber sie ändert gleichzeitig Selektoren, Protokollierung und quellbasierte Zugriffsregeln. Behandeln Sie das als ausdrückliche Anforderung und nicht als Notlösung für zwei mehrdeutige Einträge.

Testen Sie drei Zustände, nicht einen

Die Konfiguration ist erst fertig, wenn sie eine belastbare Antwort für den Normalbetrieb, für den Zustand des ausgefallenen Primärsystems und für die Rückkehr zum Primärsystem hat. Testen Sie alle drei und halten Sie fest, welcher Policy-Eintrag und welcher Peer jeweils gedient hat. Ein Test, der nach dem ersten Zustand aufhört, beweist, dass das Design funktioniert, wenn nichts falsch ist, und das ist der Zustand, den Sie nicht prüfen mussten.

Unterscheiden Sie außerdem konfigurierte Überlappung von der legitimen Koexistenz alter und neuer Assoziationen während einer Schlüsselerneuerung. Mehrere aktive SAs sind normal und vorübergehend; zwei Einträge, die um einen Flow kämpfen, sind dauerhaft und unsichtbar.