Résolution de problèmes de connectivité des services Internet

Vue d'ensemble

Accéder aux applications basées sur le cloud via Internet représente une grande partie du trafic commercial qu'un site ou un utilisateur facilite. Si les services critiques accessibles via Internet sont inaccessibles, cela peut avoir un impact matériel sur la performance de l'entreprise. Ce manuel vise à aider dans des scénarios comme celui-ci.

Symptômes

Le site Web ne charge pas
- Cela pourrait se manifester de plusieurs façons, mais généralement, les requêtes du navigateur expireront lors de la tentative d'accéder à un site.
Incompatibilité avec les règles du firewall
Erreur de certificat
- Une erreur de certificat apparaît lors de la tentative de navigation sur un site ou une application via HTTPS
Page de blocage
- En tentant d'accéder à un site ou à une application, une page informative indiquant que le trafic est bloqué apparaît.

Causes possibles

Règle de firewall Internet bloquant le trafic
Accessibilité du service, y compris les IPs géo-bloquées
Incompatibilité avec l'inspection TLS
Erreur TLS
Pré-requis TLSI non remplis - par exemple installation du certificat
URL mal catégorisée
Résultats de faux positif du moteur de sécurité
Échec du service RBI

Évaluation initiale

Remarque

Note : Assurez-vous d'avoir des règles de pare-feu Internet (même créées temporairement à des fins de dépannage) configurées avec un suivi des événements activé.

Examinez le firewall Internet, l'IPS et les événements Anti-malware en sélectionnant le préréglage respectif dans le CMA. Définissez des filtres pour réduire le trafic intéressant et vérifiez si le flux a été bloqué par le firewall ou les moteurs IPS/AM. Le champ règle indiquera la règle respective qui correspond au trafic.

Assurez-vous de consulter la section de dépannage appropriée en suivant ces étapes d'évaluation initiale :

Si vous pouvez trouver des événements FW pertinents pour les tentatives d'atteindre l'application, allez à Dépannage du non-chargement du site Web à l'aide des événements
Si aucun événement ne semble avoir été généré pour le flux testé, allez à Dépannage du non-chargement du site Web - Pas d'événements
Si les événements IPS ou Anti-malware montrent que l'un de ces moteurs bloque l'accès au serveur interne, ou si la réplication montre des pages d'information liées à l'IPS ou à l'Anti-Malware, allez à Résolution du blocage de faux positifs IPS/Anti-Malware
Si une page d'information liée à la politique Internet de l'entreprise est signalée ou reproduite, visitez Dépannage de page de blocage erronée
Si l'application signale un certificat non approuvé, accédez à Dépannage des certificats non approuvés pour tout le trafic
Si des erreurs TLS sont signalées sur les pages d'information lors de la tentative d'atteindre l'application Internet, consultez Dépannage des erreurs de certificat
Pour les problèmes de rendu des sites Web spécifiquement en Chine, allez à Dépannage des problèmes de rendu en Chine

Dépannage du problème

Les étapes de dépannage des 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 loin dans le manuel.

Vérification des journaux de piste de vérification

Vérifiez la piste d'audit pour tout journal modifié qui pourrait avoir impacté l'accès aux ressources internes. Cela inclut les règles de firewall Internet, les paramètres AM/IPS et l'inspection TLS.

Dépannage du non-chargement du site Web à l'aide des événements

Trouver des flux pertinents dans les é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 d'un compte. Les événements peuvent être filtrés en événements pertinents en sélectionnant le préréglage 'firewall Internet', ou en filtrant pour le type d'événement 'Sécurité' et le sous-type 'firewall Internet'. Vous pouvez également filtrer par le nom du site en question avec le champ 'Site source'.

Pour une application ou un site échouant à charger, essayez de filtrer le flux en question. Pour ce faire, vous pouvez ajouter d'autres champs de filtre à la recherche. Par exemple, vous pouvez vouloir filtrer par 'Domaine' ou 'IP de destination'. Vous pouvez aussi vouloir filtrer par 'IP source' ou tout flux où l' 'Action' était Bloquer.

Une fois que vous avez identifié les événements qui sont pertinents pour le flux en cours de dépannage, nous pouvons continuer à analyser les informations vues ici.

Analyse des champs d'événements

Les champs d'événements offriront beaucoup d'informations sur les flux individuels et aideront un administrateur à s'assurer que la politique et la configuration CMA pour un flux donné sont correctes, ou à identifier des incompatibilités ou des problèmes dans le flux.

