AWS Client VPN verbunden, aber EC2 läuft weiter in den Timeout

Mein Laptop zeigte verbunden. Der AWS-Client-VPN-Client zeigte seinen grünen Zustand, der Endpoint protokollierte eine Sitzung, und trotzdem konnte ich keinen MongoDB-Port auf einer EC2-Instanz in einem privaten Subnetz öffnen. Nichts war offensichtlich kaputt: Das Zertifikat war gültig, das Profil kam aus der Konsole, und der Tunnel trug Verkehr. Der Fehler lag bei mir, weil ich „verbunden“ als „autorisiert“ gelesen hatte.

Die Anmeldung beantwortet genau eine Frage: Darf diese Identität eine Sitzung aufbauen? Alles danach entscheiden getrennte Regeln, die Ihr Zertifikat nie zu sehen bekommen. Eine Sitzung, die sich authentifiziert, und ein Paket, das ankommt, sind zwei verschiedene Erfolge, und in der Lücke dazwischen leben die meisten Meldungen der Art „das VPN steht, aber der Host ist nicht erreichbar“.

Die folgenden Prüfungen sind die Reihenfolge, die ich heute verwende.

Was eine verbundene Sitzung tatsächlich beweist

Während des Handshakes prüft der Endpoint das Client-Zertifikat gegen seinen Trust Store oder leitet den Browser zu Ihrem Identity Provider um, wenn SAML konfiguriert ist. Wenn das durchgeht, erhält der Client eine Adresse aus dem Client-CIDR des Endpoints, und die Konsole zeigt eine aktive Verbindung. An keiner Stelle dieses Austauschs wird gefragt, ob Sie 10.0.4.17 auf Port 27017 erreichen dürfen.

Die Berechtigung für ein Ziel ist ein eigenes Objekt am Endpoint. Jeder Flow wird gegen die Autorisierungsregeln geprüft, und jede davon verbindet ein Ziel-CIDR mit der Gruppe, der die Regel gewährt wird. Wenn keine Regel das Ziel abdeckt, nimmt der Endpoint die Sitzung an und verwirft den Verkehr. Es gibt kein Banner, keine Reconnect-Schleife und nichts in der Client-Oberfläche, das „verweigert“ sagt.

Vergleichen Sie die Autorisierungsregel mit der Ressource, nicht mit der VPC

Listen Sie die Regeln auf und halten Sie sie neben die Adresse, die die Instanz tatsächlich hat:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

Die Ausgabe zeigt pro Regel ein Ziel-CIDR und eine Gruppen-ID. Darin verstecken sich zwei Fehler. Die Regel kann 10.0.0.0/16 autorisieren, während die Instanz in einer gepeerten VPC auf 10.1.0.0/16 liegt; die Peering-Route existiert, aber niemand hat eine Autorisierungsregel für den zweiten Bereich geschrieben. Oder die Regel verweist auf eine Verzeichnisgruppe, in der der Benutzer im Verzeichnis Mitglied ist, nicht aber in der Gruppe, die der Endpoint auswertet.

Schreiben Sie die engste Regel, die das Ziel abdeckt, und fügen Sie eine zweite nur hinzu, wenn ein zweites CIDR wirklich nötig ist. Eine breite 0.0.0.0/0-Regel aus einem Quick Start funktioniert, und genau deshalb überlebt sie bis in die Produktion und verdeckt das Modell.

Zwei Routentabellen entscheiden, ob das Paket sich bewegt

Eine Endpoint-Route ordnet ein Ziel-CIDR einem der Subnetze zu, mit denen der Endpoint verknüpft ist. Das ist die halbe Strecke. Die eigene Routentabelle des Subnetzes muss weiterhin wissen, wie das Paket weiterzuleiten ist, und das zählt in dem Moment, in dem das Ziel hinter einer Peering-Verbindung, einem Transit Gateway oder einem lokalen Bereich liegt, der über einen Site-to-Site-Tunnel erreichbar ist.

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

Suchen Sie eine Route, deren Ziel zum CIDR der Ressource passt und deren Zielobjekt ein verknüpftes Subnetz ist. Fehlt die Route, fügen Sie sie hinzu. Ist sie vorhanden und der Host bleibt stumm, liegt die Lücke auf der VPC-Seite, also vergleichen Sie mit der Routentabelle des Verknüpfungs-Subnetzes.

