Dépannage de la connectivité de tunnel de site Socket

Vue d'ensemble

La connectivité du site est primordiale pour que les hôtes derrière un socket aient accès au WAN via le cloud Cato. L'absence de connectivité d'un site peut perturber le fonctionnement de l'entreprise. Ce manuel a pour but de fournir des conseils sur le dépannage de ce scénario.

Symptômes

Une défaillance de la connectivité du socket peut se manifester de plusieurs manières. Un administrateur peut noter les symptômes suivants :

• Le site est déconnecté dans CMA 
• Site connecté à un PoP inattendu
  
• Network Analytics montre que le tunnel est instable

Causes possibles

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

• Pas de connectivité Socket
  
• Trafic DTLS unidirectionnel seulement
  
• Performance sous-jacente médiocre
  
• Restrictions de géolocalisation IP
• Configuration de sélection de PoP inappropriée
• Configuration du SLA à des lignes de base incorrectes
• Dispositif NAT devant le socket

Dépannage du problème

Les étapes pour résoudre les symptômes qu'un administrateur peut rencontrer sont répertorié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 manuel.

Dépannage du Site Déconnecté dans CMA

Rassembler des informations à partir des événements

En utilisant la page Accueil > Événements dans CMA, un administrateur peut rapidement obtenir un historique des événements de connectivité pour les sites d'un compte. Les événements peuvent être filtrés pour afficher des événements pertinents en sélectionnant le préréglage "Statut de connectivité des sites" ou en filtrant par type d'événement "Connectivité" et sous-type "Déconnecté" Vous pouvez également affiner le filtre par le nom du site en question à l'aide du champ 'Site source'.

Consulter l'horodatage de l'événement de déconnexion pertinent du site en question peut aider à axer l'enquête. Des événements de réseau plus larges ou des événements d'alimentation locaux sont-ils connus pour se produire à cet horodatage ? Y a-t-il des changements dans la trace d'audit qui précèdent cela et qui peuvent être corrélés ?

Vérification de la connectivité Socket

Veuillez consulter les Pré-requis de connexion du Socket Cato pour comprendre les exigences d'une connexion socket.

L'état de connectivité du socket peut être consulté via son WebUI local, voir Connexion au WebUI du Socket localement.. Pour qu'un socket soit connecté, le port WAN utilisé pour assurer la connexion au cloud Cato doit afficher une icône de statut verte. Un indicateur autre que le vert suggère un problème de connectivité. La signification des différentes couleurs des icônes de statut est décrite dans Comprendre les icônes d'état du lien

Pour une icône rouge, assurez-vous qu'il existe un lien physique fonctionnant entre le socket et le dispositif ISP. Cela inclut les câbles connectés en toute sécurité et les LED des ports qui s'allument comme prévu.

Un conflit IP sera également détecté par l'état de connectivité du socket. L'avertissement de conflit IP continuera d'être affiché pendant une période de 24 heures, à partir du moment où le conflit a été détecté pour la première fois comme expliqué dans cet article de la base de connaissances.

Confirmez que l'état de Récupération forcée via contournement Internet sous Outils est Normal. Le bouton 'Forcer le contournement' entraînera tout le trafic LAN à contourner Cato et détruira le tunnel Cato, montrant le site comme déconnecté dans CMA.

Si l'état de Récupération d'urgence est actif, quittez cet état en cliquant sur le bouton Exit Forced Bypass.

En cas de problème de connectivité, nous pouvons utiliser l'onglet Outils pour tester davantage. Pour se connecter à Cato, le socket nécessite un accès L3 aux adresses IP publiques de Cato. Utilisez l'outil ping pour garantir que ce Socket peut atteindre des adresses IP ou des domaines de Cato, ou des adresses IP connues comme 8.8.8.8 via le port WAN directement. Si aucune n'est accessible, veuillez consulter la section Résolution de l'absence de connectivité du Socket.

Exécution de la capture de paquets

Une capture de paquets peut également être effectuée pour s'assurer que la demande du Socket d'établir un tunnel DTLS vers le PoP est répondue. Lors de la capture sur le port WAN en question, des paquets bidirectionnels sur UDP/443 vers le PoP devraient être visibles. La capture d'écran suivante montre une poignée de main DTLS réussie et l'échange de paquets de Données d'application.

Si seuls des paquets DTLS sortants sont détectés ou si la poignée de main DTLS est incomplète, veuillez consulter Résolution de la poignée de main DTLS incomplète. 

Impossible d'établir un tunnel en raison d'un dispositif NAT devant le socket

Pour les Sockets qui utilisent plusieurs liaisons WAN, s'il y a un dispositif NAT entre le Socket et le PoP, il est possible qu'une ou plusieurs des liaisons WAN ne puissent pas se connecter au PoP. Cela peut créer des problèmes de connectivité, comme le statut HA du site Not Ready.

