Pourquoi EC2 ne peut pas joindre votre ordinateur portable AWS Client VPN
Client VPN traduit les sources IPv4 du client vers l'interface du point de terminaison. C'est pourquoi la réponse fonctionne et une nouvelle connexion depuis EC2 non.
Un ordinateur portable connecté via AWS Client VPN atteint une application EC2 sans difficulté. Ensuite, vous essayez l'inverse, depuis EC2 vers l'adresse attribuée au client, et la connexion se bloque ou est refusée. Cette asymétrie vient rarement d'une règle de groupe de sécurité manquante. Sur un point de terminaison Client VPN associé à des sous-réseaux VPC, AWS traduit les sources IPv4 du client vers l'interface réseau du point de terminaison, il n'existe donc aucune adresse VPC entrante qui représente votre ordinateur portable.
Commencez par ce que montre la capture
Faites une capture sur l'hôte EC2 pendant que le client se connecte et lisez l'adresse source que l'application voit réellement. Si c'est l'interface du point de terminaison côté VPC et non une adresse du pool de clients, la traduction est confirmée avant même de changer une seule règle.
Le pool de clients est une plage d'attribution, pas un sous-réseau doté d'une route de retour. C'est sur cette distinction que la plupart de ces enquêtes se trompent.
La traduction qui explique l'asymétrie
Trois flux se confondent, et un seul d'entre eux est celui que les gens testent.
| Flow | Started by | What the VPC sees | Outcome |
|---|---|---|---|
| Client to EC2 service | The client | A translated source at the endpoint interface | Works, with a stateful reply |
| EC2 host to client pool address | The EC2 host | A destination with no route and no translation state | No usable path |
| Client to client | A client, when the feature is configured | Traffic mediated by the endpoint | Works only with that feature and its authorisation |
La description des composants de Client VPN précise que les sources IPv4 du client sont traduites vers l'interface du point de terminaison, ce qui suffit à comprendre pourquoi la ligne du milieu n'a rien à comparer.
Une nouvelle connexion a besoin d'une route, d'une étape de résolution d'adresse et d'une décision d'autorisation. L'état de traduction de la session de quelqu'un d'autre n'en fournit aucun des trois.
Pourquoi une réponse n'est pas une nouvelle connexion
Une réponse TCP est comparée à une entrée existante, et c'est pourquoi le chemin de retour fonctionne sans aucune règle entrante. Un SYN neuf de l'hôte EC2 n'a aucune entrée à comparer, il devient donc une tentative sortante ordinaire vers une destination que le VPC ne sait pas atteindre.
C'est aussi pourquoi il est trompeur de décrire cela comme un trafic qui ne va que dans un sens. Le trafic de retour circule en continu dans ces sessions. C'est l'initiation qui n'a pas de chemin.
Ce qui casse encore une session censée fonctionner
Les groupes de sécurité, les ACL réseau et le pare-feu de l'ordinateur portable lui-même comptent tous pour les connexions censées réussir. Un ping qui échoue en dit le moins, car la politique ICMP est souvent distincte de la politique TCP qui vous intéresse.
Écrivez ces règles en fonction de la source traduite, pas de l'adresse du client. Les règles liées à l'adresse qui n'apparaît jamais sur le réseau sont l'échec le plus courant que l'on s'inflige soi-même dans cette conception.
Quand le VPC doit vraiment lancer la conversation
Si un service doit notifier un poste de travail, inversez le sens et laissez le client maintenir un canal sortant persistant auquel le service répond. Si tout un réseau distant doit être joignable depuis le VPC, choisissez une architecture qui publie ses préfixes et sa politique d'accès plutôt que de supposer que Client VPN le fait déjà. L'accès client à client est un troisième cas, plus étroit, avec ses propres objets de route et d'autorisation. Rien de tout cela n'est une case à cocher sur le point de terminaison existant.
Gardez aussi honnête la portée de l'explication IPv4. La documentation AWS actuelle sépare IPv6, où cette traduction ne s'applique pas, et d'autres modèles de raccordement qui routent différemment.
Testez en trois étapes étiquetées : le client ouvre une session autorisée, le service du VPC répond à cette session, et un hôte du VPC ouvre une nouvelle session vers le client. Que les deux premières réussissent alors que la troisième échoue est la forme attendue de cette conception, pas un défaut à traquer avec des règles de pare-feu.