Dépannage de la connectivité de site IPsec

Vue d'ensemble

La connectivité est primordiale pour l'accès au réseau étendu via le cloud Cato pour les réseaux derrière un IPsec. Le manque de connectivité d'un site IPsec peut perturber les fonctions commerciales. Ce guide vise à orienter le dépannage dans ce scénario.

Symptômes

Une panne de connectivité IPsec peut être déterminée de la manière suivante. Un administrateur peut noter les symptômes suivants :

• Le site IPsec est déconnecté dans le CMA 
  
• Historique d'instabilité dans la connexion
• Mauvaise performance pour le trafic traversant la connexion IPsec

Causes possibles

Voici des causes possibles que vous pouvez identifier lors du dépannage.

• Connectivité des pairs
  • Cela inclut la capacité des pairs à se joindre de manière cohérente sur une couche sous-jacente L3.
• Inadéquation de configuration IPsec
  • Les ensembles de transformation ou les inadéquations d'authentification peuvent empêcher la formation des tunnels ou provoquer leur échec avant qu'une nouvelle clé ne puisse être complétée
• Performance de la couche sous-jacente
  • IPsec repose sur une connexion sous-jacente stable pour une performance satisfaisante à l'intérieur du tunnel.

Dépannage du problème

Les étapes pour dépanner les symptômes qu'un administrateur peut rencontrer sont énumérées ci-dessous. Ces étapes visent à identifier les causes possibles des problèmes rencontrés. Les étapes de résolution seront mises en évidence plus tard dans le guide.

Dépannage d'un site IPsec déconnecté ou instable dans le CMA

Collecte d'informations à partir des événements

En utilisant la page Accueil > Événements dans le CMA, un administrateur peut rapidement obtenir un historique des événements de connectivité pour les sites IPsec au sein d'un compte. Les événements peuvent être filtrés jusqu'aux événements pertinents en sélectionnant le preset 'État de connectivité des sites' ou en filtrant par type d'événement 'Connectivité' et sous-type 'Déconnecté'. Vous pouvez également filtrer par le nom du site en question avec le champ 'Site source' ou utiliser la valeur du protocole tunnel 'IPSEC' pour filtrer tous les sites IPsec.

Voir l'horodatage de l'événement de déconnexion pertinent depuis le site en question peut aider à focaliser l'enquête. Y a-t-il eu d'autres événements de réseau plus larges ou des événements de puissance locale connus pour s'être produits à cet horodatage ? Y a-t-il des changements dans la piste d'audit préalables à cela qui pourraient être corrélés ?

Si aucun événement de déconnexion n'est trouvé et que le tunnel est toujours signalé comme instable, il est possible que le problème survienne lors du processus de nouvelle clé à cause de paramètres inadéquats entre Cato et le pair distant. Continuez avec les étapes ci-dessous pour une analyse plus approfondie.

Voir l'historique de connexion IPsec du site

La chronologie disponible dans Réseau > Site > Configuration du site > IPsec est essentielle pour résoudre les problèmes des sites IPsec déconnectés.

IMPORTANT : Si ce fichier n'est pas disponible dans le CMA (fichier non trouvé), cela signifie que Phase1 (ou IKE_SA dans IKEv2) n'a pas été négociée avec le pair distant. Confirmez que les paramètres IKE et d'authentification correspondent entre les deux pairs.

Le CSV fourni par le bouton Chronologie donnera un historique des journaux de tunnels pertinents. Ces journaux peuvent fournir des indications claires sur les problèmes pouvant causer le manque de connectivité dans la connexion IPsec. Des exemples courants de messages indicatifs sont les suivants :

Les messages suggérant que les sélecteurs de trafic ne correspondent pas sont la preuve d'une inadéquation de configuration entre les paramètres de phase 2 des pairs, en particulier en ce qui concerne les sous-réseaux disponibles de chaque côté du jumelage IPsec. Si vous voyez des erreurs suggérant que c'est le cas, naviguez vers la page Résolution d'une inadéquation de configuration IPsec.

