BGP-Ankündigungen des VGW gegenüber der VPC-Routentabelle: Was ändert was

Ein fehlendes Präfix in einer VPC-Subnetz-Routentabelle und ein fehlendes Präfix auf dem Router des Kunden sind zwei verschiedene Fehler, und nur einer davon wird innerhalb der AWS-Routentabellen behoben. Das virtuelle private Gateway kündigt die CIDR-Blöcke an, die seiner VPC zugeordnet sind; die Subnetz-Routentabelle entscheidet, wohin eine Arbeitslast eine Antwort sendet. Das zweite als Mittel zur Änderung des ersten zu behandeln ist die häufigste falsche Abzweigung in dieser Diagnose. Führen Sie die folgenden Prüfungen der Reihe nach aus und halten Sie die beiden Richtungen getrennt.

Benennen Sie den Anhang, bevor Sie irgendeine Tabelle lesen

Ein Site-to-Site-VPN endet entweder an einem virtuellen privaten Gateway oder an einem Transit-Gateway, und die Ressourcen-IDs entscheiden, welches Routingmodell gilt. Lesen Sie sie zuerst: aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[].{Tunnels:VgwTelemetry,Gateway:GatewayId,Transit:TransitGatewayId}'. Die Antwort sagt Ihnen, ob die nächste zu prüfende Tabelle eine VPC-Routentabelle oder eine Routentabelle des Transit-Gateways ist.

Wenn das VPN an ein Transit-Gateway angebunden ist, hören Sie auf, die VPC-Routentabelle als Steuerungsebene zu behandeln. Dort verweist die VPC-Tabelle auf den Gateway-Anhang, und Assoziierung und Propagierung finden in der Routentabelle des Transit-Gateways statt. Das Vermischen beider Sichten führt zu sicheren Schlussfolgerungen über das falsche Objekt.

Die Richtung von AWS zum Büro ist eine Ankündigung

Bei einem VGW-Anhang kündigt das Gateway die seiner VPC zugeordneten CIDR-Blöcke über BGP an das Kundengateway an. Das Hinzufügen einer einzelnen Subnetzroute oder das Richten einer Route auf eine gepeerte VPC oder ein Gerät fügt kein weiteres zugeordnetes CIDR hinzu und erscheint nicht in dieser Ankündigung. Wenn im Büro ein Präfix fehlt, vergleichen Sie die Liste der empfangenen Routen mit den VPC-Zuordnungen, bevor Sie eine Routentabelle bearbeiten.

Die einfache Regel hat Ausnahmen, halten Sie sie daher in ihrem Geltungsbereich. Eine VPN-CloudHub-Konfiguration kann Standortpräfixe zwischen Kundengateways erneut ankündigen, und ein Transit-Gateway folgt seinen eigenen Propagierungsregeln. Die Aussage, ein VGW kündige nur seine eigene VPC an, ist eine nützliche Voreinstellung, kein Gesetz, das jede Topologie abdeckt, auf die Sie treffen.

Die Richtung vom Büro zu AWS ist Propagierung plus Auswahl

In der Gegenrichtung lernt das VGW das Präfix des Büros, aber das allein bewegt keine Arbeitslast. Die Subnetz-Routentabelle muss entweder die Propagierung für den Anhang aktiviert haben oder eine statische Route zum selben Ziel enthalten. Wenn beides für ein Präfix existiert, gewinnt die statische Route, und die Suche nach dem längsten Präfix läuft vor beiden.

Lesen Sie den Ursprung, statt ihn anzunehmen: aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 --query 'RouteTables[].Routes'. Ein Eintrag mit dem Ursprung EnableVgwRoutePropagation kam von BGP; ein Eintrag mit dem Ursprung CreateRoute wurde von einem Menschen eingetragen und gewinnt weiter, bis jemand ihn löscht.

Ein Runbook, das die beiden Richtungen getrennt hält

Notieren Sie vier Fakten auf der AWS-Seite, bevor Sie etwas ändern: den Anhangtyp, die zugeordneten VPC-CIDRs, den Ursprung der Subnetzroute für das betreffende Präfix sowie den Tunnel- und BGP-Zustand. Derselbe describe-Aufruf liefert VgwTelemetry mit einer Anzahl akzeptierter Routen pro Tunnel, was Ihnen sagt, ob AWS überhaupt Routen akzeptiert hat. Vergleichen Sie das dann mit dem, was das Kundengerät tatsächlich installiert hat. Ein Präfix, das in BGP vorhanden, in der Weiterleitungstabelle aber nicht vorhanden ist, ist ein lokales Import- oder Best-Path-Problem, kein AWS-Routentabellenproblem.

Wenn der Subnetztabelle das Präfix gänzlich fehlt, aktivieren Sie die Propagierung oder fügen Sie eine statische Route hinzu, und lesen Sie dann dieselbe Abfrage nach dem Propagierungsintervall erneut, statt anzunehmen, die Änderung sei sofort wirksam. Wenn das Präfix existiert und der Verkehr trotzdem scheitert, lassen Sie die Steuerungsebene in Ruhe und wechseln Sie zum Datenpfad.

Was Sie dort nicht ändern sollten

Schalten Sie die Propagierung nicht auf unbeteiligten Routentabellen um, um ein fehlendes Präfix zu beheben, und fügen Sie keine Standardroute hinzu, um ein einzelnes fehlendes CIDR zu überdecken. Beide Änderungen vergrößern die Reichweite der Auswirkung und erschweren die nächste Diagnose. Beschränken Sie die Änderung auf die Tabelle, die das betreffende Arbeitslast-Subnetz bedient.

Der Datenpfad ist von all dem getrennt. Sicherheitsgruppen sind zustandsbehaftet, Netzwerk-ACLs nicht, und eine Host-Firewall oder ein asymmetrischer Rückweg kann Verkehr verwerfen, den das Routing korrekt zugestellt hat. Eine angekündigte Aggregat-Route autorisiert außerdem nicht jeden Dienst darin, beschränken Sie den Zugriff daher an der Richtliniengrenze, statt sich darauf zu verlassen, ob eine Adresse zufällig in einer BGP-Ankündigung erscheint.

Speichern Sie das Vorher und Nachher jeder Routentabellen-Abfrage im Änderungsprotokoll. Wenn die Änderung die Lage verschlechtert, stellen Sie die früheren Routen wieder her und bestätigen Sie das mit derselben Abfrage, denn ein Rollback, den Sie nicht überprüfen können, ist nur eine Vermutung.