Le PoP utilise le port source de chaque connexion DTLS entrante pour connecter chaque lien WAN au même tunnel logique. Le dispositif NAT peut changer le port source et empêcher un lien WAN de se connecter au même tunnel logique que les autres liens WAN.

Échec des connexions DTLS avec les fournisseurs LTE/5G

Comme mentionné dans cette étude de cas, si des fournisseurs LTE/5G sont utilisés pour se connecter à Cato, l'ISP peut interférer avec la poignée de main DTLS sur le port UDP/443, ce qui peut être vu comme des données spécifiques au transporteur (par exemple, APN) pendant la poignée de main.

Même s'il y a une communication DTLS bidirectionnelle, la poignée de main n'est pas terminée ; par conséquent, le tunnel Cato ne s'établira pas. 

Pour résoudre ce problème, changez le port DTLS en UDP/1337, veuillez consulter Résolution de la poignée de main DTLS incomplète. 

Dépannage de la sélection inattendue de PoP

Vérifiez l'adresse IP de l'ISP et le PoP actuellement sélectionné

Sous surveillance, sélectionnez un site et ouvrez le volet Vue d'ensemble du site. Dans la section Sockets du site, cliquez sur 'Voir le journal' pour voir toutes les connexions récentes. Recherchez l'IP publique de l'ISP (IP distante) qui se connecte à Cato, ainsi que le nom de l'ISP et sa localisation. La colonne 'PoP' affichera le PoP actuel auquel le site est connecté.

Il est important de vérifier que la 'IP distante' et la localisation de l'ISP sont comme prévu et que l'ISP ne transporte pas la connexion à travers un emplacement inattendu. La localisation de l'ISP (ville) doit correspondre ou être proche du pays/ville spécifié dans les paramètres généraux du site au sein de CMA.

Vérifiez la configuration de sélection de PoP sur CMA

Une localisation PoP préférée obsolète ou mal configurée sur un site peut forcer des connexions à des PoP sous-optimaux. La configuration de sélection de PoP peut être vue par site via la page Réseau > Site > Configuration du site > Général.

Si un emplacement est configuré ici et ne semble pas adapté pour une connexion optimale, ou s'il est préférable de permettre au mécanisme de sélection de PoP de Cato de déterminer le PoP optimal, veuillez consulter la section Résolution de la configuration de sélection de PoP inadaptée.

Vérifiez la configuration de sélection de PoP sur le Socket 

Une configuration de sélection de PoP obsolète ou inadaptée peut également exister dans la configuration du socket. Pour vérifier si c'est le cas, naviguez vers les Paramètres de connexion Cloud dans le webUI du socket, voir Utilisation du webUI du Socket.

Si la configuration existe ici et qu'il est préférable de permettre au mécanisme de sélection de PoP de Cato de déterminer le PoP optimal, veuillez consulter la section Résolution de la configuration de sélection de PoP inadaptée.

Vérifier l'état du PoP

Les Sockets peuvent se connecter à un PoP inattendu en raison du fait que le PoP géographiquement le plus proche est affecté par des opérations de maintenance ou un autre problème similaire. Veuillez consulter la page État du PoP pour vérifier si cela est le cas. 

Vérifier les restrictions de localisation pour la géolocalisation

Selon le MSA de Cato, les sites de socket dans certaines géolocalisations sont restreints pour se connecter à des PoPs dans d'autres emplacements. Le MSA est décrit lors de l'achat des services de Cato.

Les sites de socket dans certaines géolocalisations seront limités à un pool de PoPs disponibles, par exemple, les sites de socket en Chine se connecteront à des PoPs en Chine, et les sites de socket vietnamiens se connecteront à un pool de PoPs en Asie.

Pour plus d'informations à ce sujet, veuillez consulter le MSA.

Vérifier les signes de déplacement du socket entre les PoPs

La page des Événements peut être utilisée pour déterminer si un socket n'est probablement pas sur le PoP optimal initialement déterminé en raison de problèmes de connectivité. En utilisant une sélection de champs, une chronologie de la connectivité du socket aux différents PoPs.

En utilisant le préréglage d'événements 'Site reconnecté', et en filtrant davantage sur le site en question en fixant également la valeur du champ 'event_message' à 'Problème de performance détecté, reconnecté à un nœud de service différent dans le Cato Cloud', nous pouvons voir toutes les instances où un site de socket a changé de PoP en raison de paramètres de connectivité du tunnel franchissant les seuils de SLA configurés. Si un site de socket dépasse les seuils de SLA vers plusieurs PoPs, continuez le flux de dépannage pour vérifier les Paramètres de SLA de connexion.