Les champs qui peuvent indiquer des causes d'inaccessibilité d'une application sont les suivants :

Action
Si le flux a été bloqué, cela indique que le flux est intercepté sur la base des politiques de sécurité configurées dans Sécurité > Firewall Internet. La règle qui a bloqué ce trafic sera également listée comme un champ dans l'événement.

Si cette règle de firewall n'est pas celle à laquelle vous vous attendiez pour ce trafic, veuillez visiter la section Résolution des flux correspondant à la mauvaise règle.

Si l'action montre 'RBI', consultez Dépannage des flux RBI
Nom PoP/ Source IP publique
Il peut être important de savoir sous quelle forme le trafic atteint l'application basée sur Internet. Particulièrement en ce qui concerne l'IP source. Ces champs aident un administrateur à déterminer quelle IP source et région quittent les paquets au PoP, et sont impactés par la configuration de sortie au sein de la base de règles réseau.

Assurez-vous que l'application ne liste pas ou ne géo-bloque pas les IP de Cato. Si le PoP sortant ou l'IP source ne correspond pas à vos attentes selon vos règles réseau, suivez le flux de dépannage des erreurs de règle pour la règle réseau concernée.
Inspection TLS
Le champ d'inspection TLS identifie si le flux en question a été intercepté pour inspection des données via TLSI. Une valeur de 1 suggère que le flux a été inspecté.

Certaines applications ne gèrent pas bien d'être inspectées, surtout celles qui utilisent des techniques de sécurité comme l'épinglage de certificats. Pour les flux qui semblent être impactés en raison de l'interception de l'inspection TLS, consultez Résolution des applications échouant en raison de TLSI.
Accélération TCP
L'accélération TCP est une méthode d'optimisation du trafic TCP lors de son passage dans le cloud Cato. Les façons dont l'accélération TCP fonctionne et comment elle peut impacter le trafic pour les applications Internet sont décrites ici.

Dépannage du non-chargement du site Web - Pas d'événements

Si aucun événement ne peut être trouvé pour un flux, et que toutes les règles pertinentes dans Sécurité > Firewall Internet sont définies pour bloquer ou surveiller, alors il est probable que le flux n'atteigne pas l'étape où il serait enregistré. Cela peut être dû à une erreur de configuration ou à un problème avec le succès du protocole précédent le flux, comme DNS.

La première étape pour résoudre les problèmes est de confirmer que ce problème est spécifique au trafic traversant Cato. Cela peut être fait en contournant Cato en connectant un hôte directement à la connexion Internet ou en utilisant Bypass Socket ou le Tunnel fractionné pour les sites de socket et les utilisateurs SDP respectivement. Si le site Web ne charge toujours pas en contournant Cato, ce n'est pas un problème lié à Cato et cela devrait être adressé par un FAI ou les fournisseurs de l'application. Si le problème ne se présente pas en contournant Cato, continuez avec ce flux de dépannage.

Dépannage de la résolution DNS

Si un flux n'atteint pas l'étape à laquelle un événement peut être généré, une cause probable est que l'incapacité de compléter le DNS empêche le flux vers l'application Internet d'être initié depuis le client.

Pour l'hôte pour lequel cette application échoue, testez la résolution DNS pour le nom d'hôte de l'application en question pour déterminer si le DNS renvoie une réponse avec succès.

Pour les cas où le DNS échoue :

Si vos serveurs DNS sont des serveurs DNS basés sur Internet externes, envisagez de modifier les serveurs DNS selon les meilleures pratiques Cato pour le DNS.

Si les serveurs DNS utilisés sont les serveurs recommandés par Cato (10.254.254.1 et 8.8.8.8), assurez-vous que ces flux DNS ne sont pas bloqués en utilisant le flux de dépannage décrit dans Trouver les flux pertinents dans les événements.

Si des serveurs DNS privés sont utilisés, assurez-vous que les requêtes DNS atteignent ces serveurs et vérifiez que la réponse correspond aux attentes.

Vérifiez la configuration de contournement pour les sites de socket

Les flux qui sont contournés sur des sites de socket n'apparaîtront pas dans la page des événements et ne seront pas soumis à l'optimisation du trafic ou aux moteurs de sécurité de Cato. Cela peut entraîner des problèmes de connectivité notamment dans les cas où des adresses IP spécifiques connues doivent être la source du trafic vers l'application Internet.

Assurez-vous que le flux en question n'est pas inclus dans une règle de contournement si cela n'est pas nécessaire :

