Provider wechseln, ohne die Site-VPN-Adressen neu zu nummerieren

Eine Filiale wechselt den Internetanbieter, und der Fileserver behält seine Adresse. Dieses Ergebnis ist in einem gerouteten Site-VPN normal und überraschend für jeden, der annimmt, die Endpunktadresse des Tunnels sei die Adresse der Anwendung. Beide leben in verschiedenen Schichten des Designs, und nur eine hat sich bewegt. Sie als eine zu behandeln, ist der Weg, auf dem ein Anbieterwechsel zum Umnummerierungsprojekt wird.

Zwei Adresspläne, die sich unabhängig bewegen

Der innere Plan beschreibt die privaten Adressen, die Anwendungen nutzen: der Filialserver unter 10.55.8.20, das Hauptstellen-Präfix, das dorthin routet, und die Rückroute. Der äußere Plan beschreibt, wie zwei Gateways einander erreichen: Peer-Adressen, Listening-Ports und der Weg über das Internet.

Ein Anbieterwechsel berührt den äußeren Plan. Er verlangt für sich genommen nicht, dass sich der innere Plan ändert.

Die beiden Bestände getrennt zu halten, ist der praktische Grund für ein Overlay, selbst wenn die Anwendung ihren eigenen Verkehr bereits verschlüsselt. Das Overlay gibt Ihnen eine stabile innere Topologie, die äußere Wechsel übersteht. Die Anwendung behält ihre Adresse, ihre Firewall-Regeln und ihre DNS-Einträge. Nur die Transporteinträge ändern sich, und das ist eine viel kleinere Prüfung.

Der äußere Tunnel trägt das innere Gespräch

In einem Gateway-zu-Gateway-Tunnel adressiert der äußere IP-Header die beiden Gateways. Der innere Header benennt weiterhin die tatsächlichen Anwendungsendpunkte. Die Gateway-zu-Gateway-Beschreibung in RFC 7296 behandelt dies als gewöhnliches Routing, das Verkehr über Tunnelendpunkte zustellt.

Deshalb kann der Filialserver 10.55.8.20 behalten, während sich die öffentliche Adresse des Gateways ändert. Das innere Paket enthält die Adresse des Anbieters überhaupt nicht.

Die Trennung ist eine Designeigenschaft, keine automatische Garantie. Wenn der Ersatz-Uplink den unterstützten Tunnel nicht aufbauen kann oder die inneren Routen nicht neu installiert werden, verliert die Anwendung ihren Pfad, obwohl ihre Adresse unverändert bleibt.

Der Anbieterwechsel hat trotzdem eine Checkliste

Die äußere Checkliste hat fünf Einträge: die Peer-Adresse oder der gepflegte Name, der Listener und jede Filterung weiter oben, die Übersetzung auf dem Pfad, die erwartete Peer-Identität und die erlaubten Einstellungen des anderen Gateways. Jeder kann für sich fehlschlagen. Halten Sie einen separaten Wiederherstellungspfad bereit, während Sie die Verbindung ändern, die die Administration trägt. Den Fernzugriff während eines Uplink-Wechsels abzuschneiden, ist ein Ausfall, den Sie selbst verursacht haben.

Prüfen Sie danach das Filialpräfix, die Route in beide Richtungen, die Schutzrichtlinie und einen echten Anwendungsfluss. Ein frisch authentifizierter Tunnel repariert keine Route, die auf das alte private Subnetz zeigt.

Adressüberschneidung mit einem anderen angebundenen Standort ist ein separates Planungsproblem. Der Anbieterwechsel erzeugt sie nicht, aber eine Migration ist meist der Zeitpunkt, an dem sie auftaucht.

Was nicht überlebt: öffentliche Quelle und Sitzungen

Eine stabile private Serveradresse ist keine stabile öffentliche Quelle. Wenn das Browsen direkt über den neuen Anbieter hinausgeht, sehen Websites die neue anbieterseitige Adresse.

Diese Adresse stabil zu halten, braucht ein bewusstes Egress-Design mit eigener Verfügbarkeit und Policy. Es kommt nicht kostenlos mit dem Tunnel.

Auch bestehende Sitzungen überstehen einen Pfadwechsel nicht. Der Tunnel kann sich in Sekunden neu aufbauen und trotzdem langlebige Verbindungen brechen, die am alten Pfad festgemacht sind. Planen Sie den Wechsel für ein Fenster, in dem Wiederverbindungen akzeptabel sind. Behaupten Sie nicht, eine Migration bleibe unsichtbar, solange nicht die konkreten Clients und ihre Timeouts getestet wurden.

Prüfen Sie den Wechsel mit vier Kontrollen

Prüfen Sie nach der Änderung vier Dinge der Reihe nach: Der Tunnel ist mit dem beabsichtigten Peer aufgebaut, die innere Route zum Filialpräfix existiert, die Richtlinie erlaubt den Anwendungsfluss, und die Anwendung antwortet. Jede hat ihren eigenen Befehl.

Auf einem Linux-Gateway decken diese drei die Mitte dieser Liste ab:

ip route get 10.55.8.20
ip xfrm policy list
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 http://10.55.8.20/health

Halten Sie Transportadressen in einem Bestand und Anwendungsadressen in einem anderen. Aktualisieren Sie nur die Einträge, die sich tatsächlich bewegt haben. Interne Abhängigkeiten neu zu nummerieren, weil sich die äußere Adresse des Tunnels geändert hat, ist vermeidbare Arbeit.