AWS Site-to-Site VPN zum NAT-Gateway: VGW versus Transit Gateway

Alle zeichnen beim ersten Mal dasselbe Diagramm: VPN in die VPC, NAT-Gateway hinaus ins Internet, fertig. AWS unterstützt diesen Weg jedoch nicht, wenn das VPN an einem virtual private gateway endet, und der Fehler ist so leise, dass Teams ihn mehr als einmal neu bauen. Das funktionierende Design braucht ein transit gateway, was das Gateway und die Routentabellen auf beiden Seiten ändert. Vergleichen Sie beide Formen, bevor Sie etwas zeichnen.

Die Topologie, die offensichtlich wirkt und nicht unterstützt wird

Die Dokumentation zum NAT-Gateway von AWS zieht eine Linie, die jeden überrascht, der bisher nur Einzel-VPC-Designs gebaut hat: Verkehr aus einer Site-to-Site-VPN-Verbindung lässt sich nicht über ein virtual private gateway zu einem NAT-Gateway routen. Der Gateway-Typ, an dem das VPN endet, entscheidet, ob überhaupt ein Übersetzungspfad existiert. Der Fehler überlebt, weil der Tunnelstatus UP ist und eine EC2-Instanz im selben Subnetz das Internet problemlos erreicht. Keine der beiden Beobachtungen prüft die defekte Richtung.

In der Praxis kommt das Paket mit einer Quelladresse aus dem lokalen Netz an und findet keinen unterstützten nächsten Hop, der es übersetzen würde. Je nach Tabellen wird es an der Ausgangsgrenze verworfen, und weil der Tunnel UP bleibt, während eine Instanz im selben Subnetz weiter ins Internet kommt, wird der Fehler als Firewallproblem vor Ort gemeldet.

Virtual private gateway versus transit gateway

Ein virtual private gateway gehört zu genau einer VPC. Es beendet das VPN, installiert Routen in die Routentabellen dieser VPC und hört dort auf. Es hat kein Attachment-Modell und kann Verkehr daher weder an eine andere VPC noch an ein gemeinsames Ausgangssegment übergeben. Diese Einzel-VPC-Reichweite ist die ganze Einschränkung, und keine Route innerhalb der VPC ändert daran etwas.

Ein transit gateway ist ein regionaler Hub, an dem das VPN, jede Spoke-VPC und eine VPC für gemeinsame Dienste als Attachments erscheinen. Es führt eigene Routentabellen, die bestimmen, welches Attachment ein gegebenes Präfix erhält.

Dieser Hub ermöglicht den zentralen Ausgang. Das VPN landet als ein Attachment, die Ausgangs-VPC als ein weiteres, und eine Routentabelle des transit gateway schickt internetgerichtete Präfixe vom ersten zum zweiten. Mit einem virtual private gateway gibt es kein zweites Attachment, an das etwas gehen könnte, weshalb sich das Design nicht nachträglich zurechtflicken lässt.

Der unterstützte Ausgangspfad, Hop für Hop

Das Referenzdesign hat fünf Hops, und jeder Pfeil ist eine Routingentscheidung, die Sie konfigurieren müssen. Der Verkehr verlässt das lokale Netz in das Site-to-Site-VPN-Attachment, die Routentabelle des transit gateway leitet ihn zum Ausgangs-VPC-Attachment weiter, wo die Subnetztabelle ihn an ein öffentliches NAT-Gateway schickt. Das NAT-Gateway übersetzt die Quelle, und das Internet-Gateway trägt das Paket hinaus.

On-premises network
  -> Site-to-Site VPN attachment on the transit gateway
  -> transit gateway route table
  -> egress VPC attachment
  -> public NAT gateway in that VPC
  -> internet gateway

Zwei Details entscheiden, ob die letzten Hops funktionieren. Das NAT-Gateway muss öffentlich sein, mit einer elastischen IP und einer Route zu einem Internet-Gateway, denn ein privates NAT-Gateway übersetzt zwischen Netzen und wird nie zum Internetausgang.

Planen Sie ein NAT-Gateway pro Availability Zone, die Sie bedienen wollen, und lassen Sie jede Subnetztabelle auf das lokale zeigen. Halten Sie die Transit-Gateway-Tabelle und die VPC-Tabellen in Ihren Notizen als getrennte Objekte, denn die eine wählt ein Attachment, die andere eine Ressource innerhalb der VPC. Eine Default-Route nur in einer von beiden lässt die halbe Strecke undefiniert und erzeugt die Teilausfälle, die am schwersten zuzuordnen sind.

Am Rückweg scheitern diese Designs

Ein NAT-Gateway ist stateful für Flows, die es bereits gesehen hat, sodass Antworten auf eine ausgehende Verbindung ohne neue eingehende Regel zurückkommen. Diese Eigenschaft veröffentlicht keinen lokalen Dienst im Internet, und sie so zu behandeln kostet ein Team einen Tag Fehlersuche an einer Verbindung, die nie zustande gekommen wäre. Für clientinitiierten Verkehr müssen vier Routen übereinstimmen: die lokale Policy, die Transit-Gateway-Tabelle, die Ausgangs-Subnetztabelle und die NAT-Subnetztabelle. Fehlt die letzte, verlässt die Anfrage das Gebäude, während die Antwort in AWS stirbt.

Prüfen Sie mit einem echten Client hinter dem VPN und sehen Sie nach, welche öffentliche Quelladresse er zeigt. Ist es die elastische IP des NAT-Gateway, findet Übersetzung statt; ist es etwas anderes, messen Sie einen anderen Ausgang.

Die asymmetrische Variante dieses Fehlers lohnt sich früh zu erkennen. Wenn die NAT-Subnetztabelle einer Availability Zone die Rückroute zum Client-Präfix hat und eine andere nicht, gelingen oder scheitern neue Verbindungen je nach Zone, in der der Flow landet, und das Muster wird fälschlich als unzuverlässiges Internet gelesen. Vergleichen Sie die Subnetztabellen jeder bedienten Zone, statt die zu reparieren, in der das Ticket aufkam, denn die fehlende Route ist der ganze Fehler, und auf der Gegenseite muss sich nichts ändern.

Wann ein expliziter Proxy das bessere Design ist

Ein HTTP-Proxy auf einer Instanz in der Ausgangs-VPC ist eine legitime Alternative und oft die günstigere. Clients werden darauf konfiguriert, der Proxy öffnet seine eigene Verbindung nach außen, und der Rückweg ist sein Problem statt eines symmetrischen Routingrätsels. Für wenige Anwendungen entfällt damit der größte Teil der Transit-Gateway-Arbeit. Er liefert außerdem Logging pro Benutzer, das ein NAT-Gateway nicht erzeugen kann.

Transparent ist er aber nicht. Alles, was Proxy-Einstellungen ignoriert, und jedes Protokoll, das nicht HTTP ist, folgt diesem Weg nicht.

Die Entscheidung hängt davon ab, was Ihre Anwendungen tatsächlich sprechen und wie viel Identität Sie in den Logs brauchen. Wo sie HTTP sprechen, verdient der Proxy seinen Platz; wo Sie allgemeinen Ausgang für beliebige Protokolle brauchen, ist das Transit-Gateway-Design das von AWS unterstützte. Das vorab zu entscheiden ist billiger, als es nach dem Bau der Routentabellen zu entdecken.