Vérifiez que la SLA de Connexion n'est pas trop stricte

La SLA de Connexion joue un rôle important pour assurer qu'un site est connecté au PoP optimal, surtout dans les environnements de réseau dynamiques avec un sous-jacent public comme les connexions Internet de l'ISP. Une SLA de Connexion trop stricte, cependant, peut provoquer des reconnexions inutiles à des PoPs autres que l'emplacement préféré de l'administrateur.

La configuration de la SLA de connexion par site peut être vue sous Network > Site > Configuration du site > SLA de Connexion.

En utilisant les Analyses de Réseau pour construire une ligne de base des métriques de performance de dernier kilomètre, considérez si les métriques SLA sont adaptées pour ce site.

Si ces paramètres ne sont pas adaptés, veuillez consulter Résolution de la configuration de SLA à des lignes de base incorrectes

Si les paramètres sont adaptés, mais que des événements de réoptimisation de PoP se produisent toujours régulièrement vers plusieurs PoPs, veuillez consulter la section Résolution des performances médiocres du sous-jacent.

Si le Socket continue à se connecter à un PoP inadapté après avoir suivi les étapes ci-dessus, veuillez ouvrir un ticket avec Support et mettez en évidence le PoP actuel et attendu.

Dépanner un tunnel instable

Vérifiez la corrélation entre la performance de dernier kilomètre et la connexion du site

En notant qu'un site donné connaît une mauvaise performance dans sa connexion à un PoP, il est important de déterminer si cette perte de paquets est probablement due à la performance sur la ligne ISP sous-jacente.

Cela peut être fait en corrélant tout problème de performance donné sur une période de temps avec la performance observée sur le dernier kilomètre dans le même cadre temporel et en cherchant des motifs.

Les analyses de réseau peuvent être utilisées pour ce faire.

L'exemple ci-dessus montre la perte de paquets en amont détectée sur un tunnel de site vers le PoP. Nous pouvons voir plusieurs pics d'environ 10% et un faible niveau constant de perte pendant toute la période.

En comparant cela à la performance pour le dernier kilomètre sur la même période de temps, nous pouvons voir ce qui suit :

Le dernier kilomètre présente également une variation de performance, mais il est affecté par un niveau constant de perte entre ~10-20%. Il est clair à partir de cela que la perte de paquets sur le tunnel du socket au PoP de Cato est probablement un symptôme de performance médiocre sur le sous-jacent.

Si c'est le cas lors du dépannage d'un problème de performance, veuillez consulter Résolution des performances médiocres du sous-jacent

Cross-Referencing des sites similaires

Les propriétés partagées entre les sites peuvent être utilisées pour tenter d'inférer des faits sur le problème en question. Par exemple, le site ci-dessous rencontre des problèmes de connectivité. Notez que le PoP connecté est Londres :

Cette information peut être utilisée pour inter-référencer d'autres sites qui peuvent être connectés à Londres pour voir si des problèmes sont partagés. Cela peut être vu dans la capture d'écran ci-dessous :

Si l'inter-référence suggère que le problème se trouve sur un Cato PoP, consultez la section Vérifier l'état du PoP.

L'inter-référence est également utile pour les sites avec des ISPs partagés. Cela est fait dans l'exemple ci-dessous :

Si cette inter-référence implique que l'ISP rencontre des problèmes de connectivité, consultez la section Résolution des performances médiocres du sous-jacent.

Vérifiez que la SLA de Connexion n'est pas trop indulgente

SLA de Connexion joue un rôle important pour assurer qu'un site est connecté au PoP optimal, surtout dans les environnements de réseau dynamiques avec un sous-jacent public comme les connexions Internet de l'ISP. Une SLA de Connexion trop indulgente, cependant, peut amener les sockets à s'accrocher à des connexions sous-optimales aux PoPs plus longtemps que ce que l'administrateur souhaiterait, impactant ainsi les applications sensibles.

La configuration de la SLA de Connexion par site peut être vue sous Réseau > Site > Configuration du Site > SLA de Connexion.

En utilisant les Analyses de Réseau pour construire une base de référence des métriques de performance du dernier kilomètre, considérez si les métriques SLA sont adaptées pour ce site.

Si ces paramètres ne sont pas adaptés, veuillez voir Résolution de la configuration de SLA à des lignes de base incorrectes.

Résolution des problèmes découverts

Résolution de la connectivité du Socket

Il est important d'isoler si les problèmes de connectivité affectent uniquement le Socket. Si vous branchez un ordinateur portable sur la même connexion ISP, rencontrez-vous les mêmes problèmes avec la résolution DNS ou le ping des adresses ? Si oui, contactez votre ISP pour avancer.

