Pourquoi ne puis-je pas me connecter à mon VPC lorsque j'utilise une connexion VPN de site à site AWS qui se termine sur une passerelle privée virtuelle ?

Résolution

• À l'aide de la console de gestion AWS, vérifiez que l'état du tunnel de la connexion VPN de site à site est actif. Si la connexion est interrompue, suivez les étapes de dépannage pour résoudre les interruptions de connexion liées auxdéfaillances de phase 1 et de phase 2.

• Vérifiez que le domaine de chiffrement configuré sur le dispositif de passerelle client est suffisamment large pour couvrir les CIDR du réseau local (sur site) et distant (AWS). Le VPN de site à site est une solution de réseau privé virtuel (VPN) basée sur le routage par défaut, les CIDR des réseaux locaux et distants sont définis sur any/any (0.0.0.0/0). AWS limite le nombre d'associations de sécurité (SA) à une seule paire pour les associations de sécurité entrantes et sortantes. Ainsi, si plusieurs réseaux sont définis pour communiquer via le tunnel, plusieurs associations de sécurité sont négociées. Cette configuration peut entraîner une défaillance de la connectivité réseau.

• Pour une configuration active/active (où les deux tunnels sont opérationnels), assurez-vous que le routage asymétrique est pris en charge et activé sur le périphérique de passerelle client. Si vous n'avez pas activé le routage asymétrique, AWS sélectionne de manière aléatoire le tunnel de sortie (trafic entre AWS et la passerelle client). Pour un VPN dynamique, utilisez les attributs AS PATH préfixés ou MED BGP pour utiliser un tunnel unique pour renvoyer le trafic du VPC vers le périphérique de passerelle client.

• Pour un VPN statique, assurez-vous que les itinéraires du réseau local distant sont définis sur la connexion VPN. Assurez-vous également d'avoir créé un itinéraire inverse correspondant pour les CIDR du VPC sur le périphérique de passerelle client. Cette route inverse est utilisée pour acheminer le trafic via l'interface de tunnel virtuel (VTI).

• Pour un VPN dynamique, assurez-vous que le dispositif de passerelle client fait de la publicité pour les routes locales auprès de ses homologues AWS. Vérifiez également que le périphérique de passerelle client reçoit les CIDR du réseau VPC.

• Vérifiez le routage sur les tables de routage du VPC. Il est recommandé d'activer la propagation des routes VGW pour propager automatiquement les routes VPN vers les tables de routage du VPC. Ou si la propagation des itinéraires est désactivée, vous pouvez ajouter un itinéraire statique pour que le réseau local passe par le VGW.

• Vérifiez que le trafic est autorisé à la fois sur l'ACL du réseau de sous-réseaux et sur le groupe de sécurité des ressources cibles. Pour plus d'informations, voir la section Contrôler le trafic vers les ressources à l'aide de groupes de sécurité et Contrôler le trafic vers des sous-réseaux à l'aide des ACL réseau.

• Vérifiez que le trafic est autorisé (entrant et sortant) sur l'hôte cible ou le pare-feu de l'instance. Sur le système d'exploitation Windows, vérifiez que le pare-feu Windows autorise le trafic. Pour les systèmes Linux, vérifiez que les tables IP, les pare-feux et autres pare-feux hôtes similaires autorisent le trafic correspondant.

• Vérifiez si l'application qui s'exécute sur le serveur cible écoute sur le port et le protocole attendus (TCP/UDP). Exécutez les commandes suivantes :

  CMD pour Windows :

  > netstat -a

  Terminal Linux :

  $ sudo netstat -plantu

Informations connexes

Comment déterminer quel programme utilise ou bloque des ports spécifiques du protocole de contrôle de transmission dans Windows Server 2003 dans la documentation Windows