Vérifiez le tunnel partagé pour les clients SDP

Les flux qui sont dans le cadre d'une politique de tunnel partagé pour les clients SDP n'apparaîtront pas dans la page des événements et ne seront pas soumis à l'optimisation du trafic ou aux moteurs de sécurité de Cato. Cela peut entraîner des problèmes de connectivité notamment dans les cas où des adresses IP spécifiques connues doivent être la source du trafic vers l'application Internet.

Assurez-vous que le flux en question n'est pas dans le cadre d'une règle de politique de tunnel partagé si cela n'est pas nécessaire :

Vérifiez la configuration du niveau de confiance pour les clients SDP

Les niveaux de confiance de sécurité sur Internet à distance peuvent impacter le trafic Internet vers les utilisateurs SDP dans les cas où l'authentification à Cato a expiré. Le comportement de basculement pour les sessions utilisateur dont les jetons ont expiré peut entraîner que le trafic Internet ne soit pas routé vers Cato. Cela peut entraîner des problèmes de connectivité notamment dans les cas où des adresses IP spécifiques connues doivent être la source du trafic vers l'application Internet.

Pour un utilisateur qui a une session expirée, assurez-vous que l'utilisateur peut accéder à Internet même avec une faible confiance, ou assurez-vous qu'il renouvelle son authentification.

Dépannage des décalages de règles de pare-feu Internet

Lors de la configuration d'une règle de pare-feu, il est possible que le trafic soit évalué par une mauvaise règle. Cette section couvre tous les scénarios de décalage possibles et comment résoudre ce problème.

Vérification de l'application personnalisée

Si le trafic intéressant est supposé correspondre à une application personnalisée et que le champ Application trouvé dans l'événement FW ne correspond pas, confirmez que l'application personnalisée est correctement configurée. Gardez à l'esprit que lorsqu'il existe des applications personnalisées qui se chevauchent, Cato identifie uniquement le trafic comme une des applications personnalisées.

Pour éviter ce problème, consultez la section Résolution d'une application personnalisée qui se chevauche.

Vérification de l'application/service intégré

Si le trafic intéressant est supposé correspondre à une application ou un service intégré et que le trafic correspond à la règle de pare-feu incorrecte, vérifiez ce qui suit :

Quelles applications ou services sont configurés dans la règle de pare-feu 'incorrecte'.
Si l'une de ces applications/services est répertoriée dans le champ Applications liées de l'événement FW.

L'identification des applications/services est un processus en plusieurs étapes qui commence par l'identification du protocole, puis de toutes les applications possibles incluses dans le champ Applications liées. Toute application 'liée' identifiée dans un flux, indépendamment de la décision de l'application finale (champ Application), correspondra à une règle de pare-feu.

Dans l'exemple ci-dessous, le trafic YouTube correspond à la règle #3 au lieu de la règle #4. C'est parce que la règle #3 inclut le service TCP (inclus dans Applications liées) même si l'application finale (champ Application) est youtube.

Pour résoudre ce comportement attendu, consultez Ordonnancement des règles de pare-feu. Un décalage d'application intégré peut aussi être résolu en ajoutant le nom de domaine de l'application pertinente à la règle de pare-feu, comme indiqué dans l'événement CMA, ou en signalant le décalage au support.

Vérification du nom de domaine

Si une règle de pare-feu contient un objet domaine ou FQDN, vérifiez quel est le champ Nom de domaine dans l'événement FW. L'objet Domaine/FQDN dans la règle de pare-feu doit être identique à ce champ.

Gardez à l'esprit qu'un FQDN est une correspondance exacte du domaine totalement qualifié. Par exemple, le FQDN example.com ne correspond qu'à example.com.

D'autre part, un Domaine est un domaine de premier niveau (TLD) ou de deuxième niveau (SLD) qui correspond à tous les sous-domaines. Par exemple, le Domaine example.com correspond à www.example.com et host.example.com.

Il pourrait y avoir des cas où Cato ne peut pas déterminer le bon nom de domaine à partir des flux HTTP, TLS ou DNS. Pour résoudre ces types de problèmes, consultez Résolution des problèmes de nom de domaine

Dépannage des erreurs de certificat

Les erreurs de certificat sont un autre symptôme courant lorsqu'il y a des problèmes de connectivité avec les applications Internet. Les pages de coupure liées à TLS sont courantes et aident les administrateurs à déterminer la cause de l'échec de la connectivité de l'application.

