Le trafic échoue par intermittence à correspondre aux règles du pare-feu

Problème

Cet article décrit la raison pour laquelle, malgré une destination identique, certaines connexions sont bloquées par Cato tandis que d'autres sont autorisées.

Par exemple, la découverte d'événements ci-dessous illustre des cas où la même source a tenté de se connecter à la même adresse IP de destination sur le même protocole. Cependant, alors qu'une connexion a été bloquée, l'autre a été autorisée.

Dépannage

Dans cette section, nous explorerons plusieurs scénarios courants qui peuvent amener Cato à traiter la connexion différemment. Comprendre ces scénarios est essentiel pour optimiser et dépanner la connexion efficacement. Explorons chacun d'eux ci-dessous.

1. Routage Asymétrique

Lorsque Cato n'a pas de visibilité sur le flux complet, il peut manquer d'informations suffisantes pour catégoriser correctement les données dans l'application appropriée. Par conséquent, même s'il existe une règle de pare-feu permettant un protocole spécifique comme le HTTPS, le routage asymétrique peut conduire à une classification erronée du flux en tant que TCP. Malheureusement, cette mauvaise classification peut entraîner le blocage de la connexion car elle ne correspond pas à la règle de pare-feu autorisée. Pour enquêter plus avant, il est recommandé de réaliser un traceroute à partir de la source vers la destination et vice versa lorsque le problème survient. En comparant les chemins aller et retour, nous pouvons valider si cela est effectivement la cause du problème.

2. Application Personnalisée Chevauchante

Lorsqu'il s'agit d'une connexion affectée impliquant une application personnalisée, il est essentiel de réaliser un examen approfondi de sa définition. Une définition excessivement simplifiée d'une application personnalisée pourrait amener Cato à identifier l'application de manière incohérente. Si une règle de pare-feu autorise les connexions à l'application personnalisée, mais en raison de la façon dont l'application personnalisée a été définie, son identification devient incohérente, ce qui entraîne un blocage intermittent de la connexion. Par conséquent, lorsqu'il s'agit de connexions destinées aux applications personnalisées, nous recommandons de suivre les meilleures pratiques décrites dans Travailler-avec-des-applications-personnalisées pour garantir un comportement cohérent.

3. Retard de Conscience de l'Utilisateur

Lorsqu'un utilisateur se connecte initialement au réseau Cato, les mécanismes de prise de conscience des utilisateurs basés sur AD et Identity-Agent nécessitent quelques secondes pour mapper l'adresse IP source au nom d'utilisateur correspondant. Pendant cette brève période, le trafic utilisateur initial peut être traité sous une règle de pare-feu inattendue. Cependant, une fois que la prise de conscience de l'utilisateur identifie avec succès le nom d'utilisateur, la règle de pare-feu appropriée sera appliquée.

4. FQDN dans la règle

Un autre scénario courant où des connexions apparemment similaires sont traitées différemment par Cato (bloquées ou autorisées) est lorsque des noms de domaine pleinement qualifiés (FQDN) sont utilisés dans les règles de pare-feu ou dans une catégorie/application personnalisée. Avant de plonger dans les détails, examinons deux événements, tous deux provenant de la même adresse IP source et destinés à la même adresse IP et au même port, mais avec des résultats différents - un autorisé et l'autre bloqué.

Réviser les règles du pare-feu

Dans l'exemple donné, la connexion est soit bloquée, soit autorisée en fonction de la règle du pare-feu WAN.

Pour enquêter plus avant, suivez ces étapes :

• Accédez à la section du pare-feu WAN dans le CMA et recherchez les règles pertinentes.

• Il devient évident que la règle 1 correspond à l'événement de moniteur (Autoriser). Cette règle permet spécifiquement les connexions catégorisées sous "Serveurs Web Internes". En cliquant sur la règle, on découvre que "Serveurs Web Internes" provient de la Catégorie Personnalisée.

• En revanche, la règle 5 s'aligne sur l'événement de blocage. Elle est conçue pour bloquer le trafic HTTP(s) ainsi que d'autres services.

Réviser l'app/catégorie

• Accédez à Ressources > Catégories > Catégories Personnalisées

• Dans la liste des catégories personnalisées, localisez et sélectionnez la catégorie "Serveurs Web Internes".

• Dans les détails de la catégorie, il est observé que le membre de la catégorie "Serveurs Web Internes" correspond au Nom de Domaine Pleinement Qualifié (FQDN) de webserver.dyow-homelab.com.

• Cela indique que la correspondance avec le FQDN sera autorisée. (Pour que Cato identifie correctement le nom d'hôte, nous devons voir la requête/réponse DNS)
  

• Toute connexion qui ne correspond pas exactement au FQDN sera refusée. Par exemple, si le site Web visité inclut «www», c'est-à-dire www.webserver.dyow-homelab.com (selon la requête DNS), il ne correspondra pas au Nom de domaine complet défini dans CMA. Pour résoudre ce problème, un objet de Domaine peut être défini à la place. Cela permettra les correspondances avec tous les sous-domaines incluant le Domaine défini. Voir Cato WAN Firewall.
  
• Dans l'exemple de connexion bloquée ci-dessus, l'utilisateur a tenté d'accéder au serveur en utilisant son adresse IP de destination au lieu du FQDN. Dans ce cas, comme il n'existe aucune requête/réponse DNS, Cato n'a pas été en mesure d'identifier le nom d'hôte, et la règle n'a pas été appliquée.
• Dans les situations où un accès direct à l'IP se produit sans demande DNS préalable, Cato utilise son cache DNS pour tenter de faire correspondre un domaine à l'IP donnée. Si le cache ne contient aucun domaine, Cato sera incapable de l'associer à un nom d'hôte ou FQDN. En conséquence, la connexion dans l'exemple mentionné sera bloquée.
• Par conséquent, lorsqu'une règle de pare-feu d'autorisation est configurée pour correspondre sur la base du nom de domaine complet, le client doit accéder au serveur en utilisant son nom de domaine pour assurer une connectivité ininterrompue.
  
  Note : Si vous utilisez un serveur DNS interne, assurez-vous que toutes ses requêtes DNS sont routées via le Cato Cloud, quel que soit le serveur DNS de destination configuré. Pour les meilleures pratiques DNS, référez-vous à Meilleures-pratiques-pour-DNS-et-votre-compte-Cato 

Solutions alternatives

En cas de désaccords sur les règles du pare-feu, même après avoir accédé au site en utilisant son nom de domaine et que les requêtes/réponses DNS passent effectivement par Cato, les solutions suivantes peuvent être mises en œuvre :

• Le cache DNS sur le PC de l'utilisateur peut être différent du cache DNS sur le PoP, ce qui amènera Cato à ne pas associer l'IP du serveur avec le FQDN. Dans les cas où un serveur DNS interne est utilisé, la durée de vie (TTL) du DNS peut être raccourcie, forçant ainsi le PC à générer des requêtes DNS plus fréquemment.
• Utilisez une combinaison IP/port dans l'app/catégorie personnalisée utilisée dans la règle du pare-feu qui correspond au serveur. Dans l'exemple ci-dessus, réglez l'application personnalisée sur l'adresse IP 192.168.2.25 et le port 8080. Cela forcerait la correspondance des règles même s'il existe des désaccords de cache DNS ou des requêtes DNS manquantes sur le Cato Cloud.