Les messages ci-dessus indiquent également une inadéquation de configuration, cette fois avec les charges d'authentification. Bien sûr, le PSK doit correspondre à ces charges pour que la connexion soit réussie. Si cela est évident dans toute tentative de connexion, naviguez vers la page Résolution d'une inadéquation de configuration IPsec.

La chronologie ci-dessus montre une tentative de connexion avec un pair configuré, qui n'a reçu aucune réponse. Il peut être vu dans cette chronologie qu'aucune interaction avec le pair n'a eu lieu, et que la SA a été fermée en raison de l'inactivité. Cela est généralement le cas lorsque la connectivité L3 au pair distant est absente. Dans ces cas, consultez la page Résolution de la connectivité des pairs.

Vous pouvez trouver une liste complète de messages d'erreur possibles de chronologie pour IKEv1 et IKEv2 ici.

Utilisation des captures de paquets pour le dépannage

Remarque : lors de la prise de captures de paquets, l'IP PoP que vous avez configurée pour le tunnel sera masquée derrière une IP interne 10.x.y.z.

Également dans la page Réseau > Site > Configuration du site > IPsec se trouve l'outil de capture de paquets. Cela permettra de fournir des traces de paquets du trafic de contrôle entre les pairs. Les problèmes mentionnés ci-dessus sont également représentés dans ces captures de paquets :

Pour les sous-réseaux inadéquates dans un ensemble de transformations, les paquets informatifs signaleront une erreur. Dans cet exemple IKEv2, le message informatif TS_UNACCEPTABLE est symptomatique d'une inadéquation de configuration au sein de l'ensemble de transformations.

Pour les paramètres inadéquates dans l'association de sécurité, l'un ou l'autre des pairs inclura une erreur dans la charge utile. Dans cet exemple IKEv2, l'erreur NO-PROPOSAL-CHOSEN indique clairement qu'un des algorithmes ou groupes DH configurés dans le CMA ne correspond pas à la configuration du pair distant. Cela peut se produire lors de l'établissement initial du tunnel ou du processus de nouvelle clé.

D'autres types de conflits de configuration sont également présentés dans la capture de paquets. Par exemple, la capture ci-dessous montre un autre exemple IKEv2, cette fois-ci avec un PSK utilisé pour l'authentification qui ne correspondait pas :

Dans l'un des cas ci-dessus ou dans d'autres indicateurs de conflit de configuration entre pairs dans IKEv1 ou IKEv2, consultez la page Résolution d'une inadéquation de configuration IPsec.

Les captures de paquets peuvent également aider à identifier les problèmes de connectivité au niveau IP avec les pairs. Dans l'exemple ci-dessous, la capture de paquets ne montre qu'un trafic unidirectionnel sortant, ce qui suggère que le pair est injoignable. Si un administrateur de dépannage constate un pair injoignable, rendez-vous à la page Résolution de la connectivité des pairs.

Résolution des problèmes de performances médiocres sur VPN

Si de mauvaises performances sont constatées sur le VPN, cela prend généralement la forme d'une perte de paquets, d'une latence élevée ou de déconnexions fréquentes.

La perte de paquets sera vue sur le trafic passant par le tunnel via les applications qu'il affecte et peut être confirmée en testant avec des sondes ICMP d'un hôte à un autre via la connexion IPsec.

La latence et les déconnexions du tunnel seront également évidentes dans la performance des applications et peuvent également être déterminées via la page Réseau > Surveillance du site > Analyse du réseau pour le site en question.

Si des problèmes de performance sont identifiés, consultez la page Résolution des performances de la couche sous-jacente.

Perte de paquets dans Azure IPSec

Lors de la configuration d'IPSec avec Azure, le débit du tunnel et le nombre de paquets par seconde (PPS) sont déterminés par le SKU de la passerelle VPN et les algorithmes de chiffrement utilisés. Par exemple, selon la documentation de Microsoft, la passerelle VpnGw3 Generation2, lorsqu'elle utilise GCMAES256, peut gérer jusqu'à 140 000 paquets par seconde (PPS).

