AWS Client VPN connecté, mais EC2 expire encore

Mon portable affichait « connecté ». Le client AWS Client VPN affichait son état vert, le point de terminaison enregistrait une session, et je n’arrivais toujours pas à ouvrir un port MongoDB sur une instance EC2 dans un sous-réseau privé. Rien n’était manifestement cassé : le certificat était valide, le profil venait de la console et le tunnel transportait du trafic. L’erreur était la mienne, car je lisais « connecté » comme « autorisé ».

La connexion répond à une seule question : cette identité peut-elle établir une session ? Tout ce qui suit est décidé par des règles distinctes, qui ne voient jamais votre certificat. Une session qui s’authentifie et un paquet qui arrive sont deux succès différents, et c’est dans l’écart entre les deux que vivent la plupart des signalements du type « le VPN est monté mais l’hôte est injoignable ».

Les vérifications ci-dessous sont l’ordre que j’utilise aujourd’hui.

Ce qu’une session connectée prouve réellement

Pendant le handshake, le point de terminaison valide le certificat du client par rapport à son magasin de confiance, ou redirige le navigateur vers votre fournisseur d’identité quand SAML est configuré. Si cela passe, le client reçoit une adresse issue du CIDR client du point de terminaison et la console affiche une connexion active. À aucun moment de cet échange, rien ne demande si vous pouvez atteindre 10.0.4.17 sur le port 27017.

L’autorisation vers une destination est un objet distinct sur le point de terminaison. Chaque flux est comparé aux règles d’autorisation, dont chacune associe un CIDR de destination au groupe auquel la règle est accordée. Quand aucune règle ne couvre la destination, le point de terminaison accepte la session et abandonne le trafic. Il n’y a ni bandeau, ni boucle de reconnexion, ni rien dans l’interface du client qui affiche « refusé ».

Comparez la règle d’autorisation à la ressource, pas au VPC

Listez les règles et placez-les à côté de l’adresse que l’instance possède réellement :

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

La sortie affiche un CIDR de destination et un identifiant de groupe par règle. Deux défaillances s’y cachent. La règle peut autoriser 10.0.0.0/16 alors que l’instance se trouve dans un VPC appairé sur 10.1.0.0/16 ; la route de peering existe, mais personne n’a écrit de règle d’autorisation pour la seconde plage. Ou bien la règle pointe vers un groupe d’annuaire auquel l’utilisateur appartient dans l’annuaire, mais pas dans le groupe que le point de terminaison évalue.

Écrivez la règle la plus étroite qui couvre la destination, et n’ajoutez une seconde règle que lorsqu’un second CIDR est réellement nécessaire. Une règle large 0.0.0.0/0 issue d’un démarrage rapide fonctionne, et c’est pourquoi elle survit en production et masque le modèle.

Deux tables de routage décident si le paquet circule

Une route de point de terminaison associe un CIDR de destination à l’un des sous-réseaux auxquels le point de terminaison est associé. C’est la moitié du chemin. La table de routage propre au sous-réseau doit encore savoir comment transmettre le paquet, ce qui compte dès que la destination se trouve derrière une connexion de peering, un transit gateway ou une plage sur site joignable par un tunnel site-to-site.

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

Cherchez une route dont la destination correspond au CIDR de la ressource et dont la cible est un sous-réseau associé. Si la route manque, ajoutez-la. Si elle est présente et que l’hôte reste silencieux, l’écart est du côté du VPC : comparez alors avec la table de routage du sous-réseau d’association.

Un réglage côté client casse le routage sans casser le tunnel : un profil contenant route-nopull. La directive demande à un client fondé sur OpenVPN d’ignorer les routes que le serveur pousse, si bien que l’interface ne monte qu’avec l’adresse propre au point de terminaison et que la destination n’a tout simplement pas de route. Vérifiez avec ip route show sous Linux ou netstat -rn sous macOS qu’une route passant par l’interface tun existe. Si ce n’est pas le cas, retirez route-nopull du profil exporté et reconnectez-vous pour que les routes poussées soient appliquées.

Les groupes de sécurité ne voient pas l’adresse de votre client

C’est la partie que j’ai comprise de travers pendant un après-midi. Pour un point de terminaison IPv4 associé à un sous-réseau, le service traduit l’adresse source du client en l’adresse de l’interface réseau du point de terminaison dans ce sous-réseau. Le paquet qui arrive à l’instance ne porte pas l’adresse affichée par votre client ; une règle de groupe de sécurité autorisant le pool client, par exemple 172.16.0.0/22, ne correspond donc à rien du tout.

Autorisez le port depuis le groupe de sécurité du point de terminaison, qui est attaché à l’interface de l’association, plutôt que depuis le CIDR client. Référencer le groupe est plus durable que coder une adresse en dur, car l’adresse de l’interface ne vous appartient pas. Les ACL réseau ne conservent pas d’état : là où des entrées personnalisées existent, le sens entrant comme le sens sortant doivent autoriser le flux.

Connectez-vous aussi à l’adresse privée de l’instance. Une IP publique fait sortir le paquet du VPC et le fait rentrer par un autre chemin, avec d’autres règles : un test via l’adresse publique ne dit donc rien du chemin privé.

Un ordre d’isolement qui s’arrête au premier échec

Parcourez ces points dans l’ordre et arrêtez-vous à celui qui échoue. Chaque étape écarte une couche plutôt que toutes à la fois.

1. Confirmez quelle identité la session a utilisée et quel groupe le point de terminaison évalue. Un certificat issu d’un magasin de confiance n’est pas le même principal qu’une assertion SAML venue de l’annuaire.
2. Confirmez qu’une règle d’autorisation couvre le CIDR de la ressource pour ce groupe.
3. Confirmez qu’une route de point de terminaison existe et cible un sous-réseau associé, puis que la table de routage du sous-réseau sait transmettre plus loin.
4. Confirmez que le groupe de sécurité autorise le port depuis l’interface du point de terminaison et non depuis le pool client.
5. Testez depuis l’intérieur du VPC, avec une session SSM sur une autre instance du même sous-réseau, pour séparer un problème applicatif d’un problème de chemin client.

Quand les étapes ne tranchent pas, ce tableau est mon recours :

Deux détails de compte produisent des symptômes qui ressemblent à des échecs de permission. Chaque utilisateur a besoin d’un certificat client distinct ; partager le même entre deux machines fait que les sessions se déplacent mutuellement, et le résultat est une boucle de reconnexion plutôt qu’un refus. Quand un nouveau point de terminaison est créé, la console affiche un nom DNS que certaines versions du client n’acceptent qu’avec le préfixe aléatoire indiqué sur la page du point de terminaison : copiez donc le nom complet au lieu de le reconstituer.

Si la cinquième étape vous bloque, récupérez le journal de connexion du point de terminaison et lisez les entrées d’autorisation avant de changer quoi que ce soit. Le journal nomme la destination vérifiée et la règle qui a correspondu ou non, ce qui ramène la question des quatre couches à une seule réponse.