AWS Client VPN verbunden, aber kein Internetzugriff: Routen prüfen

Sie sind mit dem AWS Client VPN-Endpoint verbunden, das private Subnetz antwortet, und jede öffentliche Seite läuft trotzdem in einen Timeout. Diese Kombination engt das Problem auf eines von drei Objekten auf der verwalteten Seite ein: die Route, die der Client installiert, die Route des Endpoints zusammen mit ihrer Autorisierungsregel oder den nächsten Hop des zugeordneten Subnetzes. Ich prüfe sie in dieser Reihenfolge, weil jeder Fehler aus Client-Sicht anders aussieht. Dieser Leitfaden behandelt den VPC-zugeordneten verwalteten Endpoint, nicht einen OpenVPN-Server auf einer EC2-Instanz und auch keine Cloud WAN- oder Transit Gateway-Anbindung.

Beginnen Sie damit, was der Client tatsächlich routet

Ein verbundener Zustand beweist die TLS-Session und die CIDR-Zuweisung an den Client, mehr nicht. Fragen Sie das Betriebssystem, wohin eine öffentliche Adresse bei aktivem Tunnel gehen würde. Unter Linux sollte ip route get 1.1.1.1 das Tunnel-Interface nennen; unter macOS zeigt netstat -rn -f inet | head -5 den Standardeintrag; unter Windows gibt Find-NetRoute -RemoteIPAddress 1.1.1.1 das gewählte Interface und den nächsten Hop aus.

Lesen Sie dann das Split-Tunnel-Flag, denn es entscheidet, ob die veröffentlichten Routen des Endpoints die einzigen Ziele sind, die der Client in den Tunnel schickt:

aws ec2 describe-client-vpn-endpoints \
  --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 \
  --query 'ClientVpnEndpoints[0].SplitTunnel'

Ist SplitTunnel true, nutzt ein öffentliches Ziel den Tunnel nur, wenn der Endpoint eine Route veröffentlicht, die es abdeckt, sodass ein fehlendes 0.0.0.0/0 diesen Verkehr auf dem lokalen Interface belässt. Ist es false, fängt der Client den Verkehr ab, aber der Endpoint muss ihn weiterhin routen und autorisieren; sonst betreten Pakete den Tunnel und bleiben dort stehen. Verbinden Sie den Client nach dem Ändern einer der beiden Einstellungen neu, denn Routen und DNS-Server werden beim Verbindungsaufbau ausgeliefert, und ein laufender Client kann seinen alten Satz behalten.

Lesen Sie die Endpoint-Route und die Autorisierungsregel getrennt

Das sind zwei Objekte, und das Erstellen des einen erzeugt nicht das andere. Listen Sie die Endpoint-Routen auf und suchen Sie eine Standardroute, deren Ziel ein zugeordnetes Subnetz ist:

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

Jede Route hat genau ein Ziel-Subnetz, also brauchen drei Zuordnungen jeweils eine passende Standardroute. AWS dokumentiert diese Abdeckungsanforderung, und das praktische Symptom einer Lücke ist ein Benutzer, der aus einem Subnetz arbeitet und aus einem anderen hängen bleibt, was wie ein sporadischer Fehler statt wie eine fehlende Route wirkt. Die offizielle Client VPN-Szenariodokumentation beschreibt die Public-Subnetz-Anordnung, zu der diese Routen gehören.

Die Autorisierung ist das zweite Objekt. Wenn keine Regel das öffentliche Ziel abdeckt, trägt der Tunnel das Paket, und der Dienst verwirft es, sodass private Ressourcen weiter funktionieren, das Internet aber nicht:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

Eine Regel für das VPC-CIDR sagt nichts über 0.0.0.0/0. Die fehlenden Teile für einen vollständigen Tunnel zu ergänzen bedeutet eine Route pro zugeordnetem Subnetz plus eine Autorisierungsregel, die Sie später prüfen können:

aws ec2 create-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 create-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all \
  --description "internet egress for full tunnel"

--access-all gewährt das Ziel jedem Client des Endpoints, halten Sie es also nur, solange der Tunnel vollständig sein soll; eine an eine Verzeichnisgruppe gebundene Regel ist vorzuziehen, wenn Sie Gruppen zum Binden haben.

Verfolgen Sie das Paket aus dem zugeordneten Subnetz hinaus