Si le trafic dépasse ces seuils, Azure rejettera automatiquement les paquets excédentaires, ce qui peut entraîner une dégradation notable des performances. Un symptôme courant est une réduction du débit, qui peut apparaître dans l'analyse du réseau de CMA comme une baisse du volume de trafic. Cependant, un moyen plus précis de diagnostiquer cela est de surveiller directement les métriques de la passerelle VPN dans le portail Azure, qui fournit des informations en temps réel sur le débit du tunnel et les valeurs de PPS pour la connexion VPN affectée.

Pour atténuer ce problème, vous pouvez envisager de passer à un SKU de niveau IPsec supérieur ou de déployer un vSocket Azure, qui peuvent améliorer la capacité de votre tunnel VPN et éviter les pertes de paquets dues à une surcharge de trafic.

Résolution des problèmes découverts

Résolution de la connectivité des pairs

Dans les scénarios où le pair IPsec n'envoie pas de paquets au PoP, montré via des entrées de chronologie ou des captures de paquets, assurez-vous que le pair distant est configuré pour se connecter à la même adresse IP que celle allouée au tunnel dans le CMA.

Si cette configuration est confirmée, assurez-vous que le pair distant peut traverser des connexions limitées par NAT en répondant au trafic sur le port 4500 ainsi que sur le port 500. NAT-T (NAT Traversal) devrait être activé sur le pair distant.

Si l'appareil du pair distant est configuré pour répondre aux requêtes ICMP sur Internet, vous pouvez également tester son accessibilité générale en testant les requêtes ICMP à l'IP publique de l'appareil.

Recherchez des changements récents sur la page de statut de santé : Si le PoP rencontre des problèmes, cela peut affecter le tunnel IPsec (chaque tunnel est connecté à un emplacement Cato PoP). Vous pouvez surveiller la santé des PoP Cato sur la page de statut.

Si le pair distant est un fournisseur de cloud tel qu'Azure ou AWS, vous pouvez également vérifier leurs pages de statut.

Si le dispositif du pair est toujours inaccessible pour cette connexion IPsec, contactez l'administrateur pour vous assurer qu'il est accessible publiquement pour les connexions IPsec.

Résolution de la discordance de configuration IPsec

Assurez-vous que la configuration du pair pour le jeu de transformations correspond à celle configurée sur la page Site > IPsec .

Pour configurer le côté Cato de l'appariement afin de correspondre à un ensemble de transformations spécifique du pair, éditez la configuration comme décrit dans la documentation liée pour IKEv1 et IKEv2.

Les sous-réseaux inclus des deux côtés du tunnel doivent également correspondre, assurez-vous que c'est le cas. Certains fournisseurs exigent que tous les sous-réseaux inclus dans le jeu de transformations soient inclus dans un seul message de jeu de transformations. Si c'est le cas pour un pair, un administrateur devrait utiliser l'option de configuration avancée "IKEv2 Envoyer un seul TS par charge" sous Site > Configuration avancée. 

Résolution des performances de la couche sous-jacente

L'accent sur la résolution des performances de la couche sous-jacente est de rendre le rendu des performances contre le pair distant.

Testez la capacité du pair distant à pinger des serveurs web publics comme 8.8.8.8. Si le retard ou la perte de paquets est cohérente avec celle du tunnel, on peut conclure que le problème existe dans l'environnement du pair distant.

Soumission de cas au support Cato

Soumettez un ticket de support avec les résultats des étapes de dépannage ci-dessus. Veuillez inclure les informations suivantes dans le ticket :

• Entrées pertinentes de la chronologie avec des horodatages
• Captures de paquets pertinentes
• Confirmation des ensembles de transformations correspondants, y compris les associations de sous-réseaux et les paramètres d'authentification/chiffrement