Zwei IPsec-Gateways, keine gemeinsame IP: Was Failover wirklich leistet

Töten Sie Gateway A während einer Besprechung und beobachten Sie, wie der Tunnel eine Minute später über B zurückkommt; die Verbindung funktioniert, der Videoanruf vielleicht nicht. Das ist die ehrliche Gestalt des kalten Failovers zwischen zwei IPsec-Gateways mit unabhängigen Adressen. Der Client wählt einen Endpunkt neu und baut eine neue Beziehung auf, was die Erreichbarkeit wiederherstellt, ohne den kryptografischen Zustand der alten Sitzung zu übertragen. Wer den Ablauf nachvollzieht, erkennt, welche Versprechen das Design halten kann.

Die Szene: zwei Adressen, keine schwebende IP

Gateway A antwortet unter einer erreichbaren Adresse, Gateway B unter einer anderen. Der Client hat einen genehmigten Weg, B zu wählen, wenn A weg ist, und es gibt keine gemeinsame Außenadresse, die beide Gateways beanspruchen. In diesem Design meint eine virtuelle IP genau diesen gemeinsamen Einstiegspunkt, nicht die innere Adresse, die einem Fernzugriffsclient zugewiesen wird.

Diese Definition ist wichtig, weil die beiden Vorstellungen in Tickets vermischt werden und die Behebung der einen nicht die Behebung der anderen ist. Ein Bericht, dass der gemeinsame Einstieg nicht dem Gateway gefolgt ist, beschreibt ein Design. Ein Bericht, dass der Laptop seine innere Adresse verloren hat, beschreibt das Lease des Clients. Verschiedene Eigentümer, verschiedene Protokolle, verschiedene Reparaturen.

Den Ausfall nachvollziehen: erkennen, dann neu wählen

Zuerst bemerkt etwas, dass A nicht mehr antwortet. Das kann Dead-Peer-Erkennung auf der Tunnelschicht sein, ein Routingprotokoll, das einen Pfad zurückzieht, oder ein Anwendungs-Timeout, das schließlich eine Neuverbindung erzwingt. Jedes hat eine andere Zeitskala, und das langsamste bestimmt meist, wie lange Nutzer warten.

Dann wählt der Client B über den Mechanismus, den die Bereitstellung unterstützt: ein zweites konfiguriertes Remote, ein DNS-Name, der auf eine gesunde Adresse aufgelöst wird, oder Routing, das nun einen anderen Pfad bevorzugt. Die Auswahl ist ein Richtlinienelement und muss vor dem Ausfall existieren, sonst geschieht sie zufällig.

Was B erben kann und was nicht

B kann eine Konfigurationsvorlage, eine Zertifizierungsstelle und eine Authentifizierungsrichtlinie mit A teilen. Es kann die lebenden Sicherheitsassoziationen nicht erben. Sitzungsschlüssel, Sicherheitsparameter-Indizes und Sequenzzustand gehören zu der Beziehung, die A und der Client aufgebaut haben, und B hat nichts davon.

Diesen Zustand zwischen Gateways zu verschieben ist ein echtes Ingenieursproblem, weshalb die Hochverfügbarkeitsdokumentation von strongSwan es als Cluster-Design behandelt und nicht als Konfigurationsschalter. Ein bestimmtes Cluster-Rezept ist keine allgemeine Antwort für ein Cloud-Netzwerk, und es ohne die begleitende Infrastruktur zu kopieren, kauft Komplexität statt Kontinuität.

Eine neue Beziehung aufbauen

Mit gewähltem B führt der Client einen neuen IKE-Austausch durch: neue Nonces, neue Diffie-Hellman-Werte, neue Bezeichner für die entstehenden Assoziationen. Die Authentifizierung erfolgt erneut bei B. Beruht das Design auf Maschinenanmeldedaten, kann die Neuverbindung unbeaufsichtigt ablaufen; verlangt es einen menschlichen Faktor, muss jemand anwesend sein, damit das Failover abgeschlossen wird.

Definieren Sie diese Nutzererfahrung vor dem Ausfall, nicht währenddessen. Sagen Sie klar, was der Client tun wird, wie lange er es versuchen wird und was er anzeigt, wenn er aufgibt, denn der Unterschied zwischen einer Minute Neuverbindung und einem Support-Anruf ist meist Dokumentation und ein getestetes Profil.

Dieselbe innere Adresse zu bewahren hilft Anwendungen, die eine stabile lokale Identität erwarten, und sie bewahrt deren Sitzungen nicht. NAT-Bindungen laufen ab, TCP-Verbindungen werden zurückgesetzt, und alles mit eigenem Timeout entscheidet selbstständig, ob es erneut versucht.

Zwei Tunnel parallel sind ein anderes Design

Beide Tunnel gleichzeitig zu betreiben ist ein gültiges Muster, wenn beide Gateways und das Routing-Design es unterstützen. Die Routenauswahl wählt dann den aktiven Pfad, und der Rückweg muss zustimmen, sonst verlässt der Verkehr ein Gateway und kommt über das andere zurück, ohne dass ein Zustand ihn zuordnet.

Überlappende Tunnelrichtlinien erzeugen für sich genommen kein geordnetes Failover. Sie erzeugen zwei Kandidaten, und etwas muss deterministisch zwischen ihnen entscheiden, sei es eine Routing-Metrik, eine Richtlinienpriorität oder eine ausdrückliche Präferenz im Client.

Welche Form Sie auch wählen, schreiben Sie den Vertrag auf: wie der Ausfall erkannt wird, wie die Alternative gewählt wird, welche Authentifizierung die Alternative verlangt und wie lange die Neuverbindung voraussichtlich dauert. Eine gemeinsame IP kann die Erkennung vereinfachen, aber sie ist kein Synonym für durchgehenden Zustand, und Verfügbarkeit ist ohnehin ein Design.