Dépannage de l'accès aux ressources internes

Vue d'ensemble

Assurer un accès transparent aux ressources internes est essentiel pour maintenir la productivité et la sécurité dans le réseau. Cependant, divers facteurs peuvent perturber l'accès, entraînant une mauvaise expérience utilisateur et un flux de travail entravé. Ce manuel vise à fournir un guide complet pour dépanner les problèmes d'accès WAN aux ressources internes au sein de Cato Cloud.

Symptômes

Un échec d'accès aux ressources internes peut se manifester de plusieurs façons. Un administrateur peut noter les symptômes suivants :

  • Le nom de domaine du serveur interne ne peut pas être résolu
  • Le serveur interne est inaccessible
  • Incompatibilité de règle de pare-feu WAN
  • Les clients SDP ne peuvent pas atteindre les ressources internes
  • La ressource de redirection de port distante (RPF) est inaccessible
  • L'hôte de surveillance LAN est inaccessible

Causes possibles

  • Problèmes de routage
  • Mauvaise configuration de la redirection DNS
  • Mauvaise configuration du pare-feu WAN
  • Chevauchement avec le réseau du client SDP
  • Intervention de sécurité
  • Problèmes de connectivité de l'hôte de destination

Évaluation initiale

Remarque

Note : Assurez-vous d'avoir une Règle de pare-feu WAN (même créée temporairement à des fins de dépannage) avec suivi d'événements activé.

Pour les problèmes liés à l'atteinte des serveurs internes via l'accès par navigateur, consultez Dépannage des problèmes d'accès au navigateur

Révisez les événements de pare-feu WAN, IPS et Anti-malware en sélectionnant le préréglage approprié dans CMA. Définissez des filtres pour réduire le trafic intéressant et vérifiez si le flux a été bloqué par le pare-feu WAN ou les moteurs IPS/AM. Le champ règle affichera 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 :

Dépannage du problème

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

Vérification des journaux du suivi des audits

Vérifiez le suivi des audits pour tout journal modifié qui pourrait avoir affecté l'accès aux ressources internes. Cela inclut les règles de pare-feu WAN, les paramètres AM/IPS, et l'inspection TLS.

Dépannage des problèmes de résolution de nom de domaine du serveur

Vérification de la résolution DNS

Si la ressource interne doit être accessible en utilisant son nom de domaine, confirmez si le nom de domaine du serveur interne peut être résolu, en utilisant les commandes nslookup ou dig à partir de la ligne de commande.

Il pourrait y avoir deux scénarios pour la résolution DNS interne dans votre compte :

  • Si une adresse IP de serveur DNS privé est utilisée dans l'organisation, confirmez si les utilisateurs affectés peuvent atteindre le serveur DNS en interne. Si ce n'est pas le cas, dépannez la connectivité au serveur DNS, de manière similaire à Dépannage du serveur interne inaccessible
  • Si le serveur DNS Cato par défaut 10.254.254.1, le serveur DNS défini par le compte, ou un DNS public bien connu (8.8.8.8, 1.1.1.1, ou 9.9.9.9) sont utilisés dans le compte, dépannez le transfert DNS à l'étape suivante.

Vérification du transfert DNS

Les flux de trafic qui reposent sur des noms de domaine internes (par ex. pc1.domaine.net) doivent avoir une redirection DNS correctement configurée dans CMA. Il est également crucial que Cato intercepte les flux DNS pour pouvoir résoudre correctement les noms de domaine.

Le transfert DNS ne peut fonctionner que si les requêtes DNS sont destinées à des serveurs DNS spécifiques comme expliqué dans Résolution des problèmes de transfert DNS.

Dépannage du serveur interne inaccessible

Vérification de la table de routage de Cato

