Ein Standort-zu-Standort-VPN für mehrere VPCs am AWS Transit Gateway

Zwei VPCs brauchen in diesem Quartal das Büronetz, und beim zweiten Tunnel bricht die Schätzung. AWS Transit Gateway kann als gemeinsamer Routing-Hub dienen: Das VPN wird einmal angehängt, und jede VPC hängt am selben Hub. Das lokale Netz erreicht dann jede angehängte VPC über eine einzige Verbindung. Das ändert, wer die Routing-Entscheidung besitzt, und genau diesen Teil bekommen die meisten Entwürfe falsch.

Der VPN-Anhang und die VPC-Anhänge sind getrennte Objekte am selben Gateway, deshalb müssen die Routing-Beziehungen danach aufgebaut werden.

On-premises network <-> Site-to-Site VPN <-> Transit Gateway
                                            |- VPC A
                                            |- VPC B

Warum Peering nicht die Abkürzung ist, auf die man hofft

Die verlockende Alternative ist, das VPN auf VPC A zu beenden und VPC B per Peering daran zu hängen. Gewöhnliches VPC-Peering bietet keinen Transit von Rand zu Rand über die VPN-Verbindung von A. Ein Peer erreicht die Adressen, die das Peering selbst bereitstellt, und ein VPN-Rand gehört nicht dazu. Transit gibt ein Hub; Peering gibt ein Paar.

Diese Einschränkung ist eine Eigenschaft des Peerings, kein Kontingent, das man erhöhen kann.

Zuordnung und Weitergabe leisten unterschiedliche Arbeit

Innerhalb des Transit Gateways wählt die Zuordnung die Routentabelle, mit der Verkehr nachgeschlagen wird, der von einem Anhang kommt. Die Weitergabe entscheidet, welche Tabellen die gelernten oder verbundenen Präfixe eines Anhangs erhalten. Ein einzelner Anhang kann einer Tabelle zugeordnet sein und zugleich in mehrere weitergegeben werden. Beides zu verwechseln ist der Weg, auf dem ein Entwurf bei einer Erreichbarkeit landet, die niemand geplant hat.

Ein vollständig verbundener kleiner Hub ist der leichte Fall.

Stecken Sie jeden Anhang in eine Tabelle, und das VPN samt beiden VPC-Präfixen löst sich sauber auf. Das erlaubt zugleich VPC-zu-VPC-Erreichbarkeit, die die Organisation vielleicht nie beabsichtigt hat, weil eine gemeinsame Tabelle keinen Begriff von einem Spoke kennt.

Workload-Routen wohnen woanders

Jedes Workload-Subnetz braucht weiterhin seine eigene Route zum Transit Gateway für die vorgesehenen lokalen Präfixe. Diese VPC-Routentabellen sind getrennte Objekte von den eigenen Tabellen des Transit Gateways. Fügen Sie die nötigen Präfixe hinzu und erhalten Sie bestehende Routen, statt jedes Ziel durch ein neues Default zu ersetzen. Eine Subnetz-Route kündigt dem Kundengerät außerdem nichts an.

Wählen Sie dynamisches oder statisches Routing bewusst; Peering liefert keines von beiden.

Spokes isolieren, ohne lokalen Zugang zu verlieren

Wenn A und B beide das Büro erreichen dürfen, aber nicht zueinander routen sollen, teilen Sie die Tabellen. Die zugeordnete Tabelle des VPN-Anhangs enthält die VPC-Präfixe. Die zugeordnete Tabelle der VPC-Anhänge enthält die lokalen Präfixe, ohne eine Route, die A mit B verbindet. Die Weitergabe erzeugt diese Beziehung, sodass Sie nie jede Standardzuordnung annehmen müssen.

Das ist Routing-Isolation und keine Autorisierung auf Anwendungsebene.

Sicherheitsgruppen, Netzwerk-ACLs, Host-Firewalls und die eigenen Berechtigungen jedes Dienstes entscheiden weiterhin, welcher Verkehr zugelassen wird. Wenn eine Inspektion nötig ist, entwerfen Sie ihren unterstützten Pfad ausdrücklich, statt anzunehmen, der Hub erledige sie.

Was der Hub nicht repariert

Adresspläne müssen weiterhin überlappungsfrei sein, weil der Hub nicht zulässt, dass ein Präfix zwei Workloads bezeichnet. Jeder VPC-Anhang braucht die Availability-Zone-Abdeckung, die seine Workloads erwarten. Mit BGP müssen die Routen des Kundengeräts zurück zu jedem erforderlichen Präfix zum Entwurf und dessen Importrichtlinie passen. Eine fehlende Ankündigung sieht genau wie ein defekter Tunnel aus.

Die VPN-Verbindung und das Transit Gateway sind jetzt gemeinsame Infrastruktur.

Planen Sie Tunnel-Redundanz, Gerätekapazität, Überwachung und Wartung rund um alle abhängigen VPCs, statt jede als unabhängig verbunden zu behandeln.

Die Migration von einem bestehenden Virtual Private Gateway verdient denselben ausdrücklichen Plan. Bauen Sie die Anhänge und Richtlinien, verschieben Sie einen kontrollierten Workload-Pfad und bestätigen Sie die erlaubten und verweigerten Beziehungen, bevor Sie den alten Pfad außer Betrieb nehmen. Zentralisierung hilft, wenn sie dem Netzwerkteam einen Ort gibt, um gemeinsame Konnektivität zu verwalten, und schadet, wenn sie verbirgt, wer wen erreichen darf, hinter einer einzigen großen Tabelle.