Welche Quell-IP nutzt ein AWS-NAT-Gateway in Richtung VPN?

Sie öffnen die VPC-Konsole, weil ein Partner gefragt hat, welcher Quellbereich über das Site-to-Site-VPN ankommt. Die Seite NAT-Gateways zeigt ein öffentliches Gateway mit zugeordneter Elastic IP, und die Versuchung ist, diese Adresse zu verschicken und weiterzugehen. Sie ist die richtige Antwort für den Internetpfad und die falsche für den VPN-Pfad, und der Unterschied ist, auf welches Gateway die Routentabelle zeigt. Gehen Sie die Route durch, bevor Sie die Allowlist schreiben.

Beginnen Sie auf der Seite NAT-Gateways, nicht bei der Allowlist

Die Seite NAT-Gateways nennt Ihnen Subnetz, Typ und Elastic IP, und diese drei Felder reichen zum Anfangen. Was sie nicht nennt, ist der Weg, den der Verkehr danach nimmt. Der ergibt sich aus den Routentabellen, die am Subnetz des NAT-Gateways hängen.

Lesen Sie zuerst den Typ, denn öffentlich oder privat entscheidet, ob später ein Internet-Gateway in der Kette auftaucht. Lesen Sie dann das Subnetz, denn dort liegt die zweite Route.

Folgen Sie den beiden Übersetzungen

Sowohl öffentliche als auch private NAT-Gateways übersetzen die private IPv4-Quelle der Arbeitslast in die eigene private IPv4-Adresse des NAT-Gateways. Diese erste Übersetzung geschieht unabhängig vom Typ. Die zweite Übersetzung ist die, die man vergisst: Ein öffentliches NAT-Gateway übergibt den Verkehr an das Internet-Gateway, das die Adresse auf die zugeordnete Elastic IP abbildet.

workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> internet gateway -> Elastic IP 203.0.113.25
workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> transit or virtual private gateway -> partner sees 10.20.2.10

Auf dem privaten Pfad gibt es kein Internet-Gateway in der Kette. Wenn Verkehr über ein Transit-Gateway oder ein virtuelles privates Gateway hinausgeht, dokumentiert der Leitfaden zu NAT-Gateways die private Adresse des NAT-Gateways als Quelle, die die Gegenseite erhält. Diese Adresse sollte der Partner zulassen, nicht die Elastic IP.

Der VPN-Pfad zeigt meist die private Adresse

Für eine Arbeitslast in 10.20.1.0/24, die ein Partnerpräfix erreicht, zeigt die Routentabelle des Arbeitslast-Subnetzes auf das NAT-Gateway, und die Routentabelle des NAT-Gateway-Subnetzes zeigt auf den Pfad des privaten Gateways. Beide Hops zählen, und nur der zweite entscheidet, was der Partner sieht. Wenn das NAT-Subnetz keine Route zum VPN-Pfad hat, kommt das Paket nie an, und das ist ein anderer Fehler als eine falsche Quelladresse.

Prüfen Sie diese zweite Route, bevor Sie überhaupt über Adressen sprechen. Eine fehlende Route und eine falsch gemeldete Quelle sehen für einen Partner, der schlicht keinen Verkehr sieht, identisch aus.

Wenn eine zweite Übersetzung die Antwort ändert

AWS bietet außerdem ein explizites, passendes Eins-zu-eins-NAT-Mapping an einem Transit-Gateway-Anhang. Dieses Mapping kann die Quelle erneut übersetzen, bevor der entfernte Dienst sie sieht, und es ist nicht das Standardverhalten, das nur routet. Weil es bewusst konfiguriert werden muss, behandeln Sie es als Design-Ausnahme und nicht als etwas, das Sie versehentlich erben. Wenn sich niemand in Ihrem Team daran erinnert, es eingeschaltet zu haben, gehen Sie davon aus, dass es fehlt, bis Sie den Anhang gelesen haben.

Wenn Ihr Design es nutzt, muss die Allowlist das endgültige Mapping beschreiben und nicht die Adresse des NAT-Gateways. Dieselbe Vorsicht gilt für Verfügbarkeitspfade: Wenn mehrere Gateway-Adressen beteiligt sind, ist die erwartete Quellmenge die Vereinigung und nicht eine repräsentative Adresse. Notieren Sie, zu welcher Übersetzung welche Adresse gehört, denn eine Liste ohne Herkunft lässt sich später nicht prüfen.

Einem privaten NAT-Gateway kann man keinen Internetdienst geben, indem man es auf ein Internet-Gateway zeigt; AWS dokumentiert, dass solcher Verkehr verworfen wird. Wählen Sie den Typ anhand des vollständigen Pfads und nicht anhand des Worts VPN in der Anforderung.

Schreiben Sie den Vertrag, auf den Ihr Partner reagieren kann

Der brauchbare Vertrag hat vier Teile: die Richtung, aus der Flüsse gestartet werden, die übersetzte Identität, die der Partner sieht, die Rückroute für diese Identität und den Schutzumfang, der gilt. NAT-Gateway-Flüsse werden von der unterstützten Ursprungsseite aus gestartet, es handelt sich also nicht um einen eingehenden Port-Forwarding-Dienst zum Freilegen einer privaten Arbeitslast. Das früh laut zu sagen verhindert eine Designprüfung, in der jede Seite annahm, die andere habe begonnen.

Übersetzung erkauft Entlastung bei Adressüberlappung und eine vorhersagbare Quellrichtlinie, und sie kostet Sie die individuelle Arbeitslast-Identität in den Protokollen des Partners. Wenn die Prüfung eine Zuordnung pro Arbeitslast braucht, halten Sie diese Identität in der Anwendungsschicht, statt zu versuchen, sie aus einer übersetzten Quelladresse zurückzugewinnen.

Prüfen Sie danach beide Routentabellen nach jeder Änderung, denn ein neuer Anhang oder ein neu zugeordnetes Subnetz schreibt die Antwort still um.