La table de routage peut être utilisée pour vérifier la disponibilité des routes, les métriques, etc. :

  • Recherchez l'adresse IP de la ressource dans la chaîne de recherche et confirmez qu'il existe une route correspondante via le site correct.
  • Si aucune route n'est trouvée, cela signifie que Cato n'est pas au courant de cette route, et ne peut donc pas acheminer vers cette destination. Pour résoudre ce problème, voir Résolution des problèmes de routage
  • S'il existe des routes vers la même destination, vérifiez que les plages dynamiques BGP ne se chevauchent pas avec d'autres routes statiques. Les routes avec une métrique plus basse sont privilégiées.
  • BGP peut également annoncer des routes redondantes de différents sites. La route avec la métrique la plus basse incluant le Poids, la longueur AS ou MED est privilégiée. Voir Comprendre les champs de la table de routage.
  • Pour résoudre les problèmes de métrique, voir Résolution des problèmes de routage

Vérification de l'acheminement basé sur les politiques de l'IPSec

Si la ressource interne est atteignable via IPSec, confirmez que les plages correctes sont définies dans les sections IPSec et Réseaux du site comme expliqué dans Manuel de dépannage IPSEC.

Si l'acheminement basé sur des politiques est configuré, tous les sélecteurs de trafic doivent correspondre à la fois sur Cato et sur le pare-feu/routeur IPSec pour assurer la connectivité aux ressources internes.

Vérification de la vivacité de la ressource interne

Si la ressource interne se trouve derrière un socket ou un vSocket, vérifiez la valeur de Dernière activité de l'hôte à partir de la page Anfitrions connus sur le site. Voir Afficher les hôtes connus pour un site

Les hôtes qui n'ont pas été vus récemment par le Site pourraient être éteints ou non connectés au réseau.

Exécutez une capture de paquets depuis le WebUI et identifiez tout problème possible au sein du LAN.

Vérification des flux TLS

Si le trafic intéressant est TLS et que vous avez vérifié que les étapes précédentes autorisent le trafic. Vérifiez si le flux de trafic est inspecté TLS par Cato. Cela se trouve dans la règle FW avec le champ inspection TLS réglé à 1.

Si c'est le cas, le certificat racine Cato doit être installé sur le dispositif source comme expliqué dans Configuration de la politique d'inspection TLS. Sinon, contournez l'inspection TLS pour éviter toute erreur de certificat et des problèmes d'accès potentiels à la ressource.

Résolution des problèmes de discordance des règles du pare-feu WAN

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

Vérification de l'application personnalisée

Si le trafic intéressant doit 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 superposées, Cato n'identifie le trafic que comme une des apps personnalisées. 

Pour éviter ce problème, veuillez consulter la section Résolution des applications personnalisées superposées.

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

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

  • Quelles applications ou services sont configurés dans la règle de pare-feu « erronée ».
  • Si une de ces applications/services est listée dans le champ Applications Liées de l'événement FW.

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

Dans l'exemple ci-dessous, le trafic SMB correspond à la Règle #1 au lieu de la Règle #2. Ceci est dû au fait que la Règle #1 inclut le service TCP (inclus dans Applications Liées) même si l'application finale (champ Application) est SMB.

Pour résoudre ce comportement attendu, voir Ordonnancement des Règles de Pare-feu

Vérification du Nom de Domaine Configuré

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 le même que ce champ.

Gardez à l'esprit qu'un FQDN correspond exactement au domaine complet. Par exemple, le FQDN example.com correspond uniquement à 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 Nom de Domaine correct à partir des flux HTTP, TLS ou DNS. Pour résoudre ces types de problèmes, voir Résolution des problèmes de discordance de Nom de Domaine

Résolution des problèmes du Client SDP ne touchant pas les ressources internes

Cette section traite des problèmes exclusifs aux Clients SDP ne touchant pas les ressources internes.

Vérification du chevauchement du sous-réseau réseau domestique de l'utilisateur

Si le Client SDP ne peut pas se connecter aux ressources internes, y compris faire un ping au serveur, vérifiez s'il y a un chevauchement d'adresses IP entre le réseau domestique de l'utilisateur et le site avec les ressources internes. Dans ce cas, la table de routage du client pointera sur la carte réseau locale lorsqu'il essaiera de se connecter au serveur interne situé derrière le site Cato distant, ce qui entraînera un échec de la connexion.

Les sites distants avec une plage d'adresses IP de 192.168.0.0/24, 192.168.1.0/24 ou 10.0.0.0/24, peuvent facilement se chevaucher avec la plage d'adresses IP des routeurs domestiques sans fil, qui utilisent souvent cette plage d'adresses IP comme paramètre DHCP par défaut.