Eine clientseitige Einstellung zerbricht das Routing, ohne den Tunnel zu zerstören: ein Profil, das route-nopull enthält. Die Direktive sagt einem auf OpenVPN-basierenden Client, die vom Server gepushten Routen zu ignorieren, sodass die Schnittstelle nur mit der eigenen Adresse des Endpoints hochkommt und das Ziel schlicht keine Route hat. Prüfen Sie mit ip route show unter Linux oder netstat -rn unter macOS, ob eine Route über die tun-Schnittstelle existiert. Wenn nicht, entfernen Sie route-nopull aus dem exportierten Profil und verbinden Sie neu, damit die gepushten Routen angewendet werden.

Security Groups sehen Ihre Client-Adresse nicht

Das ist der Teil, bei dem ich einen ganzen Nachmittag falsch lag. Bei einem IPv4-Endpoint, der mit einem Subnetz verknüpft ist, übersetzt der Dienst die Quelladresse des Clients in die Adresse der Netzwerkschnittstelle des Endpoints in diesem Subnetz. Das Paket, das bei der Instanz ankommt, trägt nicht die Adresse, die Ihr Client angezeigt hat, also trifft eine Security-Group-Regel, die den Client-Pool erlaubt, sagen wir 172.16.0.0/22, auf gar nichts.

Erlauben Sie den Port aus der Security Group des Endpoints, die an der Schnittstelle der Verknüpfung hängt, statt aus dem Client-CIDR. Auf die Gruppe zu verweisen ist dauerhafter, als eine Adresse fest zu verdrahten, denn die Adresse der Schnittstelle können Sie nicht steuern. Network ACLs sind zustandslos, wo also eigene Einträge existieren, müssen sowohl die eingehende als auch die ausgehende Richtung den Flow zulassen.

Verbinden Sie sich zusätzlich über die private Adresse der Instanz. Eine öffentliche IP führt das Paket aus der VPC heraus und über einen anderen Pfad mit anderen Regeln wieder hinein, ein Test über die öffentliche Adresse sagt also nichts über den privaten Pfad.

Eine Isolationsreihenfolge, die beim ersten Fehler stoppt

Arbeiten Sie diese der Reihe nach durch und stoppen Sie dort, wo einer fehlschlägt. Jeder Schritt schließt eine Schicht aus, nicht alle.

1. Bestätigen Sie, welche Identität die Sitzung verwendet hat und welche Gruppe der Endpoint auswertet. Ein Zertifikat aus einem Trust Store ist nicht derselbe Principal wie eine SAML-Assertion aus dem Verzeichnis.
2. Bestätigen Sie, dass eine Autorisierungsregel das CIDR der Ressource für diese Gruppe abdeckt.
3. Bestätigen Sie, dass eine Endpoint-Route existiert und auf ein verknüpftes Subnetz zeigt, und dann, dass die Routentabelle des Subnetzes weiterreichen kann.
4. Bestätigen Sie, dass die Security Group den Port von der Endpoint-Schnittstelle erlaubt und nicht aus dem Client-Pool.
5. Testen Sie aus der VPC heraus mit einer SSM-Sitzung auf einer anderen Instanz im selben Subnetz, um ein Anwendungsproblem von einem Problem des Client-Pfads zu trennen.

Wenn die Schritte nicht entscheidend sind, greife ich auf diese Tabelle zurück:

Zwei Kontodetails erzeugen Symptome, die wie Berechtigungsfehler aussehen. Jeder Benutzer braucht ein eigenes Client-Zertifikat; wird eines auf zwei Rechnern geteilt, verdrängen sich die Sitzungen gegenseitig, und das Ergebnis ist eine Reconnect-Schleife statt einer Verweigerung. Wenn ein neuer Endpoint erstellt wird, zeigt die Konsole einen DNS-Namen, den manche Client-Versionen nur mit dem zufälligen Präfix akzeptieren, das auf der Endpoint-Seite angezeigt wird; kopieren Sie den vollständigen Namen, statt ihn nachzubauen.

Wenn Schritt fünf Sie nicht weiterbringt, holen Sie das Verbindungsprotokoll des Endpoints und lesen Sie die Autorisierungseinträge, bevor Sie etwas ändern. Das Protokoll nennt das geprüfte Ziel und die Regel, die gepasst hat oder nicht, und das reduziert die Frage mit den vier Schichten auf eine einzige Antwort.