AWS Site-to-Site VPN : extérieur, intérieur et le préfixe LAN

La plupart des erreurs sur AWS Site-to-Site VPN sont des erreurs d’adresses, et elles se commettent avant qu’un seul paquet ne bouge. Les adresses extérieures du tunnel joignent les pairs IPsec, les adresses intérieures forment la liaison de routage entre eux, et les préfixes protégés sont ce à quoi cette liaison sert. Copiez un rôle dans l’autre et le tunnel monte alors que rien ne route. Voici la séquence lire-vérifier-configurer que j’utilise sur une passerelle client BGP, avec les valeurs tirées de la configuration d’équipement téléchargée plutôt que de la mémoire.

Trois rôles d’adresse, un seul tunnel

Les adresses extérieures sont publiques et appartiennent aux pairs IPsec : une par tunnel côté AWS, et l’identité joignable de la passerelle client de votre côté, ajustée à la disposition NAT que vous avez réellement. Les adresses intérieures sont privées et appartiennent à la liaison logique, qu’AWS documente comme un /30 tiré de 169.254.0.0/16. Les préfixes protégés sont les réseaux VPC, locaux ou de transit que vous routez et annoncez par cette liaison.

Attribuer un préfixe LAN comme adresse de l’interface du tunnel est la version classique de cette erreur. L’interface semble configurée, le LAN n’est pas annoncé, et le côté distant n’a aucune route pour lui. Le tunnel peut même réussir son propre ping intérieur alors que chaque nom d’application expire. La référence des options de tunnel énumère les contraintes du CIDR intérieur, y compris la plage d’adresses dont il doit provenir.

Lisez les valeurs dans la configuration téléchargée

Téléchargez la configuration de votre modèle d’équipement précis depuis la connexion, puis traitez sa table d’adresses comme la source de vérité. La console affiche les mêmes valeurs par tunnel : IP extérieure, CIDR intérieur et l’adresse du pair BGP côté AWS. Les deux tunnels sont des objets distincts avec des points de terminaison extérieurs distincts et des /30 intérieurs distincts, même si tous deux transportent les mêmes réseaux protégés.

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query 'VpnConnections[0].Options.TunnelOptions[].[OutsideIpAddress,TunnelInsideCidr]'
aws ec2 describe-customer-gateways --customer-gateway-ids cgw-0123456789abcdef0 \
  --query 'CustomerGateways[0].[IpAddress,BgpAsn]'

Si le fichier téléchargé et la console en direct ne concordent pas, le fichier est périmé. Retéléchargez plutôt que de modifier les adresses à la main, car un écart entre la paire intérieure et le voisin configuré du pair est une panne BGP silencieuse.

Construisez la liaison avec la bonne adresse dessus

Sur une passerelle Linux, le tunnel est une interface VTI ou XFRM, et le /30 intérieur va sur cette interface. Deux tunnels signifient deux interfaces et deux voisins BGP, un par point de terminaison AWS. La convention qu’AWS imprime dans la configuration d’équipement téléchargée place la passerelle privée virtuelle sur la première adresse de chaque /30 intérieur et votre passerelle client sur la seconde, vous prenez donc l’adresse la plus haute et vous appairez avec la plus basse. Rien ici n’a besoin d’une adresse LAN.

ip tunnel add tun0 mode vti local 203.0.113.10 remote 18.230.1.1 key 42
ip addr add 169.254.10.2/30 dev tun0
ip link set tun0 up mtu 1400
ip tunnel add tun1 mode vti local 203.0.113.10 remote 18.230.2.1 key 43
ip addr add 169.254.10.6/30 dev tun1
ip link set tun1 up mtu 1400

Si le fichier de votre modèle d’équipement imprime l’appairage inverse, utilisez ses chiffres et gardez la règle : l’adresse sur l’interface est la vôtre, l’adresse du pair appartient à AWS. Faire l’inverse produit un tunnel qui n’atteint jamais Established, parce que le voisin que vous avez configuré est l’adresse que votre propre interface détient déjà.

Gardez le mark et la clé VTI alignés sur ce que le démon IKE utilise pour lier une SA enfant à l’interface, sinon le trafic arrive sur le tunnel sans interface où atterrir. Vérifiez la MTU par rapport au chemin et par rapport aux propres réglages du démon IKE au lieu de copier un chiffre depuis un autre site.

Vérifiez BGP avant de vérifier les routes

Le fait qu’IPsec monte prouve que les pairs s’accordent sur une association de sécurité et rien d’autre. La session BGP est une négociation distincte sur la liaison intérieure, alors lisez l’état du voisin et les compteurs de préfixes, puis comparez-les à ce que vous comptiez annoncer.

ip -s addr show dev tun0
vtysh -c 'show bgp summary'
vtysh -c 'show bgp neighbors 169.254.10.1'
vtysh -c 'show ip bgp neighbors 169.254.10.1 advertised-routes'

L’état Established avec zéro préfixe reçu est un problème de politique ou d’annonce, pas un problème de tunnel. Répétez toute la vérification sur le second tunnel ; un premier tunnel qui fonctionne vous dit que les adresses sont plausibles, pas que le second tunnel a été configuré.

Suivez un paquet routé, puis arrêtez-vous

Une fois que la session porte les préfixes, testez la route dans les deux sens depuis la passerelle : adresse source, saut suivant et la politique de sécurité qui autorise le trafic. Une session BGP peut être établie alors que le préfixe précis dont votre application a besoin est filtré, résumé ou pointé vers la mauvaise interface.

Reachability Analyzer est l’outil côté AWS qui prend une source, une destination et un chemin, et indique quel composant d’une configuration prise en charge l’a bloqué. Utilisez-le pour tester le chemin du VPC vers l’adresse de votre passerelle client, pas depuis un hôte d’application. Il analyse la configuration et n’envoie pas de paquet à travers un pare-feu local, alors gardez son verdict séparé de vos propres compteurs d’interface et captures de paquets.

Consignez la paire extérieure, le /30 intérieur et les préfixes annoncés pour chaque tunnel dans un seul tableau. C’est ce tableau qui rend le changement suivant vérifiable.