AWS Client VPN connecté mais sans accès à internet : vérifier les routes

Vous êtes connecté à l’endpoint AWS Client VPN, le sous-réseau privé répond, et pourtant chaque page publique expire. Cette combinaison réduit le problème à l’un de trois objets du côté géré : la route que le client installe, la route de l’endpoint avec sa règle d’autorisation, ou le saut suivant du sous-réseau associé. Je les vérifie dans cet ordre, car chaque défaillance se présente différemment côté client. Ce guide couvre l’endpoint géré associé à un VPC, pas un serveur OpenVPN sur une instance EC2 ni un rattachement Cloud WAN ou Transit Gateway.

Commencez par ce que le client route réellement

Un état connecté prouve la session TLS et l’attribution du CIDR au client, rien de plus. Demandez au système d’exploitation où irait une adresse publique tant que le tunnel est actif. Sous Linux, ip route get 1.1.1.1 devrait nommer l’interface du tunnel ; sous macOS, netstat -rn -f inet | head -5 affiche l’entrée par défaut ; sous Windows, Find-NetRoute -RemoteIPAddress 1.1.1.1 imprime l’interface choisie et le saut suivant.

Lisez ensuite l’indicateur de tunnel divisé, car il décide si les routes publiées par l’endpoint sont les seules destinations que le client envoie dans le tunnel :

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

Quand SplitTunnel vaut true, une destination publique n’utilise le tunnel que si l’endpoint publie une route qui la couvre, donc une 0.0.0.0/0 absente laisse ce trafic sur l’interface locale. Quand il vaut false, le client capture le trafic, mais l’endpoint doit encore le router et l’autoriser ; sinon les paquets entrent dans le tunnel et s’y arrêtent. Reconnectez le client après avoir changé l’un ou l’autre réglage, car les routes et les serveurs DNS sont livrés au moment de la connexion et un client en cours d’exécution peut conserver son ancien ensemble.

Lisez la route de l’endpoint et la règle d’autorisation séparément

Ce sont deux objets, et créer l’un ne crée pas l’autre. Listez les routes de l’endpoint et cherchez une route par défaut dont la cible est un sous-réseau associé :

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

Chaque route a exactement un sous-réseau cible, donc trois associations ont besoin chacune d’une route par défaut correspondante. AWS documente cette exigence de couverture, et le symptôme pratique d’un manque est un utilisateur qui travaille depuis un sous-réseau et se bloque depuis un autre, ce qui se lit comme une panne intermittente plutôt qu’une route absente. La documentation officielle du scénario Client VPN décrit la disposition en sous-réseau public à laquelle ces routes appartiennent.

L’autorisation est le second objet. Quand aucune règle ne couvre la destination publique, le tunnel transporte le paquet et le service le rejette, donc les ressources privées continuent de fonctionner alors qu’internet non :

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

Une règle pour le CIDR du VPC ne dit rien sur 0.0.0.0/0. Ajouter les pièces manquantes pour un tunnel complet signifie une route par sous-réseau associé plus une règle d’autorisation que vous pourrez auditer plus tard :

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 accorde la destination à chaque client de l’endpoint, donc ne la gardez que tant que le tunnel doit être complet ; une règle liée à un groupe d’annuaire est préférable quand vous avez des groupes auxquels la lier.

Suivez le paquet hors du sous-réseau associé

La route de l’endpoint décide qu’AWS remet le paquet à ce sous-réseau. Elle ne décide pas du saut suivant au-delà, qui vit dans la table de routes VPC propre au sous-réseau :

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

Une route par défaut utilisable pointe vers une passerelle internet pour un sous-réseau public, ou vers une passerelle NAT pour un privé, et un état blackhole signifie que la cible a été supprimée et que le chemin meurt désormais en silence. Ce sont des tables différentes de la liste de routes de l’endpoint, et réparer l’une ne répare pas l’autre.

Deux filtres se trouvent sur ce saut. Le groupe de sécurité appliqué à l’association réseau cible doit autoriser le trafic sortant vers la destination publique, et toute ACL réseau applicable doit autoriser la requête et le trafic retour sur les ports éphémères. Un groupe de sécurité d’association restrictif est une cause fréquente de voir l’accès privé fonctionner et l’accès public non.

Choisissez la première couche d’après le symptôme au lieu de changer les trois à la fois :

Séparez la défaillance DNS d’une route morte

La résolution de noms échoue différemment du transfert, et le tunnel complet rend la différence importante car le résolveur poussé est désormais atteint via le tunnel. Si l’endpoint spécifie des serveurs DNS du VPC, leurs adresses ont besoin d’une couverture de route et d’une autorisation comme toute autre destination. Interrogez le résolveur directement pour voir quelle défaillance vous avez : dig +short example.com @10.0.0.2, ou nslookup example.com 10.0.0.2 sous Windows.

Quand une URL numérique répond et qu’une URL nommée non, arrêtez de modifier la route par défaut et travaillez le DNS. Une requête vers une adresse IP ne prouve rien sur un hôte virtuel nommé et son certificat, donc gardez un test nommé dans la vérification finale.

Le chronométrage aide. Une connexion TCP qui ne reçoit pas de réponse en quelques secondes désigne le routage ou un filtre, tandis qu’une requête qui reste bloquée dans la résolution de nom désigne le résolveur. Changer la route par défaut alors que le résolveur est injoignable transforme souvent une défaillance en deux.

Revenez proprement en arrière, puis vérifiez le chemin de sortie

Les deux objets étaient additifs, donc le retour en arrière est une suppression et non une réparation :

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

Reconnectez-vous, puis confirmez par quel chemin le trafic sort. Comparez l’adresse publique observée avec l’adresse IP élastique de la passerelle NAT, ou avec la passerelle internet que vous comptiez utiliser, et vérifiez qu’une ressource privée répond encore dans la même session.

Terminez par une liste courte et traitez le dernier élément comme une partie du changement et non comme de la documentation :

• Une 0.0.0.0/0 route d’endpoint pour chaque sous-réseau associé.
• Une règle d’autorisation qui couvre 0.0.0.0/0 pour les clients que vous voulez servir.
• Une route par défaut de VPC qui n’est pas en blackhole sur chaque sous-réseau associé.
• La sortie du groupe de sécurité d’association, plus le trafic retour de l’ACL.
• Des adresses de résolveur routées et autorisées, vérifiées par une requête nommée.
• Un retour en arrière consigné pour la route et la règle.

Une précision de périmètre : c’est un chemin IPv4. Un client double pile conserve la connectivité IPv6 qu’il a déjà, donc une route par défaut IPv6 est une décision distincte avec sa propre autorisation et non un effet de bord de celle-ci.