Die Endpoint-Route entscheidet, dass AWS das Paket an dieses Subnetz übergibt. Sie entscheidet nicht über den nächsten Hop danach, der in der eigenen VPC-Routentabelle des Subnetzes liegt:

aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0a1b2c3d4e5f67890 \
  --query 'RouteTables[].Routes[?DestinationCidrBlock==`0.0.0.0/0`]'

Eine brauchbare Standardroute zeigt auf ein Internet-Gateway für ein öffentliches Subnetz oder auf ein NAT-Gateway für ein privates, und ein Status blackhole bedeutet, dass das Ziel gelöscht wurde und der Pfad nun still stirbt. Das sind andere Tabellen als die Routenliste des Endpoints, und die Reparatur der einen repariert die andere nicht.

Auf diesem Hop sitzen zwei Filter. Die auf die Ziel-Netzwerkzuordnung angewandte Sicherheitsgruppe muss ausgehenden Verkehr zum öffentlichen Ziel erlauben, und jede anwendbare Netzwerk-ACL muss die Anfrage und den Rückverkehr auf ephemeren Ports erlauben. Eine restriktive Zuordnungs-Sicherheitsgruppe ist ein häufiger Grund, warum privater Zugriff funktioniert, öffentlicher aber nicht.

Wählen Sie die erste Schicht anhand des Symptoms, statt alle drei gleichzeitig zu ändern:

Trennen Sie DNS-Fehler von einer toten Route

Die Namensauflösung scheitert anders als die Weiterleitung, und der vollständige Tunnel macht den Unterschied wichtig, weil der gepushte Resolver nun durch den Tunnel erreicht wird. Wenn der Endpoint VPC-DNS-Server angibt, brauchen deren Adressen Routenabdeckung und Autorisierung wie jedes andere Ziel. Fragen Sie den Resolver direkt, um zu sehen, welchen Fehler Sie haben: dig +short example.com @10.0.0.2, oder nslookup example.com 10.0.0.2 unter Windows.

Wenn eine numerische URL antwortet und eine benannte nicht, hören Sie auf, die Standardroute zu bearbeiten, und arbeiten Sie am DNS. Eine Anfrage an eine IP-Adresse beweist nichts über einen benannten virtuellen Host und sein Zertifikat, behalten Sie also einen benannten Test in der Abschlussprüfung.

Timing hilft. Eine TCP-Verbindung, die innerhalb weniger Sekunden keine Antwort bekommt, deutet auf Routing oder einen Filter hin, während eine Anfrage, die in der Namenssuche hängt, auf den Resolver deutet. Die Standardroute zu ändern, während der Resolver nicht erreichbar ist, macht aus einem Fehler meist zwei.

Rollen Sie sauber zurück und prüfen Sie dann den Egress-Pfad

Beide Objekte waren additiv, also ist das Zurückrollen ein Löschen und keine Reparatur:

aws ec2 delete-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 delete-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all

Verbinden Sie neu und bestätigen Sie, über welchen Pfad der Verkehr das Netz verlässt. Vergleichen Sie die beobachtete öffentliche Adresse mit der elastischen IP-Adresse des NAT-Gateways oder mit dem Internet-Gateway, das Sie nutzen wollten, und prüfen Sie, ob eine private Ressource in derselben Sitzung noch antwortet.

Schließen Sie mit einer kurzen Liste ab und behandeln Sie den letzten Punkt als Teil der Änderung und nicht als Dokumentation:

• Eine 0.0.0.0/0 Endpoint-Route für jedes zugeordnete Subnetz.
• Eine Autorisierungsregel, die 0.0.0.0/0 für die Clients abdeckt, die Sie bedienen wollen.
• Eine VPC-Standardroute, die nicht blackhole ist, auf jedem zugeordneten Subnetz.
• Egress der Zuordnungs-Sicherheitsgruppe plus ACL-Rückverkehr.
• Resolver-Adressen geroutet und autorisiert, mit einer benannten Anfrage verifiziert.
• Ein dokumentiertes Zurückrollen für die Route und die Regel.

Ein Hinweis zum Umfang: Dies ist ein IPv4-Pfad. Ein Dual-Stack-Client behält die IPv6-Konnektivität, die er bereits hat, eine IPv6-Standardroute ist also eine eigene Entscheidung mit eigener Autorisierung und kein Nebeneffekt dieser.