VGW ou TGW ? Où se termine le tunnel IPsec d’AWS Site-to-Site

On demande où un VPN Site-to-Site d’AWS cesse de protéger le paquet et on attend une réponse unique : à la passerelle. La version utile de cette réponse nomme laquelle, car une passerelle privée virtuelle et une passerelle de transit sont des montages différents avec des objets d’attachement différents, et le relecteur qui suppose le mauvais construit le reste de l’évaluation sur un schéma qui n’existe pas. Faites les trois vérifications ci-dessous dans l’ordre. Chacune soit confirme la limite, soit vous dit que la réponse précédente portait sur une autre ressource.

Nommez les trois extrémités avant d’évaluer quoi que ce soit

Une revue du chiffrement de ce chemin exige trois choses nommées : la passerelle client, la cible VPN d’AWS qui termine IPsec, et l’extrémité applicative qui reçoit le paquet interne. Notez-les avec leurs identifiants de ressource avant d’ouvrir une seule page de la console, car tout ce qui suit est une affirmation sur l’une de ces trois.

La passerelle client est la vôtre et sa configuration vous est visible. La cible AWS est une ressource gérée, et l’erreur est de la supposer : une connexion VPN peut s’attacher à une passerelle privée virtuelle ou directement à une passerelle de transit, et ni l’une ni l’autre n’implique l’autre. La troisième extrémité est celle que les gens sautent, et c’est la seule qui répond à la vraie question sur les données applicatives.

Vérification 1 : quelle passerelle termine réellement le tunnel

Les deux montages sont pris en charge et le guide d’architecture Site-to-Site VPN les décrit côte à côte, alors interrogez l’API plutôt qu’un schéma qui a souvent un an. Une requête en lecture seule sur une connexion renvoie les champs de cible VPN :

aws ec2 describe-vpn-connections --region eu-west-1   --vpn-connection-ids vpn-0123456789abcdef0   --query 'VpnConnections[0].{VGW:VpnGatewayId,TGW:TransitGatewayId,CGW:CustomerGatewayId,Category:Category}'

Le discriminant est TransitGatewayId, pas VpnGatewayId. Une connexion dont TransitGatewayId est vide se termine sur une passerelle privée virtuelle autonome, tandis qu’une connexion où ce champ est renseigné se termine sur un attachement VPN de passerelle de transit, et VpnGatewayId peut encore être rempli dans ce cas car il peut nommer la passerelle porteuse de l’attachement. Lisez d’abord le champ TGW, puis confirmez le type d’attachement à partir de la liste des attachements plutôt qu’à partir d’un nom de champ, car un attachement VPC sur cette passerelle de transit n’est pas l’attachement VPN. Trouver l’instance de destination dans un VPC attaché ne vous dit rien sur l’attachement VPN qui a transporté le paquet.

Pendant que vous y êtes, vérifiez les tunnels. La connexion porte deux tunnels IPsec pour la redondance, et une connexion dont le second tunnel n’est jamais monté est un constat réel pour la disponibilité, même si cela ne change rien à la limite du chiffrement :

aws ec2 describe-vpn-tunnels --region eu-west-1   --filters Name=vpn-connection-id,Values=vpn-0123456789abcdef0   --query 'VpnTunnels[].{Outside:OutsideIpAddress,State:State,Status:Status}'

Vérification 2 : ce que le paquet interne porte encore

Une fois IPsec terminé, AWS transmet le paquet désencapsulé par la route qui lui correspondait. À partir de là, le trafic est du trafic VPC ordinaire, et la protection du VPN a pris fin. Ce n’est pas un trou dans le service ; c’est ce que signifie la limite, et le point de la liste est de le dire clairement au lieu de laisser « le VPN est chiffré » tenir lieu de « les données sont chiffrées de bout en bout ».

Examinez maintenant ce qui était à l’intérieur. Si le paquet interne est un protocole applicatif en clair, rien en aval n’ajoute de confidentialité tant que quelque chose d’autre ne le chiffre pas. Si le paquet interne porte déjà une session TLS, le retrait de l’IPsec externe ne change rien pour cette session : elle reste protégée jusqu’à sa propre extrémité, où qu’elle soit.

La surcorrection habituelle est de conclure que tout ce qui est derrière la passerelle est exposé. Ce n’est pas le cas. Le transport du service, le chiffrement du stockage et le TLS applicatif sont des mécanismes distincts avec des conditions distinctes, et chacun doit être évalué selon ses propres termes plutôt que déduit de la forme du VPN. Une entrée de journal de flux affichant ACCEPT prouve que le routage a fonctionné et ne dit rien sur la confidentialité, ce qui est exactement l’erreur que cette liste existe pour empêcher.

Vérification 3 : ce qui termine TLS derrière la passerelle

Suivez l’écouteur, pas l’adresse. Si un répartiteur de charge ou un proxy termine TLS, la connexion que tient votre client s’arrête là, et le proxy ouvre une seconde connexion vers le backend qui peut être en clair ou en TLS avec une autre chaîne de confiance. Une adresse IP privée et une route correspondante ne sont pas une preuve sur cette seconde connexion.

Testez l’extrémité qui vous importe vraiment depuis l’intérieur du VPC, avec le nom que l’application utilise plutôt qu’une IP que vous avez résolue une fois :

openssl s_client -connect internal.example:443 -servername internal.example -verify_return_error

Répétez-le pour chaque saut traversé par la requête. Si la réponse diffère entre le nom tourné vers le client et le nom du backend, vous avez trouvé exactement le segment que le VPN n’a jamais couvert, et c’est le constat à écrire.

Consignez le résultat en segments, pas en verdict

La sortie de cette liste est un petit tableau avec une ligne par segment : passerelle client vers cible VPN d’AWS, passerelle vers charge de travail, charge de travail vers magasin de données, et tout saut de proxy entre les deux. Chaque ligne indique ce qui la protège et de quoi dépend cette protection. « Chiffré » sans mécanisme et sans extrémité n’est pas une ligne.

Répondez ensuite à l’exigence d’origine dans les mêmes termes qu’elle a été posée. Si l’exigence est que les données restent confidentielles jusqu’à ce que la charge de travail les reçoive, le VPN ne satisfait que le premier segment, et les lignes restantes demandent un transport applicatif, un TLS de service ou un chiffrement de stockage configurés et vérifiés séparément.

Conservez les identifiants de connexion, les états des tunnels et les sujets des certificats dans le dossier. Quand quelqu’un revient sur la conception dans six mois, ces trois artefacts répondent à la question de la limite en quelques minutes au lieu de relancer le débat depuis un schéma.