VPN-Failover: wenn der Rückweg im alten Tunnel bleibt

Der Backup-Tunnel kommt hoch, der primäre fällt aus, und die Anwendung läuft weiterhin in ein Timeout. An beiden Standorten sieht der Tunnelstatus gesund aus, und genau das macht es verwirrend. Ein Failover, das Anfragen auf das Backup verschiebt, die Antworten aber auf dem alten Pfad lässt, ist kein Failover. Das Runbook unten prüft den Rückweg, nicht nur den Handshake.

Halten Sie zuerst die Routen an beiden Enden fest; eine Sicht von nur einem Standort kann keinen asymmetrischen Pfad zeigen. Es ist außerdem der Schritt, der unter Zeitdruck am häufigsten übersprungen wird.

Routen beider Standorte vor dem Test festhalten

Notieren Sie für jedes geschützte Präfix die primäre Route, die Backup-Route und die Präferenz, die zwischen ihnen wählt. Beziehen Sie das LAN-Gateway hinter jedem VPN-Endpunkt ein, denn der Endpunkt ist selten der letzte Hop.

Statische Metriken, getrackte Routen und dynamisches Routing drücken die Eignung unterschiedlich aus. Wissen Sie, welche Ihr Design nutzt, und was nötig ist, damit die Alternative aktiv wird. Schreiben Sie die Bedingung neben die Route, zum Beispiel eine niedrigere Metrik, bis die Probe fehlschlägt.

Tun Sie das an beiden Standorten. Ein Backup, das auf einer Seite bevorzugt und auf der anderen ignoriert wird, erzeugt genau die Asymmetrie, die Sie vermeiden wollen.

Anfragen und Antworten in jeder Phase beobachten

Nutzen Sie eine harmlose erlaubte Anwendung und beobachten Sie drei Phasen: normal, Ausfall des Primärpfads und Wiederherstellung. Halten Sie in jeder Phase fest, welcher Tunnel die Anfrage und welcher die Antwort trägt. Eine erreichbare Peer-Adresse beweist nicht, dass der geschützte Anwendungspfad funktioniert. Erfassen Sie an beiden Standorten, damit ein einseitiger Fluss sichtbar wird.

Wenn Anfragen wechseln und Antworten nicht, prüfen Sie die Route des entfernten Standorts zum Client-Präfix und seine Präferenz für das Backup. Das ist eine Routingentscheidung, kein Tunnelausfall.

Stellen Sie nach dem Test den ursprünglichen Zustand wieder her und bestätigen Sie, dass der primäre Pfad wieder bevorzugt wird. Ein wiederhergestellter Primärpfad, der nicht bevorzugt wird, ist ein Failover-Design, das nicht fertig ist.

Sitzungszustand beim Gateway-Wechsel handhaben

Firewalls und NAT können Verbindungszustand an einem Gateway halten, und ein Pfadwechsel zu einem anderen Gateway überträgt ihn nicht. Manche Anwendungen verbinden sich selbst neu; andere scheitern, bis die Sitzung wiederhergestellt ist. Wenn das Backup die öffentliche Quelle oder die übersetzte private Adresse ändert, können auch Regeln für den Fernzugriff reagieren. Dokumentieren Sie jeden erwarteten Sitzungsneustart, statt unterbrechungsfreien Failover zu versprechen.

Halten Sie die Adressierung stabil, wo die Anwendung es verlangt. Ein Failover-Design, das die Quelladresse für jede Sitzung ändert, ist eine Designentscheidung, und sie sollte schriftlich festgehalten werden. Diese Entscheidung bestimmt, wie viel von der Störung die Nutzer tatsächlich bemerken.

Testen Sie eine Anwendung, die eine lange Sitzung hält, nicht nur eine neue Anfrage.

Primärpfad wiederherstellen und auf Flapping prüfen

Bestätigen Sie, dass Routenankündigungen oder Präferenzen sich ohne Oszillieren einpendeln. Ein flappender Primärpfad kann störender sein als ein klarer Ausfall, weil jeder Übergang den Zustand zurücksetzt.

Halten Sie die Gateway-Administration über einen Wiederherstellungspfad erreichbar, damit der Test Sie nicht selbst aussperrt. Halten Sie die Phasen, die beobachteten Pfade und die Wiederherstellungszeit fest; dieser Datensatz macht den nächsten Failover vorhersagbar. Die Weiterleitungshinweise von strongSwan sind nützlich, wenn die Endpunkte Linux-Hosts sind.