AWS Client VPN ou un bastion pour atteindre un VPC appairé

Un point de terminaison Client VPN peut atteindre un VPC appairé avec son VPC associé, et vous n'avez pas besoin d'un bastion pour rendre cela légitime. Le choix qui vaut la peine est celui de l'endroit où le trafic change de mains : une route de point de terminaison qui atterrit dans le sous-réseau d'association et traverse la connexion de peering, ou un hôte dans le VPC appairé qui termine la session. Les deux chemins fonctionnent et ils échouent à des endroits différents, donc la décision porte sur la propriété et l'audit, pas sur ce qu'AWS autorise. Voici comment je choisis entre eux, et les quatre entrées qui font fonctionner le chemin routé.

Deux chemins, un point de terminaison, des propriétaires différents

Sur le chemin routé, le trafic du client atteint le point de terminaison, est traduit vers l'adresse de l'interface réseau Client VPN dans le sous-réseau d'association, et quitte ce sous-réseau par la connexion de peering de A vers B. Le VPC B ne termine aucune session VPN ; il voit du trafic ordinaire venant du VPC A, c'est pourquoi sa route de retour pointe vers le VPC A, et non vers le pool de clients.

Sur le chemin du bastion, le client atteint d'abord un hôte. Un bastion dans A laisse encore le dernier saut traverser la connexion de peering, donc vous conservez le travail de peering et ajoutez une session. Un bastion dans B a aussi besoin d'un chemin depuis le client, et quand ce chemin est la même route de point de terminaison, vous avez la conception routée plus un saut. Le bastion ne retire du travail que lorsqu'il existe déjà, qu'il est déjà approuvé, et que ce qui se trouve derrière a besoin d'une frontière de session plutôt que d'une frontière réseau.

Quatre entrées font fonctionner le chemin routé

AWS documente ce scénario sur la page Client VPN how-it-works, et en pratique tout se résume à quatre entrées détenues par deux ou trois équipes. Les plages sont illustratives ; la plage appairée doit être unique et la plage de retour doit correspondre à votre plan.

Route et autorisation sont des contrôles distincts. Une route de point de terminaison correcte sans règle d'autorisation correspondante ne donne rien au client ; une règle d'autorisation pour une destination que le point de terminaison ne peut pas router lui donne un trou noir. Les deux doivent nommer la même plage.

La route du point de terminaison pointe vers un sous-réseau du VPC du point de terminaison lui-même, jamais vers la connexion de peering. Les tables de routes du VPC pointent vers la connexion de peering, jamais vers une instance ou une interface. Copier une valeur entre les deux s'enregistre sans protestation et ne route rien.

Parce que le sous-réseau d'association traduit la source du client, B doit router vers le VPC A, et non vers le pool de clients. Envoyer la plage des clients à travers la connexion de peering semble symétrique, passe la revue et échoue silencieusement parce que B ne voit jamais de paquet dont la source est un client.

Groupes de sécurité et le dernier mètre d'autorisation

Le routage fait entrer les paquets dans B ; B décide encore. Pour une connexion de peering active dans la même région, un groupe de sécurité dans B peut référencer le groupe appliqué à l'association Client VPN, ce qui garde la règle étroite et survit aux changements d'adresse. Là où une référence de groupe n'est pas réalisable, autorisez explicitement la plage du sous-réseau d'association au lieu d'élargir à 0.0.0.0/0, ce qui transforme une erreur de routage en délai d'attente inexpliqué.

Vérifiez ensuite ce que le routage ne touche jamais : les ACL réseau des deux sous-réseaux, la liste d'autorisation ou l'audience du jeton de l'application, et le DNS. Le peering ne copie pas les zones hébergées privées, donc le portable peut détenir une route fonctionnelle vers une adresse qu'il ne peut pas résoudre, et une connexion de peering n'ajoute aucune confiance à un certificat. Pointez le point de terminaison vers un résolveur qui répond pour B, puis confirmez que le nom privé et le certificat correspondent.

Quand le bastion est la réponse honnête

Je garde trois déclencheurs pour choisir un bastion à dessein. Le VPC appairé appartient à une équipe qui n'ajoutera pas de route de retour pour votre plage ou n'acceptera pas de référence de groupe. L'accès doit être approuvé ou enregistré par session et l'application ne peut pas le porter elle-même. Ou le dernier saut doit rester à l'intérieur de B parce que le service ne se résout que là et que son identité TLS est épinglée à un nom interne.

Rien de tout cela n'est un contournement du fait que le peering n'est pas transitif. La non-transitivité limite ce que les ressources de B peuvent faire : elles ne peuvent pas utiliser A comme transit vers un troisième VPC avec lequel A est appairé. Elle n'a jamais signifié qu'un utilisateur VPN ne peut pas atteindre un VPC appairé directement, et un bastion construit pour contourner cette mauvaise lecture est un hôte à corriger sans raison.

L'erreur inverse coûte plus cher avec le temps : faites passer chaque équipe par le seul bastion qui existe déjà, puis découvrez que son groupe de sécurité, sa table de routes et sa fenêtre de correctifs sont la dépendance de production. Notez quel déclencheur l'hôte sert, et retirez-le quand le déclencheur disparaît.

Transit Gateway et plusieurs associations changent l'arithmétique

Si le point de terminaison est attaché directement à un Transit Gateway plutôt qu'à un sous-réseau, le modèle change : les clients ne sont plus traduits vers une adresse d'interface dans un sous-réseau d'association, et les tables de routes de la passerelle doivent porter la plage des clients plus le rattachement qui mène au VPC appairé. C'est plus propre à l'échelle, mais le travail passe de quatre entrées à des tables de routes de passerelle.

Plusieurs associations multiplient les contrôles. La route du point de terminaison appartient au point de terminaison, mais chaque sous-réseau d'association a besoin d'une table de routes avec un véritable prochain saut de peering. Une session peut réussir via une association alors qu'une autre n'a pas de chemin de retour, alors testez chacune.

Ordre de vérification qui trouve la panne rapidement

Exécutez-les dans l'ordre ; chaque étape peut réussir pendant que la suivante échoue, et un délai d'attente côté client ne dit presque jamais laquelle a cassé.

1. Résolvez le nom de l'application depuis le client et vérifiez que l'adresse est dans la plage appairée.
2. Connectez-vous, puis lisez le journal des connexions du point de terminaison pour l'association qui a terminé la session.
3. Sur ce sous-réseau d'association, confirmez que la table de routes pointe la plage appairée vers une connexion de peering active.
4. Sur le sous-réseau de ressources dans B, confirmez une entrée de retour pour la plage de l'interface et des règles de groupe correspondantes.
5. Testez une opération autorisée et une ressource qui doit rester inaccessible ; la seconde attrape les restes de débogage.
6. Reconnectez-vous après tout changement de route split-tunnel, car un tunnel en cours ne prendra pas un nouvel ensemble de routes.

Deux symptômes méritent d'être mémorisés. Un SYN qui atteint B sans réponse est presque toujours la route de retour manquante. Une connexion qui se termine puis se réinitialise est généralement le groupe, l'ACL ou l'application. Ni l'un ni l'autre n'apparaît comme cause dans le journal du point de terminaison, alors gardez les quatre entrées avec un propriétaire à côté de chacune.

Si aucun des trois déclencheurs ne s'applique, terminez le chemin routé et consignez ces quatre entrées. Si l'un s'applique, gardez le bastion uniquement pour cette frontière et laissez la route du point de terminaison aux services qui n'ont pas besoin d'une session devant eux.