Ein Subnetz ohne Ausfall auf einen neuen VPN-Tunnel umziehen

Bringen Sie den neuen Tunnel hoch, verlegen Sie ein Subnetz, und genau dieses Subnetz fällt nun sporadisch aus, während alles andere tadellos läuft. Halb migrierte VPNs scheitern genau so, weil der Tunnel nie der schwierige Teil war. Der Pfad umfasst auch, welche Route gewinnt, welche Selektoren passen, was die Zugriffsregeln erlauben, wie Antworten zurückkommen und jede Übersetzung, die das alte Design anwandte. Verlegen Sie nur den Tunnel, und Sie haben nichts davon verlegt.

Der Tunnel ist die leichte Hälfte des Pfads

Sporadische Ausfälle nach einer Teilmigration bedeuten normalerweise, dass beide Pfade plausibel sind. Manche Flüsse nehmen den neuen Tunnel, andere bleiben beim alten, und ein zustandsbehaftetes Gerät sieht dann eine Antwort auf einem Pfad ankommen, den die Anfrage nie benutzt hat. Zwei Pfade sind nicht automatisch sicherer als einer; sie sind zwei Dinge, die sich widersprechen können. Beobachten Sie die Berichte über Pfadwechsel statt der Tunnelzähler, denn die Zähler sehen die ganze Zeit gesund aus.

Die nützliche erste Frage ist nicht, welcher Tunnel besser ist. Sie lautet, welche Flüsse heute welchen Pfad wählen und ob Anfrage und Antwort dieselbe Antwort bekommen.

Bauen Sie das Ziel, bevor Sie es bevorzugen

Bestätigen Sie, dass die Peers kompatibel sind und dass der neue Tunnel den beabsichtigten Adressbereich trägt. Fügen Sie die Weiterleitung und die Dienstberechtigungen hinzu, die er braucht, solange er noch der nicht bevorzugte Pfad ist, damit der Umschnitt selbst nur die Auswahl ändert und sonst nichts.

Fragen Sie den entfernten Standort, wie er den Verkehr zurückführen wird. Wenn Antworten weiterhin über den alten Tunnel verlassen, erzeugt eine neue lokale Route Asymmetrie oder scheitert an einem Filter, der Zustand merkt. Die Übersetzung gehört aus demselben Grund ins Design: eine geänderte Quelladresse ändert auch den Rückweg.

Schneiden Sie eng um, und kennen Sie den Weg zurück

Benennen Sie das genaue Subnetz und den plattformgestützten Mechanismus, der seine neue Route oder seinen Selektor bevorzugt. Richtlinienbasierte Definitionen verhalten sich nicht immer wie Routenmetriken, lesen Sie deshalb die Regeln für überlappende Richtlinien Ihrer Implementierung, bevor Sie annehmen, dass die spezifischere Übereinstimmung gewinnt.

Verlegen Sie ein Subnetz, nicht einen Standort. Halten Sie den Verwaltungszugang auf einem Pfad, den Sie nicht anfassen, und schreiben Sie das Rollback auf, bevor Sie irgendetwas anwenden: welche Route oder Richtlinie zurückgeht, wer es tut und wie sie dabei verbunden bleiben.

Asymmetrie und veralteter Zustand

Firewalls und NAT-Geräte merken sich die Schnittstelle, die ein Fluss benutzt hat. Wenn Anfrage und Antwort verschiedene Tunnel nehmen, kann das Gerät die Antwort verwerfen, obwohl jeder Pfad für sich funktioniert. Testen Sie mit einem Fluss, den Sie nach der Änderung öffnen, denn eine bestehende Sitzung kann stundenlang den alten Pfad weiterbenutzen.

Wenn sich die beobachtete Quelladresse verschoben hat, finden Sie jede Richtlinie, die die alte nennt. Eine Migration, die die Quelle still ändert, bricht Regeln, die niemand als Teil des VPN-Designs eingeordnet hat.

Beweisen Sie beide Antworten, dann ziehen Sie die alte Richtlinie zurück

Erreichen Sie von einem gewöhnlichen Host im migrierten Subnetz den vorgesehenen Dienst und prüfen Sie die beobachtete Quelle und die Antwortschnittstelle. Testen Sie dann ein Netz, das auf dem alten Tunnel bleiben soll, denn eine Migration ist erst fertig, wenn beide Antworten stimmen. Der zweite Test ist der, den Leute auslassen, und er ist der, der einen Selektor fängt, der breiter ist als beabsichtigt.

Ziehen Sie die überholte Richtlinie erst zurück, wenn kein verbleibendes Subnetz mehr von ihr abhängt, und halten Sie die endgültige Route mit ihrem Eigentümer im Selektor-Inventar fest. Fertig ist nicht, dass der neue Tunnel oben meldet; fertig ist, dass jedes Netz seinem vorgesehenen Pfad folgt.