Warum EC2 Ihren AWS Client VPN-Laptop nicht erreicht
Client VPN übersetzt IPv4-Client-Quellen in die Endpoint-Schnittstelle. Deshalb funktioniert die Antwort, aber eine neue Verbindung von EC2 nicht.
Ein Laptop, der über AWS Client VPN verbunden ist, erreicht eine EC2-Anwendung ohne Probleme. Dann versuchen Sie das Gegenteil, von EC2 zu der Adresse, die dem Client zugewiesen wurde, und die Verbindung hängt oder wird abgelehnt. Diese Asymmetrie ist selten eine fehlende Sicherheitsgruppenregel. An einem Client VPN-Endpoint, der mit VPC-Subnetzen verknüpft ist, übersetzt AWS IPv4-Client-Quellen in die Netzwerkschnittstelle des Endpoints, sodass es keine eingehende VPC-Adresse gibt, die Ihren Laptop repräsentiert.
Beginnen Sie mit dem, was der Mitschnitt zeigt
Machen Sie einen Mitschnitt auf dem EC2-Host, während der Client sich verbindet, und lesen Sie die Quelladresse, die die Anwendung tatsächlich sieht. Wenn es die Endpoint-Schnittstelle auf der VPC-Seite und nicht eine Adresse aus dem Client-Pool ist, ist die Übersetzung bestätigt, bevor Sie eine einzige Regel ändern.
Der Client-Pool ist ein Zuteilungsbereich, kein Subnetz mit einer Rückroute. An dieser Unterscheidung gehen die meisten dieser Untersuchungen schief.
Die Übersetzung, die die Asymmetrie erklärt
Drei Flüsse werden miteinander verwechselt, und nur einer davon ist der, den man testet.
| Flow | Started by | What the VPC sees | Outcome |
|---|---|---|---|
| Client to EC2 service | The client | A translated source at the endpoint interface | Works, with a stateful reply |
| EC2 host to client pool address | The EC2 host | A destination with no route and no translation state | No usable path |
| Client to client | A client, when the feature is configured | Traffic mediated by the endpoint | Works only with that feature and its authorisation |
Die Beschreibung der Client VPN-Komponenten führt aus, dass IPv4-Client-Quellen in die Endpoint-Schnittstelle übersetzt werden, was ausreicht, um zu sehen, warum die mittlere Zeile nichts zum Abgleichen hat.
Eine neue Verbindung braucht eine Route, einen Schritt zur Adressauflösung und eine Autorisierungsentscheidung. Übersetzungszustand aus der Sitzung eines anderen liefert nichts davon.
Warum eine Antwort keine neue Verbindung ist
Eine TCP-Antwort wird gegen einen bestehenden Eintrag abgeglichen, deshalb funktioniert der Rückweg ganz ohne eingehende Regel. Ein frisches SYN vom EC2-Host hat keinen Eintrag zum Abgleichen und wird daher zu einem gewöhnlichen ausgehenden Versuch zu einem Ziel, das die VPC nicht zu erreichen weiß.
Deshalb ist es auch irreführend, dies als Verkehr zu beschreiben, der nur in eine Richtung fließt. Rückverkehr fließt in diesen Sitzungen fortlaufend. Die Initiierung ist der Teil ohne Pfad.
Was eine Sitzung, die funktionieren sollte, trotzdem bricht
Sicherheitsgruppen, Netzwerk-ACLs und die eigene Firewall des Laptops sind alle wichtig für die Verbindungen, die gelingen sollen. Ein fehlgeschlagener Ping sagt am wenigsten, weil die ICMP-Richtlinie oft von der TCP-Richtlinie getrennt ist, die Sie interessiert.
Schreiben Sie diese Regeln gegen die übersetzte Quelle, nicht die Client-Adresse. Regeln, die an der Adresse hängen, die nie auf dem Draht erscheint, sind der häufigste selbst verursachte Fehler in diesem Design.
Wenn der VPC die Konversation wirklich beginnen muss
Wenn ein Dienst eine Workstation benachrichtigen muss, kehren Sie die Richtung um und lassen Sie den Client einen dauerhaften ausgehenden Kanal halten, auf dem der Dienst antwortet. Wenn ein ganzes entferntes Netzwerk von der VPC aus erreichbar sein muss, wählen Sie eine Architektur, die ihre Präfixe und Zugriffsrichtlinie veröffentlicht, statt anzunehmen, Client VPN tue das bereits. Client-zu-Client-Zugriff ist ein dritter, engerer Fall mit eigenen Routen- und Autorisierungsobjekten. Nichts davon ist ein Kontrollkästchen am bestehenden Endpoint.
Halten Sie auch den Umfang der IPv4-Erklärung ehrlich. Die aktuelle AWS-Dokumentation trennt IPv6, wo diese Übersetzung nicht greift, und andere Anbindungsmodelle, die anders routen.
Testen Sie in drei gekennzeichneten Schritten: Der Client öffnet eine erlaubte Sitzung, der VPC-Dienst antwortet auf diese Sitzung, und ein VPC-Host öffnet eine neue Sitzung zum Client. Dass die ersten beiden gelingen und die dritte scheitert, ist die erwartete Form dieses Designs und kein Fehler, den man mit Firewall-Regeln jagen sollte.