Pour résoudre ce problème, suivez les étapes décrites dans Le Client SDP ne peut pas se connecter aux ressources WAN distantes.

Utilisateurs macOS et iOS ne résolvent pas les domaines internes

Comme expliqué dans Utilisateurs macOS Ventura et iOS Incapables d'Atteindre les Ressources Internes Via Cato, si le Client SDP ne peut pas se connecter aux ressources internes en utilisant son nom de domaine mais peut les atteindre en utilisant son adresse IP, il est possible que le transfert DNS échoue en raison de DoH (DNS sur HTTPS) ou DoT (DNS sur TLS) utilisé par le point de terminaison. Cato ne supporte actuellement pas DoH/DoT.

Pour résoudre ce problème, voir Résolution des Problèmes de Transfert DNS. Sinon, le serveur DNS Cato (10.254.254.1) peut être défini dans CMA comme le seul serveur DNS pour le point de terminaison.

Utilisateurs Android ne résolvant pas les domaines internes

Comme expliqué dans Appareils Android Incapables d'Atteindre les Ressources Internes Via Cato, si le Client SDP ne peut pas se connecter aux ressources internes en utilisant son nom de domaine mais peut les atteindre en utilisant son adresse IP, il est possible que le transfert DNS échoue en raison du DNS Privé Automatique utilisé par l'appareil (comportement par défaut) qui impose DoH/DoT pour la résolution DNS. Ceci n'est actuellement pas supporté par Cato.

Pour résoudre ce problème, consultez Résolution des Problèmes de Transfert DNS. Sinon, le DNS Privé peut être désactivé sur l'appareil.

Résolution des problèmes des Ressources Internes RPF

Analyse des Événements RPF

Examinez les événements RPF en sélectionnant le préréglage RPF dans CMA.  Confirmez que l'événement est généré ce qui confirmera que l'IP externe de Cato est disponible. Notez que l'adresse IP de destination est l'IP publique externe configurée dans la règle RPF.

Note : Les événements RPF entrants peuvent parfois afficher un Nom d'affichage, même si le trafic n'est pas initié par un utilisateur. C'est un comportement attendu.

Les champs d'événements dans la plateforme Cato extraient des métadonnées du tunnel, hôte, et agent utilisateur, pas seulement du flux de trafic. Ainsi, si un utilisateur est mappé sur un appareil derrière socket ou tunnel, son nom peut apparaître dans l'événement—même pour le trafic entrant.

Cela diffère de la manière dont les politiques de pare-feu ou de routage interprètent le trafic (qui sont orientées vers la direction), mais est normal pour la corrélation des événements. 

 

Analyse des Événements de Blocage Géographique

Examinez tout événement destiné à l'adresse IP interne du serveur interne. Confirmez qu'aucune restriction de blocage géographique n'empêche la connexion au serveur interne. Si tel est le cas, modifiez la politique de restriction géographique pour la direction entrante pour autoriser le pays source.

Vérification de la Vitalité de la Ressource Interne

Vérifiez la valeur de Dernière Activité Connue de la page Hôtes Connus sur le site. Consulte Afficher les Hôtes Connus pour un Site

Les hôtes qui n'ont pas été vus récemment par le Site peuvent être éteints ou non connectés au réseau.

Exécutez une capture de paquets depuis le WebUI et identifiez tout problème potentiel au sein du LAN.

Résolution des problèmes de l'Hôte de Surveillance LAN Inaccessible

Analyse des Événements de Connectivité

Examinez les événements de connectivité en sélectionnant le préréglage hôtes LAN inaccessibles dans CMA. Les événements Hôte Inaccessible seront générés lorsque l'hôte LAN défini n'est plus accessible.

Vérification de l'Accessibilité de l'Hôte Local

Confirmez que l'hôte local défini peut être pingé depuis le Socket WebUI. Si le ping est réussi, vérifiez ce qui suit :

  • Les sondes de surveillance LAN sont des paquets ICMP provenant de 10.254.254.1, il est donc important de confirmer que l'hôte surveillé ait un chemin de retour vers la passerelle LAN Socket pour pouvoir répondre.
  • Si l'appareil exécute un pare-feu local, ICMP doit être autorisé depuis l'adresse IP 10.254.254.1.

