Cloud-VPN braucht BGP: Warum andere Routing-Protokolle scheitern

Die IPsec-Sicherheitsassoziation steht, die Tunnelzähler laufen, und der Verkehr zum Cloud-Präfix verschwindet. Der Betreiber versucht dann, OSPF auf dem Kundenrouter zu aktivieren, in der Erwartung, dass sich der Nachbar bildet, und nichts passiert. Der Tunnel war nie das fehlende Teil: Ein verwaltetes Cloud-VPN stellt einen definierten Routing-Vertrag bereit, und auf den großen Plattformen ist dieser Vertrag BGP. Solange keine Sitzung besteht und kein Präfix akzeptiert wird, ist der Tunnel nur ein verschlüsselter Pfad ohne Ziele dahinter.

Der Tunnel steht und die Route fehlt

Dass Phase 1 und Phase 2 abgeschlossen werden, beweist, dass sich die Peers über den Schutz einig sind, nicht dass eine Seite weiß, wohin der Verkehr gehen soll. Das sind getrennte Zustandsmaschinen mit getrennten Fehlermodi.

Stellen Sie drei Fragen in dieser Reihenfolge: Wurde das Präfix angekündigt, wurde es vom Peer akzeptiert, und wurde es für die Weiterleitung installiert? Ein Präfix, das angekündigt und gefiltert wurde, ist ein Richtlinienproblem. Ein Präfix, das nie angekündigt wurde, ist ein Sitzungs- oder Konfigurationsproblem. Ein Präfix, das akzeptiert, aber nicht installiert wurde, ist ein Routenauswahlproblem, und jede Antwort zeigt auf einen anderen Teil der Konfiguration.

Was der Anbieter Ihnen tatsächlich gibt

Ein verwaltetes VPN-Gateway ist kein uneingeschränkter Router. Der Anbieter gibt Ihnen ein Gateway mit unterstützten Peer-Adressen, einer Einstellung für das autonome System, Präfixgrenzen und einem definierten Fehlerverhalten. Diese Oberfläche ist das Produkt.

Google Cloud dokumentiert dynamisches BGP-Routing für HA VPN, wobei Cloud Router Peer-Routen lernt und geeignete benutzerdefinierte dynamische Routen an das VPC liefert. AWS Site-to-Site VPN dokumentiert eine Wahl zwischen statischem und dynamischem Routing und beschreibt BGP-Liveness-Prüfungen als nützlich für Tunnel-Failover, während auch Health-Checks für Geräte ohne BGP unterstützt werden. Das Verhalten einer Plattform sollte nicht aus dem Produktnamen der anderen abgeleitet werden.

Die praktische Konsequenz ist, dass Sie zuerst den verwalteten Modus wählen und dann die unterstützten Parameter lesen. Ein Design, das einen Adjacency-Typ annimmt, den der Dienst nicht anbietet, ist kein Konfigurationsproblem, das auf dem Kundenrouter zu lösen wäre.

Tunnelschutz und Erreichbarkeit sind getrennte Aufgaben

IPsec schützt den Verkehr, der für den Tunnel ausgewählt ist. BGP liefert die Erreichbarkeitsinformationen, die ein Präfix geeignet machen. Ein funktionierender Tunnel beweist nicht, dass das erwartete Präfix angekündigt, akzeptiert oder installiert wurde.

Stellen Sie sich eine Filiale vor, die 10.42.0.0/16 über zwei geeignete Tunnelpfade ankündigt. Entfernen Sie einen nutzbaren Pfad, und die Routenwahl kann sich ändern, ohne dass jemand die Route jeder Arbeitslast bearbeitet. Erkennung, Routenwahl und Anwendungswiederherstellung sind nicht sofort und nicht über alle Bereitstellungen hinweg gleich, daher muss der Failover-Test die gesamte Abfolge beobachten und nicht das erste Paket, das durchkommt.

Wenn ein Cloud-Präfix nicht erreichbar ist, prüfen Sie den Sitzungszustand und die gelernten Routen, bevor Sie die Kryptografie anfassen. Eine SA, die steht und keine Route dahinter hat, ist die häufigste Form dieses Symptoms.

Wo OSPF-Annahmen brechen

OSPF, IS-IS oder ein anderes Protokoll in einem IPsec-Tunnel ist auf einer selbst verwalteten Appliance durchaus möglich, wo Sie beide Enden und das Weiterleitungsdesign besitzen. Diese Tatsache sagt nichts über einen verwalteten Dienst aus, der nur BGP als dynamischen Routingmodus anbietet.

Wenn ein vorgeschlagenes Design eine Adjacency benötigt, die der Dienst nicht unterstützt, ändern Sie die Architektur bewusst. Zu den Optionen gehören eine selbst verwaltete Appliance im VPC, statisches Routing, wo der Dienst es unterstützt, oder ein anderes Konnektivitätsprodukt. Das Protokoll nur auf dem Kundenrouter zu konfigurieren, kann keinen cloudseitigen Peer hinzufügen, der nicht existiert, und wird das Präfix nicht erscheinen lassen.

Übertragen Sie nicht die Antwort eines Anbieters auf das Gateway eines anderen. Dieselben Wörter, etwa dynamisches Routing oder Tunnel-Failover, können unterschiedliche Mechanismen und unterschiedliche Grenzen beschreiben.

Lesen Sie die Dienstanforderung und entwerfen Sie dann

Schreiben Sie vor der ersten Konfigurationszeile die Nachbaradressen, die Nummern der autonomen Systeme, die Präfixe, die Sie ankündigen und akzeptieren werden, die Routengrenzen und das erwartete Verhalten bei einem Tunnelausfall auf. Diese fünf Punkte sind der Vertrag, gegen den Sie entwerfen.

Prüfen Sie dann in derselben Reihenfolge: Sitzung aufgebaut, Präfix empfangen, Route in der Routentabelle des VPC vorhanden und ein echter Fluss zu einer Dienstadresse. Wiederholen Sie das nach einem erzwungenen Failover, denn eine Sitzung, die sich neu aufbaut, kann mit einem anderen Routensatz zurückkommen. Wenn das Design von Konvergenz unter einer Sekunde abhängt, messen Sie sie, statt sie anzunehmen.

Bewahren Sie den Dienstvertrag zusammen mit dem Änderungsdatensatz auf. Wenn später jemand fragt, warum der Tunnel kein OSPF fahren kann, ist die Antwort eine Produktgrenze und keine Protokollbeschränkung, und der Datensatz sollte das sagen.