Warum GRE und ESP durch ein AWS NAT-Gateway scheitern

Der Tunnel scheitert, die Sicherheitsgruppe erlaubt bereits den gesamten Verkehr, und die Schlussfolgerung lautet, dass AWS das VPN blockiert. Es blockiert nichts. Ein verwaltetes NAT-Gateway leitet eine dokumentierte Menge äußerer Protokolle weiter, und natives GRE oder natives ESP sind nicht darin, daher wird keine hinzugefügte Regel das Gateway dazu bringen, sie zu übertragen. Die Allow-Regel und die Transportfähigkeit sind zwei verschiedene Dinge, und nur eines davon können Sie ändern.

Die Regelmenge ist nicht die Protokollmenge

Eine Sicherheitsgruppe entscheidet, welcher Verkehr die Instanz verlassen darf. Das NAT-Gateway entscheidet, was es übersetzen und weiterleiten kann. Wenn die zweite Grenze greift, erzeugt eine permissive Regel genau das Symptom, das Menschen als Firewall-Problem fehldeuten: Pakete verlassen die Instanz, der Kontrollaustausch kann sogar abgeschlossen werden, und beim Peer kommt nichts an.

Die Protokollspezifikation für NAT-Gateways von AWS führt für den verwalteten Dienst TCP, UDP und ICMP auf. Das ist die gesamte unterstützte Menge. Eine Allow-Regel für ein anderes IP-Protokoll kann sie nicht erweitern, weil die Regel lange vor dem Weiterleitungspfad des Gateways ausgewertet wird.

Die Unterscheidung ist wichtig, weil beide Fehler aus Sicht des Clients identisch aussehen und völlig unterschiedliche Korrekturen haben.

PPTP zeigt, warum ein Porttest lügt

PPTP ist das klarste alte Beispiel für eine Portprüfung, die nichts beweist. Es öffnet eine TCP-Kontrollverbindung auf Port 1723 und überträgt die Tunneldaten dann über GRE, das IP-Protokoll 47 ist. Protokoll 47 ist nicht TCP-Port 47, und die beiden Nummern haben nichts miteinander zu tun, außer dass sie Ziffern teilen.

Ein Betreiber, der die Konnektivität zu 1723 testet und einen abgeschlossenen Handshake sieht, schließt daraus, dass der Pfad funktioniert. Der Datenkanal überträgt dann nie ein einziges Paket, weil das Gateway keine GRE-Unterstützung anzubieten hat. Das ist eine Auslegung der Anforderungen eines alten Protokolls, keine Empfehlung, PPTP einzusetzen, das seit Jahren veraltet ist.

Dieselbe Argumentation gilt für jedes Protokoll, dessen Kontrollkanal TCP oder UDP ist, während sein Datenpfad es nicht ist.

IPsec überlebt nur als UDP

IPsec ist der Fall, in dem die Antwort bedingt statt eines glatten Nein ist. AWS dokumentiert NAT-Traversal als die unterstützte Anordnung für IPsec durch ein NAT-Gateway. Mit ausgehandeltem NAT-T wird ESP in UDP gekapselt, und das Gateway sieht gewöhnliches UDP statt Protokoll 50.

UDP 4500 zu erlauben, bringt Endpunkte nicht dazu, NAT-Traversal zu verwenden. Es erlaubt die Pakete nur, wenn sie bereits so geformt sind. Bestätigen Sie aus der eigenen Aushandlungsausgabe des Clients, welche Kapselung gewählt wurde, und bestätigen Sie auf der Empfangsseite, dass der Peer sie akzeptiert hat. Zwei für natives ESP konfigurierte Endpunkte senden weiterhin natives ESP, egal was die Regelmenge sagt.

Ein TCP- oder UDP-basiertes VPN passt in die dokumentierte Transportmenge und kann dennoch aus Gründen des Routings, der Filterung oder der Authentifizierung scheitern. In die Menge zu passen ist notwendig, nicht ausreichend.

Prüfen Sie den Pfad, bevor Sie die Richtlinie erweitern

Prüfen Sie die tatsächliche Route des Workload-Subnetzes und die Identität seines nächsten Hops zuerst. Ein direkter öffentlicher Pfad, eine NAT-Instanz, ein verwaltetes NAT-Gateway und ein privater Pfad über ein Transit-Gateway sind vier verschiedene Designs, und nur eines davon ist der hier beschriebene verwaltete Dienst.

Halten Sie dann den angestrebten Endpunkt, die Adressfamilie, das äußere Protokoll und den Port fest, sofern das Protokoll einen hat. Verwenden Sie die Diagnose des Clients und die Flussbeobachtungen des Netzwerkeigentümers statt einer erfolgreichen Browseranfrage, die nur beweist, dass TCP und UDP funktionieren. Prüfen Sie danach die Sicherheitsgruppe, die Subnetz-ACL, die Gast-Firewall und die Dienstrichtlinie für beide Richtungen des Flusses.

Öffnen Sie nicht den gesamten Verkehr, um einen Transport auszugleichen, den der Dienst nicht übertragen kann. Die Regeländerung behebt es nicht, und sie überlebt den Vorfall.

Wenn der Transport nicht passt

Liegt das äußere Protokoll außerhalb der unterstützten Menge, ist die Lösung architektonisch: Wählen Sie einen Transport, den der Pfad tragen kann, oder verlegen Sie den Egress auf etwas, das den benötigten trägt. OpenVPN über UDP, WireGuard über UDP und TLS-basierte Tunnel passen alle in die dokumentierte Menge. Eine kundenseitig verwaltete NAT-Instanz ist die Option, wenn ein bestimmtes Protokoll durchgelassen werden muss und die Betriebskosten dafür akzeptabel sind.

Das Hosten eines eingehenden VPN-Servers ist ein separates Problem mit einer separaten Antwort. Ein NAT-Gateway bietet ausgehende Übersetzung und keine allgemeine eingehende Portweiterleitung, daher braucht ein Server dahinter seinen genehmigten öffentlichen Einstieg, der nach eigenen Bedingungen gestaltet ist.

Reihenfolge der Arbeit: Benennen Sie das äußere Protokoll, bestätigen Sie den nächsten Hop, vergleichen Sie ihn mit der dokumentierten Menge, und ändern Sie dann Architektur oder Transport. Eine andere Portnummer macht GRE nicht zu TCP, und eine weitere permissive Regel macht aus einem abgeschlossenen Kontrollaustausch keinen funktionierenden Datenkanal.