Si la page de blocage suggère une erreur TLS comme indiqué ci-dessus, le flux pertinent peut être trouvé dans les événements. Le sous-type de filtre est TLS peut être utilisé pour zoomer sur des événements spécifiques liés aux erreurs TLS.

Ici, la raison du blocage peut être identifiée pour tout flux bloqué en raison d'une erreur TLS.

Si l'erreur suivante est affichée, même si le certificat du site est valide et que le site est accessible en dehors de Cato, veuillez ouvrir un dossier avec le support Cato.

Dépannage du certificat non fiable pour tout le trafic

Si tout le trafic dirigé vers Internet pour des utilisateurs ou des hôtes particuliers reçoit des erreurs de confidentialité ou de confiance et que TLSI est activé pour le trafic en question, il est probable que le certificat requis pour que TLSI fonctionne ne soit pas présent sur l'appareil.

Vérification de l'utilisation d'un certificat personnalisé

Lors de l'examen de la manière de garantir que le trafic puisse être intercepté avec succès pour TLSI sans interrompre les flux, il faut d'abord déterminer si un certificat personnalisé est utilisé. En examinant le certificat présenté via le navigateur, nous pouvons identifier si le certificat par défaut de Cato, ou un personnalisé agit en tant qu'autorité de certification.

Dans la capture d'écran ci-dessus, nous pouvons voir que l'AC pour le certificat injecté n'est pas le certificat standard de Cato. Nous pouvons vérifier nos certificats personnalisés dans Cato via Sécurité > Gestion des certificats pour identifier si cela correspond à notre certificat actif configuré :

Cela aide un administrateur à identifier quel certificat nécessite d'être distribué aux clients finaux.

Vérifiez si les certificats pertinents sont installés

Une fois que nous avons identifié quel certificat doit être installé sur les hôtes afin que ces flux fonctionnent, nous pouvons suivre cet guide pour s'assurer que ces certificats sont installés sur les appareils.

Dépannage d'une page de blocage erronée

Lorsque vous êtes face à une page de blocage, il est important de déterminer à partir de la page de blocage le type de blocage qui a eu lieu et comment le dépannage doit avancer.

La page de coupure ci-dessus indique que ce blocage a été généré par le pare-feu Internet. Si la règle qui a bloqué ce flux est configurée pour le suivi des événements, ce flux s'affichera dans la page des événements et pourra être analysé plus en profondeur :

Si cette règle a été activée par erreur et que vous vous attendiez à ce que ce flux corresponde à une autre règle, consultez la section Dépannage des décalages de règles de pare-feu Internet.
Si cette règle a été activée en fonction de la catégorie d'URL, et que vous pensez que cette catégorie est appliquée à cette URL par erreur, consultez la section Résolution des erreurs de catégorisation d'URL.
Si l'action qui correspond à l'événement pertinent est 'RBI', accédez à Dépannage des flux RBI

Dépannage des flux RBI

Si une URL déclenche une règle RBI contre les attentes, assurez-vous que l'URL est classifiée correctement, comme dans Résolution des erreurs de catégorisation d'URL.

Si un utilisateur rencontre un problème de navigation sur une certaine URL, vous pouvez générer une session d'émulation RBI de test pour l'URL avec l'Utilitaire Admin RBI. Entrez l'URL HTTP ou HTTPS valide puis suivez le lien résultant pour afficher le site dans une session RBI. L'utilitaire envoie ce trafic directement au service RBI sans passer par le Cato Cloud. Cela peut aider à déterminer si le problème d'un utilisateur est lié au service RBI lui-même, ou est causé par d'autres problèmes tels que la configuration du compte ou la connectivité de l'infrastructure Cato. Par exemple, un utilisateur connecté à Cato ne peut pas naviguer vers un site non catégorisé configuré pour RBI, mais l'administrateur peut atteindre le site en utilisant l'outil. Cela peut indiquer que le service RBI fonctionne correctement et que le problème est lié à la connectivité entre un PoP et le service.

Après avoir exécuté une session RBI depuis l'outil, vous pouvez rapporter les résultats au Support pour les aider à résoudre le problème.

Pour dépanner avec l'outil Admin RBI :

Depuis le panneau de navigation, sélectionnez Sécurité > RBI.
Sous l'utilitaire Admin RBI, entrez une URL HTTP ou HTTPS valide. Par exemple : https://maps.google.com
Cliquez sur Générer. Une URL est créée pour la session RBI.
Cliquez sur le lien à côté de l'URL. La session RBI s'ouvre dans votre navigateur par défaut.

