Ein lokales Subnetz an ein AWS VPN anbinden: VGW oder Transit Gateway

Ein bestehendes Site-to-Site-VPN führt 10.60.0.0/16, hinter demselben lokalen Gateway erscheint ein neues Servicenetz als 10.70.0.0/16, und jemand fragt, ob ein Proxy nötig ist. Meist nicht: Ein gerouteter Pfad kann das Präfix transportieren, aber nur wenn drei Dinge zusammenpassen, und welche drei, hängt von der AWS-Architektur ab, die Sie bereits betreiben. Ein Virtual Private Gateway hat eine Routentabellengrenze; ein Transit Gateway fügt eine zweite hinzu. Ankündigung richtig, Tabelle falsch ergibt eine Sitzung, die gesund aussieht und nichts liefert.

Kündigen Sie ein Präfix an, das das Gateway wirklich liefern kann

Das lokale Gateway braucht eine Weiterleitung in das neue Netz, bevor eine Ankündigung sinnvoll ist. 10.70.0.0/16 per BGP anzukündigen sagt AWS, wohin Pakete für diesen Bereich gehen sollen; es erzeugt nicht den lokalen Weiterleitungspfad, der den Bereich am anderen Ende erreichbar macht. Bestätigen Sie, dass das Gateway eine Route für das Präfix hat, die auf das Gerät zeigt, das es hält, und dass das Gerät konfiguriert ist, für diese Adressen zu antworten. Exportrichtlinie und akzeptierte Präfixgrenzen sind die nächste Einschränkung, denn ein Präfix, das die Sitzung herausfiltert, erreicht AWS gar nicht.

Halten Sie Aggregate und spezifischere Routen bewusst. Überlappende Pfade aus zwei Richtungen sind eine Designentscheidung, kein Detail, das man später entdeckt.

Pfad eins: die Grenze des Virtual Private Gateway

Bei einem Virtual Private Gateway beschreibt die AWS-VPN-Dokumentation zum Routing zwei Verteilungsmodi, statische Routen und BGP-Ankündigungen, und beide hängen von der Subnetz-Routentabelle ab, die die Anwendung tatsächlich nutzt. Propagierung ist bequem, wenn Sie den gesamten Bereich kontrollieren, und eine explizite Route lässt sich leichter nachvollziehen, wenn das Ziel neben dem Zielobjekt stehen soll. So oder so ist die Prüfung dieselbe: Enthält die Tabelle des konkreten Anwendungssubnetzes einen funktionierenden Pfad zum VPN-Ziel für das neue Präfix, und gewinnt er gegen etwas Spezifischeres?

Eine gesunde BGP-Sitzung beweist, dass der Kanal existiert. Sie sagt nichts darüber, ob eine bestimmte Subnetztabelle die Route übernommen hat.

Pfad zwei: das Transit Gateway fügt eine Tabelle hinzu

Ein Transit Gateway teilt diese eine Frage in zwei. Das VPC-Subnetz muss das Ziel an die Transit-Gateway-Anbindung senden, und dann muss die Routentabelle des Transit Gateway die VPN-Anbindung für dasselbe Präfix auswählen. Zuordnungs- und Propagierungsentscheidungen bestimmen, welche angebundenen Netze die Route erhalten, also kann ein Präfix vom VPN korrekt angekündigt werden und dennoch nie die VPC erreichen, deren Tabelle nie der richtigen Routentabelle zugeordnet wurde.

Der häufige Fehler ist eine Route, die in einer Tabelle existiert und in der anderen nicht, wobei jedes Team überzeugt ist, seine Seite sei richtig. Vergleicht man die beiden Architekturen, ist diese zusätzliche Grenze der ganze Unterschied: mehr Stellen zum Nachsehen und genauere Kontrolle darüber, wer die Route bekommt.

Auch die Routenpropagierung gewährt nicht jeder Anbindung das Präfix. Sie verteilt es an die Tabellen, die dafür konfiguriert sind, es zu empfangen.

Der Rückweg ist eine eigene Richtlinienentscheidung

Eingehender Datenverkehr ist nur die Hälfte des Austauschs. Das neue lokale Netz braucht eine Route zurück zu den AWS-Quellpräfixen über das richtige Gateway, und die Sicherheitsrichtlinie an beiden Enden muss dieses Paar aus Quelle und Ziel erlauben. Wenn der Tunnel einen Schutzbereich mit Traffic Selectors aushandelt, muss das neue Präfix darin liegen, sonst wird das Paket verworfen, bevor irgendeine Routentabelle befragt wird.

Adressüberlappung ist die andere Falle. Getrennte, ausdrücklich eigene Bereiche halten das einfach; überlappende Bereiche bedeuten Übersetzung oder eine Neugestaltung, und keines davon ist eine austauschbare Variante desselben Rezepts.

Testen Sie mit einer Quelle im neuen Netz und einem Ziel im Anwendungssubnetz und wiederholen Sie es dann in die andere Richtung. Ein einseitiger Test beweist eine Richtung.

Wann der Proxy wirklich die bessere Grenze ist

Ein Proxy verdient seinen Platz, wenn die Anforderung eine schmale Serviceschnittstelle ist, wenn die Anwendung diese Architektur bereits erwartet oder wenn der Netzwerkpfad das Präfix nicht ohne eine Übersetzung tragen kann, die Sie nicht wollen. Er ist nicht der Notnagel für einen Routentabelleneintrag, den niemand geprüft hat.

Entscheiden Sie in dieser Reihenfolge: lokale Weiterleitung, Ankündigung, Tabellengrenze, Rückweg-Richtlinie. Beheben Sie das erste, das scheitert, und fragen Sie erst dann, ob der geroutete Pfad überhaupt die richtige Antwort ist.