Si vous rencontrez des problèmes de connectivité réseau après avoir configuré une connexion IPsec-VPN, consultez cette rubrique pour résoudre les incidents.
1. Liste de contrôle rapide (vérification en 5 minutes)
Avant d'analyser les journaux, effectuez la liste de contrôle suivante afin d'écarter les erreurs de configuration courantes. De nombreux problèmes peuvent être résolus à cette étape.
-
Connectivité réseau : Votre passerelle locale peut-elle exécuter une commande
pingvers l'adresse IP publique de la passerelle VPN Alibaba Cloud ?Action : Sur votre passerelle locale, exécutez la commande
ping. Si elle échoue, vérifiez votre connexion Internet ainsi que les éventuels pare-feu intermédiaires.
-
Pare-feu et politiques de sécurité : Les ports requis sont-ils ouverts ?
Action : Assurez-vous que le pare-feu et les politiques de contrôle d'accès de votre passerelle locale (et les groupes de sécurité Alibaba Cloud, le cas échéant) autorisent le trafic entrant et sortant sur le port UDP 500 et le port UDP 4500 (pour la traversée NAT).
-
Cohérence des paramètres : Les paramètres de chiffrement sont-ils identiques entre le côté cloud (passerelle VPN Alibaba Cloud) et le côté local (passerelle locale) ?
Action : Vérifiez attentivement les paramètres de configuration IKE des deux côtés (version, algorithme de chiffrement, algorithme d'authentification, groupe DH, clé prépartagée) pour garantir leur cohérence.
-
Adresse IP de la passerelle cliente : L'adresse IP est-elle correcte, en particulier si la passerelle locale se trouve derrière un dispositif NAT ?
-
Action : Dans la console de gestion Alibaba Cloud, vérifiez l'adresse IP de la passerelle cliente associée à la connexion IPsec-VPN.
Si la passerelle locale dispose d'une adresse IP publique, cette valeur doit correspondre à cette adresse IP publique.
Si la passerelle locale se trouve derrière un dispositif NAT, cette valeur doit correspondre à l'adresse IP publique du dispositif NAT. Une adresse IP incorrecte est une cause fréquente de l'erreur « no response from peer ».
-
-
Configuration des routes : Les routes pointent-elles vers le VPN ?
-
Action :
Côté Alibaba Cloud : Vérifiez la table de routage du VPC pour vous assurer que le trafic destiné au bloc CIDR du centre de données est acheminé vers la passerelle VPN.
Côté centre de données : Vérifiez votre routeur local pour vous assurer que le trafic destiné au bloc CIDR du VPC est acheminé vers le tunnel IPsec.
-
-
Blocs CIDR privés non RFC côté IDC : Le centre de données local utilise-t-il des blocs CIDR privés non RFC (tels que 30.0.0.0/xx, qui ne font pas partie des blocs CIDR privés standard 10.0.0.0/8, 172.16.0.0/12 ou 192.168.0.0/16) ?
Action : Si de tels blocs CIDR privés non RFC existent côté IDC, vous devez activer la fonctionnalité d'utilisation privée de blocs CIDR publics pour le VPC. Pour plus d'informations, consultez la rubrique Comment mettre en œuvre l'utilisation privée d'adresses IP publiques dans un VPC ?.
Configuration pour l'interconnexion entre plusieurs blocs CIDR : Pour les scénarios impliquant plusieurs blocs CIDR dans le trafic ciblé, consultez la rubrique Recommandations de configuration et FAQ pour l'interconnexion entre plusieurs blocs CIDR.
-
Conflit de blocs CIDR privés : Le bloc CIDR privé utilisé par le centre de données local chevauche-t-il les blocs CIDR du VPC et de ses vSwitches ?
Action : Comparez les blocs CIDR privés du centre de données local avec les blocs CIDR du VPC et de ses vSwitches un par un afin de garantir qu'il n'y a aucun chevauchement entre les deux côtés. Outre le bloc CIDR où résident les serveurs, vous devez également vérifier les blocs CIDR utilisés par les plateformes de conteneurs, tels que le bloc CIDR du pont par défaut de Docker
172.17.0.0/16, ainsi que le bloc CIDR des Pods et le bloc CIDR des Services de Kubernetes. Ces blocs CIDR sont automatiquement alloués par les plateformes et ne figurent généralement pas dans la liste de contrôle de planification réseau ; ils sont donc souvent négligés. Le trafic dont l'adresse de destination se situe dans la plage de chevauchement est prioritairement acheminé vers l'interface locale par le routage local et n'entre pas dans le tunnel IPsec. Par conséquent, la négociation de la connexion IPsec-VPN aboutit, mais le client local ne peut pas communiquer avec les instances ECS du VPC, ou la commandepingéchoue. En cas de chevauchement, ajustez la planification des blocs CIDR côté centre de données local ou côté plateforme de conteneurs afin qu'elle n'entre pas en conflit avec le bloc CIDR du VPC.
-
Routes CEN dans les scénarios inter-VPC (utilisation conjointe de CEN et VPN) : L'instance ECS à laquelle vous souhaitez accéder se trouve-t-elle dans un VPC autre que celui associé à la connexion IPsec ?
Action : Si la connexion IPsec est associée au VPC A, mais que l'instance ECS cible se trouve dans le VPC B, lequel communique avec le VPC A via un Cloud Enterprise Network (CEN), la simple configuration des routes côté VPN ne suffit pas pour assurer la connectivité de bout en bout. Vous devez également vérifier la publicité des routes dans CEN : assurez-vous que les routes requises pour la communication entre le bloc CIDR du centre de données local et le bloc CIDR du VPC B existent déjà dans la table de routage CEN et ont été publiées, afin que le trafic de retour du VPC B puisse revenir vers le VPC A via CEN et entrer dans le tunnel IPsec. Lorsque les routes pertinentes sont manquantes ou non publiées, la négociation de la connexion IPsec-VPN aboutit, le centre de données local communique normalement avec les instances ECS du VPC A, mais ne peut pas communiquer avec les instances ECS du VPC B, ou la commande
pingéchoue.
2. Affichage des informations d'erreur
Si la liste de contrôle rapide ne résout pas le problème, vous pouvez consulter les codes d'erreur spécifiques ou les informations de journalisation pour identifier l'origine du dysfonctionnement.
2,1 Affichage des codes d'erreur
Les codes d'erreur fournissent des indices directs pour le dépannage.
Pour obtenir le dernier statut d'erreur, vous pouvez déclencher une nouvelle négociation. Une méthode simple consiste à modifier la connexion IPsec, à basculer la valeur de Effective Immediately , à enregistrer la modification, puis à rétablir la valeur d'origine.
Les passerelles VPN créées avant le 21 mars 2019 doivent être mises à niveau avant que vous ne puissiez afficher les codes d'erreur.
Console
Consultez le code d'erreur dans la colonne Connection Status du tunnel cible.
Pour le mode à tunnel unique : Consultez le code d'erreur dans la colonne Connection Status de la connexion IPsec-VPN cible.
API
Appelez l'opération DiagnoseVpnConnections pour récupérer le code d'erreur.
2,2 Affichage des journaux
Pour une analyse plus détaillée, en particulier lorsqu'aucun code d'erreur n'est affiché, vous pouvez consulter jusqu'à 180 jours de journaux IPsec-VPN. Vous pouvez filtrer les journaux selon une plage horaire spécifique (minimum 10 minutes).
Console
Cliquez sur View Logs dans la colonne Actions du tunnel cible.
Pour le mode à tunnel unique : Cliquez sur View Logs dans la colonne Actions de la connexion IPsec cible.
API
Appelez l'opération DescribeVpnConnectionLogs pour récupérer les journaux.
3. Trouver une solution pour votre scénario
Identifiez votre problème spécifique dans les catégories suivantes et reportez-vous à la solution correspondante.
a. Échec ou expiration du délai de la négociation de phase 1
Il s'agit du problème le plus fréquent. Cela signifie que la passerelle VPN Alibaba Cloud a envoyé une demande de négociation mais n'a reçu aucune réponse de la part de l'appareil de passerelle sur site.
Cause possible | Méthode de dépannage |
1. Problèmes de connectivité réseau | Vérification : Sur votre appareil de passerelle sur site, exécutez les commandes Solution : En cas de perte de paquets, un problème réseau existe entre votre centre de données et Alibaba Cloud. Vérifiez votre connexion Internet, votre fournisseur d'accès Internet (FAI) et tous les pare-feu intermédiaires. VPN Gateway ne prend pas en charge les connexions IPsec-VPN transfrontalières. Pour créer une connexion transfrontalière, utilisez Cloud Enterprise Network (CEN). |
2. Adresse IP de la passerelle client incorrecte | Vérification : Dans la console de gestion Alibaba Cloud, confirmez l'adresse IP de la passerelle client. Solution : Cette adresse IP doit être l'adresse IP publique que l'appareil de passerelle sur site utilise pour se connecter à Internet. Si l'appareil de passerelle sur site se trouve derrière un appareil NAT, cette adresse IP doit être l'adresse IP publique de l'appareil NAT. Remarque : Pour modifier l'adresse IP d'une passerelle client, vous devez créer une nouvelle passerelle client et la réassocier à la connexion IPsec-VPN. Cette opération entraîne une interruption de service. |
3. Le pare-feu distant bloque les paquets | Vérification : Vérifiez les politiques de contrôle d'accès de l'appareil de passerelle sur site et de son pare-feu en amont. Solution : Assurez-vous que le trafic vers et depuis l'adresse IP publique de la passerelle VPN Alibaba Cloud est autorisé sur le port UDP 500 (pour IKE) et le port UDP 4500 (pour la traversée NAT). |
4. Incompatibilité des politiques IKE (phase 1) | Vérification : Comparez les configurations IKE aux deux extrémités. Solution : Assurez-vous que les paramètres suivants sont identiques : - Version IKE ( - Mode de négociation ( - Algorithme de chiffrement (tel que - Algorithme d'authentification (tel que - Groupe DH (tel que - Durée de vie de l'association de sécurité (SA) (secondes). Nous vous recommandons de conserver cette valeur cohérente afin d'éviter toute instabilité. |
5. Problèmes liés à l'appareil de passerelle sur site | Vérification : Vérifiez l'état et les journaux de l'appareil de passerelle sur site pour détecter d'éventuelles erreurs ou redémarrages inattendus. Solution : Assurez-vous que l'appareil fonctionne correctement et que le service IPsec est en cours d'exécution. Pour des exemples de configuration, consultez Configurer les appareils sur site. Certains appareils nécessitent un trafic de données pour déclencher la négociation du protocole IPsec. Contactez le fournisseur de l'appareil pour savoir comment la déclencher. |
6. Divers | Pour plus d'informations, consultez l'Annexe : Codes d'erreur et mots-clés des journaux. |
b. Échec ou expiration du délai de la négociation de phase 2
Référence rapide :
La négociation de phase 2 réussissait auparavant, mais échoue désormais systématiquement ?
-
L'état de la négociation passe-t-il par intermittence à « Échec » ?
L'état de la négociation passe-t-il par intermittence à « Échec » ?
La négociation échoue-t-elle systématiquement ?
Cause possible | Méthode de dépannage |
1. Incompatibilité des politiques IPsec (phase 2) | Vérification : Comparez les configurations IPsec aux deux extrémités. Solution : Assurez-vous que les paramètres suivants sont identiques : - Algorithme de chiffrement (tel que - Algorithme d'authentification (tel que - Groupe DH (Perfect Forward Secrecy - PFS) : Si une extrémité active le PFS, l'autre extrémité doit également l'activer et utiliser le même groupe DH. Si une extrémité est définie sur |
2. Le sélecteur de trafic est correctement configuré, mais la négociation échoue toujours | Vérification : Vérifiez la configuration du sélecteur de trafic de l'appareil distant et confirmez que son bloc CIDR local correspond au bloc CIDR distant de la connexion IPsec côté Alibaba Cloud, et que son bloc CIDR distant correspond au bloc CIDR local de la connexion IPsec côté Alibaba Cloud. Solution : Après avoir confirmé que les sélecteurs de trafic aux deux extrémités correspondent aux blocs CIDR distants respectifs, vérifiez si les configurations de routage des deux côtés sont correctes et testez la connectivité. |
3. Autre | Pour plus d'informations, consultez l'Annexe : Codes d'erreur et mots-clés des journaux. |
La négociation de phase 2 réussissait auparavant, mais échoue désormais systématiquement ?
Catégorie de cause | Cause | Solution |
Anomalie de la passerelle | L'instance de passerelle VPN Alibaba Cloud présente un impayé. | Ajoutez des fonds à votre compte ou ajoutez un nouveau mode de paiement. Pour plus d'informations, consultez Modes de paiement. |
L'appareil de passerelle sur site est anormal. | Dépannez l'appareil de passerelle sur site. Pour plus d'informations, contactez le fournisseur de l'appareil. | |
La politique de contrôle d'accès de l'appareil de passerelle sur site a changé. | Vérifiez la politique de contrôle d'accès de l'appareil de passerelle sur site pour vous assurer que le trafic est autorisé entre le centre de données et le VPC. | |
Modification de la configuration IPsec-VPN | La configuration IPsec-VPN a été supprimée de l'appareil de passerelle sur site. | Ajoutez à nouveau la configuration IPsec-VPN à l'appareil de passerelle sur site. Assurez-vous que la configuration de l'appareil de passerelle sur site est cohérente avec celle de la connexion IPsec-VPN. Pour certains exemples, consultez Configurer les appareils sur site. |
La configuration IPsec-VPN sur l'appareil de passerelle sur site a été modifiée et n'est plus cohérente avec les paramètres de la connexion IPsec-VPN. | Modifiez la configuration de l'appareil de passerelle sur site pour la rendre cohérente avec celle de la connexion IPsec. | |
Dans la configuration IPsec-VPN de l'appareil de passerelle sur site, un paramètre est spécifié avec plusieurs valeurs. Par exemple, lors de la configuration de l'appareil de passerelle sur site, l'algorithme de chiffrement dans la phase de configuration IKE est spécifié comme étant aes et aes192. | Lors de la configuration d'une connexion IPsec côté Alibaba Cloud, chaque paramètre ne prend en charge qu'une seule valeur. Vérifiez la configuration IPsec-VPN de l'appareil de passerelle sur site pour vous assurer que chaque paramètre est également spécifié avec une seule valeur et qu'elle est identique à celle de la connexion IPsec. | |
La configuration de la connexion IPsec a été modifiée et n'est plus cohérente avec l'appareil de passerelle sur site. | Vérifiez la configuration de la connexion IPsec pour la rendre cohérente avec celle de l'appareil de passerelle sur site. Pour plus d'informations, consultez Connexion IPsec. | |
Une passerelle IPv4 et une liste de contrôle d'accès réseau (ACL) ont été nouvellement configurées pour l'instance VPC associée à la connexion IPsec. | Vérifiez les configurations de la passerelle IPv4 et de la liste ACL appliquées à l'instance VPC pour autoriser le trafic entre le centre de données sur site et l'instance VPC. Pour plus d'informations, consultez Passerelle IPv4 et Listes de contrôle d'accès réseau. | |
L'adresse IP de l'appareil de passerelle sur site change | L'adresse IP utilisée par l'appareil de passerelle sur site pour établir la connexion IPsec-VPN a changé, ce qui rend l'adresse IP de l'instance de passerelle client côté Alibaba Cloud incohérente avec l'adresse IP utilisée par l'appareil de passerelle sur site. | Assurez-vous que l'adresse IP utilisée par l'appareil de passerelle sur site pour établir la connexion IPsec-VPN est identique à l'adresse IP configurée pour l'instance de passerelle client côté Alibaba Cloud. |
L'appareil de passerelle sur site possède plusieurs adresses IP et l'adresse IP de l'instance de passerelle client côté Alibaba Cloud est incohérente avec l'adresse IP utilisée par l'appareil de passerelle sur site pour établir la connexion IPsec-VPN. | Assurez-vous que l'adresse IP utilisée par l'appareil de passerelle sur site pour établir la connexion IPsec-VPN est identique à l'adresse IP configurée pour l'instance de passerelle client côté Alibaba Cloud. | |
L'appareil de passerelle sur site utilise une adresse IP dynamique et l'adresse IP de l'instance de passerelle client côté Alibaba Cloud est incohérente avec l'adresse IP utilisée par l'appareil de passerelle sur site pour établir la connexion IPsec-VPN. | L'appareil de passerelle sur site doit utiliser une adresse IP statique pour établir la connexion IPsec-VPN. Assurez-vous que l'adresse IP statique utilisée par l'appareil de passerelle sur site est identique à l'adresse IP configurée pour l'instance de passerelle client côté Alibaba Cloud. |
L'état de la négociation passe-t-il par intermittence à « Échec » ?
Catégorie de cause | Cause | Solution |
Modification de la configuration IPsec-VPN | La configuration du paramètre groupe DH (appelé PFS sur certains appareils de passerelle sur site) dans la phase de configuration IPsec est incohérente entre la connexion IPsec et son appareil de passerelle sur site. | Vérifiez la configuration du paramètre groupe DH (PFS) dans la phase de configuration IPsec de la connexion IPsec ou de l'appareil de passerelle sur site, afin que les valeurs du paramètre groupe DH (PFS) soient configurées de manière identique aux deux extrémités. Pour la méthode de configuration, consultez Connexion IPsec. |
Dans la configuration IPsec-VPN de l'appareil de passerelle sur site, un paramètre est spécifié avec plusieurs valeurs. Par exemple, lors de la configuration de l'appareil de passerelle sur site, l'algorithme de chiffrement dans la phase de configuration IKE est spécifié comme étant aes et aes192. | Lors de la configuration d'une connexion IPsec côté Alibaba Cloud :
| |
L'appareil de passerelle sur site est configuré avec une durée de vie SA basée sur le trafic. | La connexion IPsec côté Alibaba Cloud ne prend pas en charge la configuration d'une durée de vie SA basée sur le trafic ; elle prend uniquement en charge la configuration d'une durée de vie SA basée sur le temps. Nous vous recommandons de ne pas configurer de durée de vie SA basée sur le trafic sur l'appareil de passerelle sur site, ou de définir la durée de vie SA basée sur le trafic sur 0 octet. | |
Mauvaise qualité du réseau | En raison d'une mauvaise qualité du réseau entre la connexion IPsec et l'appareil de passerelle sur site, les paquets du protocole DPD, les paquets de sondage de contrôle d'intégrité ou les paquets du protocole IPsec sont perdus puis expirent, ce qui entraîne l'interruption de la connexion IPsec-VPN. | Vérifiez la connectivité réseau au moment où la connexion IPsec-VPN a été interrompue. |
Limitation côté pair de la connexion IPsec | Le fournisseur distant de la connexion IPsec impose une limitation selon laquelle la négociation du protocole IPsec ne peut être déclenchée qu'en présence de trafic de données. | Confirmez si la passerelle VPN distante de la connexion IPsec présente cette limitation d'utilisation. Si cette limitation existe, consultez le fournisseur distant pour savoir comment déclencher la négociation du protocole IPsec. |
Lors de l'établissement d'une connexion IPsec-VPN en mode double tunnel, la connexion IPsec côté Alibaba Cloud utilise le mode sélecteur de trafic et les sélecteurs de trafic des deux tunnels sont identiques par défaut. L'appareil de passerelle sur site de la connexion IPsec peut présenter une limitation pertinente (par exemple, un appareil de pare-feu Cisco ASA). Lorsque les sélecteurs de trafic des deux tunnels sont identiques, un seul tunnel peut négocier avec succès et les deux tunnels négocient avec succès à tour de rôle. | Confirmez auprès du fournisseur concerné si l'appareil de passerelle sur site de la connexion IPsec présente cette limitation. Si cette limitation existe, consultez Configurer les appareils sur site pour modifier la configuration IPsec-VPN de l'appareil de passerelle sur site de la connexion IPsec. |
c. La négociation de phase 2 a réussi, mais une exception existe
Tableau de référence rapide :
L'état de négociation du protocole de routage BGP est-il « Anormal » ?
Les instances ECS du VPC ne peuvent-elles pas accéder aux serveurs du centre de données sur site ?
Les serveurs du centre de données sur site ne peuvent-ils pas accéder aux instances ECS du VPC ?
Le ping réussit, mais l'accès au service échoue ou l'accès à certains numéros de port échoue ?
L'accès au réseau privé est normal, mais la latence de transfert est élevée ?
Échec du contrôle d'intégrité (uniquement pour le mode tunnel unique) ?
L'état de négociation du protocole de routage BGP est-il « Anormal » ?
Catégorie de cause | Cause | Solution |
Configuration BGP incorrecte | L'appareil de passerelle sur site n'est pas configuré avec la bonne adresse IP BGP. | Vérifiez les configurations BGP de la connexion IPsec et de son appareil de passerelle sur site pour vous assurer que l'adresse IP BGP de la connexion IPsec et l'adresse IP BGP de l'appareil de passerelle sur site se trouvent dans le même bloc CIDR et n'entrent pas en conflit. Le bloc CIDR auquel appartiennent les adresses IP BGP doit être un bloc CIDR situé dans 169.254.0.0/16 avec une longueur de masque de sous-réseau de 30. |
Problèmes liés à la connexion IPsec-VPN | En raison d'une connectivité anormale de la connexion IPsec-VPN, le côté connexion IPsec ne peut pas recevoir les paquets du protocole BGP provenant de l'appareil de passerelle sur site. | Vérifiez la connectivité de la connexion IPsec-VPN et confirmez si le côté connexion IPsec a reçu les paquets du protocole BGP provenant de l'appareil de passerelle sur site. Vous pouvez afficher les données de surveillance du trafic sous la connexion IPsec. Si le système actuel n'a enregistré aucun trafic entrant, cela indique que le côté connexion IPsec n'a pas reçu les paquets du protocole BGP provenant de l'appareil de passerelle sur site. |
L'état de négociation de la connexion IPsec est interrompu. | Sur la base des journaux de la connexion IPsec, vérifiez si la connexion IPsec est toujours dans l'état « Négociation de phase 2 réussie ». Si l'état de négociation de la connexion IPsec est instable, résolvez le problème de connexion IPsec en vous basant sur les Codes d'erreur et mots-clés des journaux. |
Les instances ECS du VPC ne peuvent-elles pas accéder aux serveurs du centre de données sur site ?
Cause : La configuration de routage du VPC, les règles de groupe de sécurité ou la configuration de routage du centre de données sur site et les politiques de contrôle d'accès n'autorisent pas les instances ECS du VPC à accéder aux serveurs du centre de données sur site.
Solution : Consultez les informations suivantes pour dépanner la configuration concernée.
-
VPC
Vérifiez la configuration de routage dans la table de routage du VPC. Assurez-vous que les routes pertinentes sont configurées dans la table de routage du VPC afin que les instances ECS puissent accéder aux serveurs du centre de données sur site.
Vérifiez les règles de groupe de sécurité appliquées au VPC. Assurez-vous que les règles de groupe de sécurité autorisent l'accès mutuel entre les instances ECS et les serveurs.
-
Centre de données sur site
Vérifiez la configuration de routage du centre de données sur site. Assurez-vous que les routes pertinentes sont configurées dans le centre de données sur site afin que les serveurs puissent répondre aux instances ECS.
Vérifiez les politiques de contrôle d'accès du centre de données sur site. Assurez-vous que le centre de données sur site autorise l'accès mutuel entre les instances ECS et les serveurs.
Si des adresses IP publiques sont utilisées comme adresses IP privées au sein du centre de données sur site, vous devez définir le bloc CIDR des adresses IP publiques comme le bloc CIDR client du VPC pour garantir que le VPC puisse accéder au bloc CIDR public.
Les serveurs du centre de données local ne parviennent pas à accéder aux instances ECS dans le VPC ?
Cause : La configuration des routes du VPC, les règles de groupe de sécurité ou la configuration des routes et les politiques de contrôle d'accès du centre de données local n'autorisent pas les serveurs locaux à accéder aux instances ECS du VPC.
Solution : Consultez les informations suivantes pour diagnostiquer la configuration concernée.
-
VPC
Vérifiez la configuration des routes dans la table de routage du VPC. Assurez-vous que les routes pertinentes sont configurées afin que les instances ECS puissent répondre aux accès provenant des serveurs.
Contrôlez les règles de groupe de sécurité appliquées au VPC. Vérifiez qu'elles autorisent l'accès mutuel entre les instances ECS et les serveurs.
-
Centre de données local
Examinez la configuration des routes du centre de données local. Assurez-vous que les routes nécessaires sont présentes pour permettre aux serveurs d'accéder aux instances ECS via la connexion IPsec-VPN.
Vérifiez les politiques de contrôle d'accès du centre de données local. Confirmez que celles-ci autorisent l'accès mutuel entre les instances ECS et les serveurs.
Dans un scénario comportant plusieurs blocs CIDR, certains communiquent normalement tandis que d'autres échouent ?
Cause : Lorsqu'une connexion IPsec-VPN relie un centre de données local à un VPC, si la passerelle VPN interagit avec des équipements de fournisseurs traditionnels tels que Cisco, H3C et Huawei, et que la connexion IPsec utilise le mode de sélecteur de trafic (traffic selector) avec plusieurs blocs CIDR configurés, seul un bloc CIDR peut communiquer, tandis que les autres échouent.
Ce phénomène résulte d'une incompatibilité du protocole IPsec entre les deux extrémités lorsque la passerelle VPN Alibaba Cloud interagit avec des équipements de fournisseurs traditionnels (Cisco, H3C, Huawei). Avec plusieurs blocs CIDR configurés, la passerelle VPN Alibaba Cloud utilise une seule SA (Security Association) pour négocier avec l'équipement pair, alors que ce dernier utilise plusieurs SAs pour négocier avec la passerelle VPN.
Solution : Consultez les Solutions de configuration recommandées pour plusieurs blocs CIDR.
Le ping fonctionne mais l'accès au service échoue, ou l'accès à certains ports est impossible ?
Cause : Les règles de groupe de sécurité appliquées au VPC ou les politiques de contrôle d'accès du centre de données local n'autorisent pas les adresses IP, les types de protocole et les numéros de port correspondants.
Solution : Consultez les informations suivantes pour diagnostiquer la configuration concernée.
Vérifiez les règles de groupe de sécurité appliquées au VPC. Assurez-vous qu'elles autorisent les adresses IP, les types de protocole et les numéros de port nécessaires à la communication entre le centre de données local et le VPC.
-
Contrôlez les politiques de contrôle d'accès appliquées au centre de données local. Vérifiez qu'elles autorisent les adresses IP, les types de protocole et les numéros de port requis pour la communication entre le centre de données local et le VPC.
Si le côté du centre de données local comporte des configurations telles que des politiques de service ou de résolution de noms de domaine, nous vous recommandons de les vérifier également. Assurez-vous que les adresses IP, les types de protocole et les numéros de port nécessaires à la communication entre le centre de données local et le VPC sont autorisés.
Pourquoi traceroute depuis le site local n'atteint pas le cloud, alors que le ping réussit ?
Cause
traceroute et ping utilisent différents types de paquets ICMP, et les équipements réseau intermédiaires peuvent leur appliquer des politiques de traitement distinctes :
ping utilise des requêtes/réponses ICMP Echo pour tester directement l'accessibilité de bout en bout de la cible.
traceroute s'appuie sur les messages ICMP Time Exceeded (notification de délai dépassé renvoyée par les équipements intermédiaires lorsque le TTL du paquet atteint 0) pour tracer le chemin saut par saut.
Si le pare-feu de sortie ou le routeur du site local est configuré avec une politique de sécurité interdisant les messages ICMP Time Exceeded (ou le port UDP utilisé par traceroute), le traçage du chemin sera interrompu à ce nœud. Toutefois, les paquets ICMP Echo de ping ne sont pas bloqués, ce qui explique la réussite du ping. Cette différence de politique des équipements intermédiaires n'indique pas un problème au niveau du tunnel VPN ou de l'hôte cible.
Suggestions de dépannage
Vérifiez la politique de sécurité de l'équipement de sortie du site local pour confirmer s'il restreint les messages ICMP Time Exceeded ou les ports UDP (traceroute commence par défaut sur le port UDP 33434 ; certains outils permettent de basculer en mode ICMP).
-
Validez la connectivité réseau segment par segment :
Depuis l'équipement local, exécutez un ping vers l'adresse IP publique de la passerelle VPN Alibaba Cloud (pour valider la connectivité entre la sortie Internet et la passerelle VPN).
Depuis l'équipement local, exécutez un ping vers l'adresse IP privée au sein du VPC Alibaba Cloud (pour valider la connectivité du canal interne du tunnel VPN).
Si vous devez confirmer la disponibilité de l'outil de traçage de chemin, exécutez traceroute en sens inverse depuis une instance ECS dans le cloud vers l'IP locale, puis comparez les résultats bidirectionnels.
Des pertes de paquets surviennent lors de l'accès au réseau privé et la connectivité est intermittente ?
Catégorie de cause | Cause | Solution |
Problème lié aux spécifications de la passerelle VPN | Lors de la communication du trafic, une pointe de trafic dépasse la spécification de bande passante de l'instance de passerelle VPN. Vous pouvez consulter les informations de surveillance du trafic de l'instance de passerelle VPN dans la console de gestion VPN Gateway pour confirmer la survenue d'une pointe de trafic. | Vous pouvez mettre à niveau l'instance de passerelle VPN ou effectuer une mise à niveau temporaire. Pour plus d'informations, consultez Redimensionnement et renouvellementRedimensionnement (Standard VPNGW uniquement). |
Problèmes liés à la connexion IPsec-VPN | Le statut de négociation de la connexion IPsec est interrompu. | Sur la base des informations de journal de la connexion IPsec, vérifiez si la connexion IPsec reste toujours dans l'état « Négociation de la phase 2 réussie ». Si le statut de négociation de la connexion IPsec est instable et que le tunnel renégocie fréquemment, provoquant des interruptions réseau intermittentes, résolvez le problème de connexion IPsec en vous appuyant sur les Codes d'erreur et mots-clés de journal. |
Problèmes liés au MTU | Le MTU utilisateur du centre de données local est configuré à une valeur supérieure à 1 300 octets (hors 1 300 octets). | Pour les passerelles VPN créées avant le 1er avril 2021, si le MTU utilisateur du centre de données local est configuré à une valeur supérieure à 1 300 octets (hors 1 300 octets), la connexion IPsec-VPN peut ne pas fonctionner. Nous vous recommandons de mettre à niveau la passerelle VPN vers la dernière version pour éviter ce problème. |
Lors de la transmission du trafic, le paquet est trop volumineux et dépasse la valeur MTU du chemin de transmission, ce qui entraîne une fragmentation du paquet pour la transmission. | La passerelle VPN prend uniquement en charge la transmission de paquets déjà fragmentés et ne prend pas en charge la fragmentation des paquets ni le réassemblage des fragments. Nous vous recommandons de définir le MTU utilisateur à 1 399 octets. Pour plus d'informations, consultez Configuration des MTU. |
L'accès au réseau privé fonctionne normalement, mais la latence de transfert est élevée ?
|
Catégorie de cause |
Cause |
Solution |
|
Problème lié aux spécifications de la passerelle VPN |
Lors de la communication du trafic, une pointe de trafic dépasse la spécification de bande passante de l'instance de passerelle VPN. Vous pouvez consulter les informations de surveillance du trafic de l'instance de passerelle VPN dans la console de gestion VPN Gateway pour confirmer la survenue d'une pointe de trafic. |
Vous pouvez mettre à niveau l'instance de passerelle VPN ou effectuer une mise à niveau temporaire. Pour plus d'informations, consultez Redimensionnement et renouvellementRedimensionnement (Standard VPNGW uniquement). |
|
Mauvaise qualité du réseau |
En raison d'une mauvaise qualité du réseau entre la connexion IPsec et l'équipement de passerelle local, une latence réseau élevée et des pertes de paquets surviennent lors de la communication du trafic. |
Utilisez les commandes |
Les sélecteurs de trafic configurés dans le cloud et sur site sont différents, mais la connexion IPsec-VPN parvient tout de même à négocier avec succès ?
Cause :
Comme illustré dans la figure ci-dessous, si le bloc CIDR du sélecteur de trafic configuré sur l'équipement de passerelle local et celui configuré sur la connexion IPsec ont une relation d'inclusion, et que les deux extrémités utilisent la version IKEv2, la passerelle VPN Alibaba Cloud considère lors de la négociation IPsec que les sélecteurs de trafic des deux côtés correspondent. Si l'équipement de passerelle local prend également en charge la relation d'inclusion (c'est-à-dire qu'il considère que les sélecteurs de trafic ayant une relation d'inclusion se correspondent), alors il est possible que les sélecteurs de trafic configurés dans le cloud et sur site soient différents, tout en permettant une négociation réussie de la connexion IPsec-VPN.
Par exemple, l'équipement de passerelle local 1 prend en charge la relation d'inclusion. Lorsque l'équipement de passerelle local 1 négocie avec la connexion IPsec 1 et la connexion IPsec 2, le bloc CIDR local 10.55.0.0/16 de l'équipement de passerelle local 1 inclut le bloc CIDR distant 10.55.193.0/24 de la connexion IPsec 1 et le bloc CIDR distant 10.55.0.0/16 de la connexion IPsec 2 ; le bloc CIDR distant 10.66.88.0/22 de l'équipement de passerelle local 1 inclut le bloc CIDR local 10.66.90.0/24 de la connexion IPsec 1 et le bloc CIDR local 10.66.89.0/24 de la connexion IPsec 2. Par conséquent, l'équipement de passerelle local 1 et la passerelle VPN Alibaba Cloud considèrent tous deux que les sélecteurs de trafic se correspondent, et l'équipement de passerelle local 1 peut négocier avec succès avec la connexion IPsec 1 et la connexion IPsec 2.
Si l'équipement de passerelle local ne prend pas en charge la relation d'inclusion (c'est-à-dire qu'il considère que les sélecteurs de trafic ayant une relation d'inclusion ne se correspondent pas), la connexion IPsec-VPN ne pourra pas négocier avec succès. Confirmez auprès du fournisseur de l'équipement de passerelle local si celui-ci prend en charge la relation d'inclusion.
Si l'équipement de passerelle local et la connexion IPsec utilisent tous deux la version IKEv1, les sélecteurs de trafic des deux extrémités doivent être strictement identiques (aucune relation d'inclusion n'est autorisée) pour que la connexion IPsec-VPN puisse négocier avec succès.
Impact possible :
Comme indiqué dans la figure précédente, si plusieurs connexions IPsec existent sous une même instance de passerelle VPN et que les blocs CIDR des sélecteurs de trafic de ces connexions ont une relation d'inclusion, le trafic peut ne pas être acheminé selon le chemin attendu.
Pour une connexion IPsec configurée en mode sélecteur de trafic, après la création de la connexion, le système ajoute par défaut les routes pertinentes à la table de routage basée sur des politiques de l'instance de passerelle VPN, et chaque route possède la même priorité de politique. Dans le scénario illustré ci-dessus, le système ajoute par défaut les routes suivantes à la table de routage basée sur des politiques de l'instance de passerelle VPN :
|
Nom de l'entrée de route |
Bloc CIDR source |
Bloc CIDR de destination |
Saut suivant |
Poids |
Priorité de politique |
|
Entrée de route 1 |
10.66.90.0/24 |
10.55.193.0/24 |
Connexion IPsec 1 |
100 |
10 |
|
Entrée de route 2 |
10.66.89.0/24 |
10.55.0.0/16 |
Connexion IPsec 2 |
100 |
10 |
|
Entrée de route 3 |
10.66.90.0/24 |
10.55.178.0/24 |
Connexion IPsec 3 |
100 |
10 |
|
Entrée de route 4 |
10.66.88.0/24 |
10.55.0.0/16 |
Connexion IPsec 4 |
100 |
10 |
Selon les Règles de correspondance des routes basées sur des politiques, dans un scénario où les priorités de politique sont identiques, le système fait correspondre les routes une par une dans l'ordre des routes basées sur des politiques. Dès qu'une route basée sur une politique est associée, le trafic est immédiatement transféré selon cette politique. L'ordre des routes basées sur des politiques est déterminé par le moment où elles sont transmises au système. Généralement, la route basée sur une politique configurée en premier est transmise en priorité au système, mais cela ne peut être entièrement garanti dans la situation actuelle. Par conséquent, une route basée sur une politique configurée ultérieurement peut être transmise en priorité au système, ce qui entraîne une priorité plus élevée pour cette route par rapport à celle configurée précédemment.
Dans le scénario illustré ci-dessus, il est possible que le centre de données local envoie des paquets de requête vers le VPC via la connexion IPsec-VPN 1, tandis que le VPC renvoie des paquets de réponse vers le centre de données local via la connexion IPsec-VPN 4, car l'entrée de route 4 peut être transmise en priorité au système, lui conférant une priorité supérieure à celle de l'entrée de route 1.
Solution :
Évitez d'ajouter des blocs CIDR de sélecteur de trafic ayant une relation d'inclusion pour l'équipement de passerelle local et la connexion IPsec. Nous vous recommandons d'ajouter des blocs CIDR de sélecteur de trafic correspondant exactement pour les deux extrémités. Cette méthode permet d'améliorer la stabilité de la connexion IPsec-VPN.
Lors de la création d'une connexion IPsec, ajoutez autant que possible des blocs CIDR de sélecteur de trafic précis afin de garantir que les blocs CIDR des sélecteurs de trafic de plusieurs connexions IPsec sous l'instance de passerelle VPN ne se chevauchent pas.
-
Configurez une priorité de politique et une valeur de poids différentes pour chaque route basée sur une politique afin de garantir que le trafic ne corresponde qu'à une seule route basée sur une politique.
Si votre instance de passerelle VPN ne prend pas en charge la configuration de la priorité de politique, vous pouvez mettre à niveau l'instance de passerelle VPN. Après la mise à niveau, l'instance de passerelle VPN prend en charge par défaut la configuration de la priorité de politique pour les routes basées sur des politiques.
Que faire si AD Connector ou la résolution DNS échoue après la connexion du tunnel IPsec ?
Cause : Lorsque le test ping du tunnel IPsec est normal et que la configuration de résolution de nom de domaine est correcte, la panne peut ne pas se situer au niveau du tunnel. Si le port UDP 53 sous-jacent est bloqué par un pare-feu local ou une politique de sécurité, la communication DNS sera bloquée, ce qui peut entraîner un échec de connexion AD Connector ou un délai d'attente RPC (Erreur 1818).
Solution :
Vérifiez et autorisez le port UDP 53 du serveur DNS du centre de données local (en fonction de l'adresse IP du serveur DNS dans l'environnement réel) afin de garantir que les ressources cloud puissent communiquer avec le DNS local via ce port.
Lors de la synchronisation d'un contrôleur de domaine Windows AD dans un environnement CEN+VPN inter-cloud, diagnostiquez le taux de perte de paquets et la latence des pings longs bidirectionnels, et capturez simultanément les paquets aux extrémités cloud et locale pour analyse si nécessaire.
Quelles sont les causes d'une durée de basculement du tunnel IPsec prolongée ?
Cause : Le temps total consommé par le basculement du tunnel dépend non seulement de la vitesse de commutation de l'instance de passerelle VPN Alibaba Cloud, mais aussi du mécanisme de détection des pannes et de commutation de l'appareil VPN local. Même si le tunnel de secours côté Alibaba Cloud est actif, l'appareil local peut ne pas avoir terminé la commutation en raison de configurations telles que le délai d'expiration du battement de cœur (heartbeat timeout) et l'intervalle de sondage, ce qui se traduit par un temps de récupération de bout en bout nettement plus long que prévu (par exemple, une récupération prenant environ 10 minutes).
Suggestions de dépannage :
Vérifiez séparément l'état et les journaux de l'instance de passerelle VPN Alibaba Cloud et de l'appareil VPN local.
Confirmez le point temporel effectif réel du tunnel de secours et le moment où le chemin du trafic termine la commutation.
Comparez ces deux points temporels pour évaluer si le temps supplémentaire est dû à la politique de sondage et de commutation de l'appareil local.
Échec de la vérification d'état (uniquement pour le mode à tunnel unique) ?
Catégorie de cause | Cause | Solution |
Problème lié à l'adresse IP cible de la vérification d'état | L'adresse IP cible de la vérification d'état est inaccessible. | Sur l'hôte associé à l'adresse IP cible, utilisez l'adresse IP cible pour accéder à l'adresse IP source de la vérification d'état via la commande |
L'hôte associé à l'adresse IP cible de la vérification d'état fonctionne anormalement et ne peut pas répondre à temps aux paquets de sondage (paquets ICMP) envoyés par la connexion IPsec. | Vérifiez si l'hôte associé à l'adresse IP cible fonctionne normalement. Pour plus d'informations, consultez le fournisseur de l'équipement de passerelle. | |
La configuration des routes et la politique de sécurité associées à l'adresse IP cible de la vérification d'état ont changé. Par exemple, la politique de sécurité n'autorise pas les paquets provenant de l'adresse IP source de la vérification d'état, de l'adresse IP cible ou du type de protocole ICMP. | Côté équipement de passerelle local, vérifiez la configuration des routes et la politique de sécurité associées à l'adresse IP cible pour garantir que :
| |
L'adresse IP cible de la vérification d'état ne répond pas aux paquets de sondage de la vérification d'état provenant du chemin d'origine (le chemin par lequel l'adresse IP cible reçoit les paquets de sondage). | Utilisez la commande | |
Problèmes liés à la connexion IPsec-VPN | Le statut de négociation de la connexion IPsec est interrompu. | Sur la base des journaux de la connexion IPsec, vérifiez si la connexion IPsec reste toujours dans l'état « Négociation de la phase 2 réussie ». Si le statut de négociation de la connexion IPsec est instable, résolvez le problème de connexion IPsec en vous appuyant sur les Codes d'erreur et mots-clés de journal. Remarque : Après l'échec de la vérification d'état de la connexion IPsec, le système réinitialise le tunnel IPsec. Dans les scénarios d'application autres que les connexions IPsec-VPN actif/passif, nous ne recommandons pas de configurer la vérification d'état pour la connexion IPsec. |