Résolution des problèmes de rendu en Chine

Pour ce cas d'utilisation spécifique, veuillez consulter notre KB pertinent sur ce sujet, Chine | Page Web ayant des problèmes de rendu

Résolution des problèmes découverts

Résolution des applications personnalisées chevauchées

Assurez-vous que l'application personnalisée inclut les adresses IP correctes, le domaine, le port et le protocole. Il n'y a pas de logique concernant le choix de l'application personnalisée pour l'identification, de sorte que l'application personnalisée doit être définie de manière unique pour éviter le chevauchement avec une autre application personnalisée. Pour plus d'informations, consultez Travailler avec des applications personnalisées

Ordre des règles de pare-feu

Gardez à l'esprit que les règles de pare-feu sont évaluées selon leur ordre, il est donc important de définir des règles plus spécifiques avant les règles plus générales. Par exemple, les règles de pare-feu qui définissent une application personnalisée, une application intégrée, un domaine, un FQDN ou un service personnalisé doivent être placées avant les règles contenant des catégories, des catégories personnalisées ou des services.

Dans la capture d'écran ci-dessous, la règle #1 contient un service personnalisé qui inclut des plages IP pour twitter.com et est placée avant la règle #2 qui contient des catégories d'applications. La règle #1 est plus spécifique que la règle #2 et sera mieux adaptée au trafic destiné à twitter.com. Cela désactivera également l'accélération TCP et résoudra tout problème de routage Off-Cloud ou Alt-WAN étant donné que la règle #1 est une règle simple.

Résolution des problèmes de nom de domaine

Les problèmes de correspondance des règles de pare-feu basés sur le domaine/FQDN peuvent être résolus comme suit :

Pour les protocoles comme HTTP/S, Cato peut déterminer le domaine de destination à l'aide des sources suivantes :
- En-tête de nom d'hôte HTTP (lorsque l'inspection TLS est activée)
- Champ SNI pendant la poignée de main TLS
- Résolution DNS, où le nom de domaine est appris à partir des requêtes et réponses DNS
Il est important de s'assurer que le domaine spécifié dans la règle de pare-feu est cohérent à travers toutes ces sources. Notez que seul le nom de domaine le mieux correspond (évalué de haut en bas) est affiché comme Nom de domaine dans les événements de pare-feu.
Pour d'autres protocoles, tels que SSH ou SMB, qui n'envoient pas un domaine en clair, Cato s'appuie exclusivement sur l'interception DNS pour associer le trafic à un domaine ou un nom de domaine complet. Ceci est particulièrement critique lors de l'utilisation d'un DNS privé car nous devons nous assurer que les requêtes/réponses DNS passent par Cato. Consulte Les meilleures pratiques pour DNS et votre compte Cato.
DoH (DNS over HTTPS) et DNS sur TLS ne sont pas pris en charge pour la correspondance des noms de domaine/applications, par conséquent, ils doivent être bloqués dans les règles de pare-feu pour forcer le déplacement des requêtes DNS vers UDP/53.

Résolution des applications échouant à cause de TLSI

Pour les flux inspectés TLS qui sont inspectés par erreur, assurez-vous que la base de règles TLSI ordonnée est configurée correctement, en tenant compte de la correspondance de l'application du flux et de la nature ordonnée des règles, comme décrit ici.

Si un flux est inspecté intentionnellement, et cela cause l'échec de l'application Internet, envisagez de configurer une règle de contournement pour l'application en question.

Résolution des erreurs de catégorisation d'URL

Pour re-catégoriser des domaines, veuillez consulter notre documentation sur Identifier la catégorie pour un domaine.

Résolution de faux positifs de blocage IPS/Anti-Malware

Passez en revue les événements IPS/Anti-Malware en sélectionnant les préréglages IPS et Anti-Malware dans CMA. Réglez les filtres pour affiner le trafic intéressant et vérifiez si le flux a été bloqué par les moteurs IPS ou AM.

Si le trafic intéressant est bloqué par IPS/AM, vous pouvez ajouter des listes d'autorisation avec portée Internet aux paramètres IPS et Anti-Malware.

Soumettre des cas à l'assistance 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 :

Détails du problème rencontré et impact global sur les utilisateurs.
Événements de pare-feu liés et configuration de la règle de pare-feu.
Reproduisez le problème et exécutez le Support en Libre-Service. Incluez le numéro de ticket généré par l'outil.