Eine EC2 Elastic IP ist nicht die private VPN-Adresse der Instanz

Die Instanz hat eine private Adresse, die Elastic IP ist ihr zugeordnet, und eine Route für dieses öffentliche /32 wird dem VPN hinzugefügt, in der Hoffnung, dass beide dasselbe werden. Das werden sie nicht. Eine Elastic IP ist eine Übersetzung, die außerhalb des Gasts vom Internet-Gateway an Verkehr vorgenommen wird, der den Internetpfad nimmt. Das Betriebssystem des Gasts sieht diese Adresse nie auf einer Schnittstelle konfiguriert. Sie einer Tunnel-Schnittstelle zuzuweisen reproduziert die vorgelagerte Übersetzung nicht und erzeugt eine zweite, widersprüchliche Identität für dieselbe Maschine.

Zwei Adressen, eine Instanz

Die Netzwerkschnittstelle der Instanz trägt eine private Adresse innerhalb der VPC, und das ist die Adresse, die der Gast kennt. Die Elastic IP ist derselben Schnittstelle zugeordnet, lebt aber auf der öffentlichen Seite der Abbildung.

Alles, was die Instanz über das Internet erreicht, kommt auf die private Adresse übersetzt an. Alles, was die Instanz ins Internet sendet, geht mit der Elastic IP als Quelle hinaus, wiederum wegen dieser Übersetzung.

Innerhalb des Gasts existiert eine Adresse. Außerhalb existieren zwei. Diese Asymmetrie erklärt den größten Teil der Verwirrung in diesem Bereich. Der Gast kann nicht konfigurieren, was das Gateway übersetzt. Er kann nur auf der Adresse antworten, die er tatsächlich hält.

Was das Internet-Gateway tatsächlich tut

Die Dokumentation von AWS zum Internet-Gateway beschreibt die Anordnung: Die Instanz kennt ihre private IPv4-Adresse, und das Gateway stellt die entsprechende Übersetzung auf eine öffentliche IPv4- oder Elastic IP für Verkehr auf dem Internetpfad bereit.

Das ist Netzwerkadressübersetzung, kein Alias. Die Abbildung wird vom Gateway gepflegt, ist an die Zuordnung gebunden und gilt nur für Pakete, die es passieren. Entfernt man die Zuordnung, verschwindet die öffentliche Identität, ohne dass der Gast etwas bemerkt.

Deshalb wird ein privates VPN-Paket, das an das öffentliche /32 adressiert ist, nicht als privates Paket an die lokale Adresse des Gasts uminterpretiert. Das Paket folgt der Route, zu der es passt, die es zum Internet-Gateway schickt, und das Verhalten des Gateways hängt davon ab, ob der Pfad in beide Richtungen erlaubt ist.

Warum der Trick mit der Tunnel-Schnittstelle scheitert

Die Elastic IP einer Tunnel-Schnittstelle zuzuweisen verlangt vom Gast, eine öffentliche Adresse als lokal zu behandeln. Nun beanspruchen zwei Dinge dieselbe Adresse: die Übersetzung des Gateways auf dem Internetpfad und die lokale Schnittstelle im Tunnel. Für den Rückverkehr gibt es keine eindeutige Antwort, welche gilt.

Selbst wenn es zu funktionieren scheint, hat das Design die eigentliche Frage verborgen. Clients erreichen entweder die private Adresse durch den Tunnel oder den öffentlichen Endpunkt über das Internet, und die beiden Pfade haben unterschiedliche Sicherheitsgruppen, unterschiedliche Protokollierung und unterschiedliche Fehlermodi.

Die Adresse war nie das Problem. Die Pfadauswahl war es.

Drei Ziele, drei Designs

Wenn das Ziel ein öffentlicher VPN-Endpunkt ist, ist die Elastic IP das richtige Werkzeug: entfernte Peers verbinden sich über das Internet damit, und der verschlüsselte Transport endet auf der Instanz. Der innere Anwendungsverkehr nutzt dann die private Adresse.

Wenn das Ziel privater Zugriff auf die Anwendung ist, ist das Ziel die private Adresse oder ein privater DNS-Name, der darauf auflöst, und VPN-Route, Sicherheitsgruppe und Rückweg müssen alle übereinstimmen. Die Elastic IP kommt in diesem Design überhaupt nicht vor.

Wenn das Ziel eine stabile öffentliche Egress-Identität für VPN-Nutzer ist, ist das ein NAT-Design auf der Egress-Seite, keine Adresse am Tunnel des Clients. Drei Ziele, die ähnlich klingen, ergeben drei verschiedene Diagramme, und nur eines davon beinhaltet, eine Elastic IP an einer neuen Stelle zu platzieren.

Prüfen Sie den gewählten Pfad

Bestätigen Sie für privaten Zugriff, dass die VPN-Route das private Präfix abdeckt, die VPC-Routentabelle den Verkehr zum Tunnel zurückführt, die Sicherheitsgruppe die Quelle des Clients zulässt und die Firewall des Clients die Antwort zulässt. Testen Sie dann eine echte Anfrage statt eines Ping.

Bestätigen Sie für öffentlichen Zugriff den Internet-Egress des Clients, das Routing des öffentlichen Einstiegs und dessen Sicherheitsrichtlinie. Ob ein VPN-Client einen öffentlichen Endpunkt durch den Tunnel erreichen kann, hängt von den Egress- und Firewall-Regeln des Tunnels ab, nicht von der Elastic-IP-Zuordnung.

Wenn ein öffentlicher Hostname von beiden Seiten aus funktionieren muss, verwenden Sie ein DNS-Design, das für VPN-Clients mit der privaten und für alle anderen mit der öffentlichen Adresse antwortet, und halten Sie das Zertifikat für den Namen statt für die Adresse gültig. Reihenfolge der Arbeit: Ziel benennen, die dazugehörige Adresse wählen, dann Routen, Richtlinie und eine Anfrage prüfen.