Exécutez une capture de paquets depuis le WebUI et identifiez tout problème potentiel au sein du LAN.

Résolution des Problèmes Découverts

Résolution des Problèmes de Routage

Si la route vers la ressource interne n'est pas trouvée dans la table de routage, vérifiez et résolvez ce qui suit :

Si le métrique de route vu dans la table de routage entraîne des décisions de routage erronées, vérifiez et corrigez ce qui suit :

  • Les valeurs métriques de tunnel sont généralement définies par Cato. Les routes redondantes doivent avoir la même métrique de tunnel tant qu'elles proviennent du même type de site, par exemple site IPSec ou Socket site.
  • La valeur de poids peut être configurée dans la CMA, Network > Site > Configuration du site > BGP. La valeur métrique configurée sur cette page sera vue comme le poids dans la table de routage. Changer la métrique pour le site corrigera les décisions de routage erronées pour les routes redondantes.
  • Les valeurs métriques de longueur AS et Métrologie Discriminatoire sont reçues du routeur externe. Ils doivent être modifiés sur cet appareil si nécessaire.

Résolution des faux positifs des blocages IPS/Anti-Malware

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

 

Résolution de l'application personnalisée chevauchante

Assurez-vous que l'application personnalisée inclut les bonnes adresses IP, domaine, port et protocole. Il n'y a pas de logique quant à quelle application personnalisée est choisie pour l'identification, donc l'application personnalisée doit être définie de manière unique pour éviter de chevaucher une autre application personnalisée. Pour plus d'informations, voir Travailler avec des applications personnalisées

Ordre des règles du pare-feu

Gardez à l'esprit que les règles du pare-feu sont évaluées selon leur ordre, il est donc important de définir des règles plus spécifiques au-dessus des règles plus générales. Par exemple, les règles du 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 au-dessus des règles du pare-feu contenant des catégories, des catégories personnalisées ou des services.

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

Résolution des problèmes de non-correspondance des noms de domaine

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

  • Pour les protocoles comme HTTP/S, Cato peut déterminer le domaine de destination en utilisant les 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 dans toutes ces sources. Notez que seul le nom de domaine le mieux adapté (évalué de haut en bas) est affiché comme Nom de domaine dans les événements du pare-feu. 

  • Pour d'autres protocoles, tels que SSH ou SMB, qui n'envoient pas de domaine en texte clair, Cato s'appuie exclusivement sur l'interception DNS pour associer le trafic à un domaine ou FQDN. Cela 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. Voir Meilleures pratiques pour le DNS et votre compte Cato
  • DoH (DNS sur 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 du pare-feu pour forcer le déplacement des requêtes DNS vers UDP/53.

Résolution des problématiques de redirection DNS

Vous ne pouvez utiliser le redirection DNS que lorsque les requêtes DNS sont destinées aux serveurs DNS suivants :

  • Serveur DNS par défaut de Cato 10.254.254.1
  • Serveurs DNS au niveau du compte, configurés sous Network > Paramètres DNS
  • Serveurs DNS bien connus tels que 8.8.8.8, 1.1.1.1 et 9.9.9.9. La liste des serveurs DNS bien connus peut varier entre les PoPs. Par exemple, la Chine et Sydney.

DoH (DNS sur HTTPS) et DNS sur TLS ne sont pas pris en charge pour la redirection DNS, par conséquent, ils doivent être bloqués dans les règles du pare-feu pour forcer le déplacement des requêtes DNS vers UDP/53. Cette solution s'applique particulièrement aux clients SDP de macOS, iOS et Android.

 

Soulever des 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 :

  • Détails du problème rencontré et impact général sur les utilisateurs.
  • Événements liés au pare-feu et configuration des règles du 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.
  • Si l'utilisateur affecté se connecte à Cato en utilisant le client SDP, veuillez enregistrer le problème en utilisant le client SDP
  •  

Cet article vous a-t-il été utile ?

Utilisateurs qui ont trouvé cela utile : 0 sur 0

0 commentaire