Assurez-vous que l'ordinateur portable de test a l'IPv6 désactivé et, en cas d'attribution d'adresse IP statique, attribuez la même IP que le Socket lors des tests.

Si les problèmes de connectivité sont isolés à votre Socket, assurez-vous que la configuration IP est correcte dans l'onglet Paramètres Réseau du WebUI :

Résolution de l'Handshake DTLS incomplet

Assurez-vous avec votre fournisseur que le trafic DTLS sur le port UDP 443 est autorisé à sortir vers Internet. Si nécessaire, ce port peut être changé en UDP/1337 comme décrit dans Configurer un port différent pour se connecter au PoP de Cato.

Résolution des performances médiocres du sous-jacent

Une mauvaise performance du sous-jacent aura un impact sur tout tunnel construit sur ce sous-jacent. Bien que le sous-jacent soit le domaine de l'ISP, il existe quelques outils qui peuvent être utilisés pour identifier où des problèmes de performance sont introduits, et aussi pour tenter de mitiger les problèmes de performance lorsque c'est possible.

Le WebUI du socket possède un outil de traceroute qui vous permettra de pinguer des hôtes accessibles publiquement via la connexion ISP. Lors de l'ouverture de session de ping vers des noms d'hôte accessibles publiquement, il peut être déterminé le saut où la perte ou le retard excessif est introduit sur le chemin l3 entre un socket et le service.

Dans l'instance ci-dessus, une perte de paquets est clairement introduite directement depuis la frontière L3 fournie par l'ISP.

Bien qu'ultimement, tout problème de sous-jacent devra être transmis à l'ISP, s'assurer que les paramètres dans le CMA sont corrects aidera à mitiger l'impact des problèmes de performance. Assurez-vous que la configuration de la bande passante pour une interface socket est précise pour la bande passante fournie par la ligne. Les outils de test de vitesse de Socket WebUI peuvent être effectués pour évaluer la connexion. De plus, réduire les paramètres de burstiness d'une connexion peut forcer Cato à activer le moteur QoS plus tôt, et permettre à votre trafic le moins prioritaire d'être abandonné en faveur des applications plus critiques. 

Résolution de la configuration de sélection de PoP inadaptée

Pour rétablir toute configuration manuelle de sélection de PoP et permettre à Cato de sélectionner le PoP optimal pour une connexion de socket, assurez-vous d'abord qu'il n'y a pas de configuration manuelle de l'emplacement PoP sur CMA, puis faites de même pour le socket.

Dans CMA, cela peut être fait dans Réseau > Site > Général > Emplacements PoP Préférés.

Assurez-vous que 'Automatique' est sélectionné.

Dans l'interface web du socket, allez à Paramètres de connexion au cloud.

Assurez-vous que la destination est définie sur 'Steering'.

Résolution de la configuration SLA aux baselines incorrectes

La première étape pour garantir que la configuration SLA est appropriée est de comprendre quels sont les seuils critiques ou les exigences pour les applications critiques utilisées depuis le site.

Pour approfondir cela, considérez deux exemples.

• L'application A est tolérante à de faibles niveaux de perte de paquets et a de bonnes capacités de réorganisation des paquets, cependant, la session doit être maintenue pour que le service fonctionne ; interrompre et recréer le flux cause des problèmes au sein de l'application.
• L'application B est très sensible à la perte de paquets sporadique. Même de faibles niveaux de perte peuvent provoquer l'interruption des transferts de données et le transfert devra être recommencé depuis le début. Cela dit, le canal de contrôle est très résilient aux interruptions et aux reconnexions de sessions.

Avec le profil de l'application A, nous créons une configuration SLA qui permet de faibles niveaux de perte même sur de longues fenêtres temporelles ; il est préférable de conserver la connexion au PoP pour maintenir la session même si la perte impacte autrement le service.

L'application B, en revanche, nécessite une configuration SLA plus stricte. Il est préférable de changer de PoP si même de petites quantités de perte de paquets sont détectées pour protéger l'intégrité des transferts.

Les sites utilisent évidemment un mélange d'applications avec différents profils et exigences. Un administrateur devra être stratégique pour équilibrer ces besoins pour une politique SLA adaptée. 

Soumettre des cas au support de Cato

Si suivre ce guide n'a pas résolu le problème, soumettez un ticket de support. Pour obtenir la réponse la plus utile à une demande, un administrateur doit fournir les résultats des étapes de dépannage effectuées lors de l'utilisation de ce guide. Y compris, par exemple :

• Filtres pertinents pour attirer l'attention sur des événements spécifiques.
• Résultats des tests de l'interface web.
• Conclusions de l'analyse réseau.
• Exigences de configuration SLA.