Dépannage de l'évaluation des règles réseau

Vue d'ensemble

Assurer une évaluation précise des règles réseau est crucial pour prendre des décisions de routage informées. Ce guide de dépannage vise à aborder de manière exhaustive divers symptômes courants, explorer les causes potentielles et offrir des étapes systématiques pour résoudre les problèmes liés à l'évaluation des règles réseau.

Symptômes

Un échec à évaluer le trafic par rapport aux règles réseau peut se manifester de plusieurs façons. Un administrateur peut noter les symptômes suivants :

  • Source IP publique incorrecte
  • Inadéquation de règle réseau
  • Interface WAN incorrecte sélectionnée
  • L'accélération TCP est appliquée ou ignorée
  • Inadéquation de priorité QoS
  • Off-Cloud ou Alt-WAN interrompent les connexions de trafic

Causes possibles

  • Inadéquation d'application personnalisée ou intégrée
  • Domaine incompatible
  • PoP d'égressement incorrect choisi
  • Connexions WAN non saines
  • Une application bloquée ou non identifiée entraîne une priorité QoS fixe
  • Ordre incorrect des règles réseau

Évaluation initiale

Remarque

Note : Assurez-vous d'avoir une Règle de pare-feu (même temporairement créée pour des fins de dépannage) avec suivi d'événement activé qui inclura le trafic prévu pour correspondre à la Règle réseau configurée.

Passez en revue les événements de pare-feu en sélectionnant les préréglages Pare-feu Internet ou Pare-feu WAN dans CMA. Définir des filtres pour restreindre le trafic intéressant. Analysez les champs pertinents tels que Applications concernées, Application, Application Cato, Nom PoP d'égressement, IP source publique, IP de destination, Nom de domaine, Règle réseau, et Accélération TCP qui vous aideront à identifier la cause profonde possible du problème.

Assurez-vous d’examiner la section de dépannage appropriée en identifiant les symptômes signalés par les utilisateurs :

Dépannage du problème

Dépannage des adresses IP source publique incorrectes

Il est parfois nécessaire de définir une IP source publique spécifique pour accéder à un service Internet restreint, comme expliqué dans Comment configurer une règle d'égressement. Si le service signale une IP source publique inattendue, suivez les étapes ci-dessous.

Révision de plusieurs IPs d'égressement

Pour les règles réseau avec plusieurs adresses IP d'égressement, le Cato Cloud utilise l'adresse IP d'égressement pour le PoP géographiquement le plus proche de la source. Si la première adresse IP sortante est indisponible, le cloud Cato passe automatiquement à la deuxième adresse IP sortante. La capture d'écran suivante montre un exemple de règle réseau avec deux adresses IP d'égressement.

Dans cet exemple, une règle réseau peut faire sortir le trafic du PoP de New York ou du PoP de Chicago. Si la source est physiquement plus proche du PoP de New York, Cato tentera de faire sortir le trafic spécifique du PoP à New York. Si la destination n'est pas accessible depuis le PoP de New York, Cato fera alors sortir le trafic du PoP de Chicago.

Pour changer ce comportement, consultez Changement de sélection de PoP d'égressement.

IPs d'égressement non disponibles

Il est possible qu'une règle réseau contenant une seule IP d'égressement fasse sortir le trafic en utilisant une IP publique de Cato différente de celle configurée. Cela peut être possible lorsque le PoP associé à l'IP d'égressement est temporairement indisponible pendant une fenêtre de maintenance. Cette situation peut être critique, surtout pour les applications VoIP.

Pour changer ce comportement, consultez Changement de sélection de PoP d'égressement.

Vérification des changements de règle réseau

Si la règle réseau a été récemment modifiée avec une adresse IP d'égressement. Gardez à l'esprit que seuls les nouveaux flux de trafic générés utiliseront la nouvelle IP d'égressement. Les flux de trafic existants conserveront l'IP d'égressement associée au moment où le flux a été créé.

Le comportement précédent est généralement courant avec le trafic VoIP où le flux SIP reste actif pendant longtemps. Pour résoudre ce problème, le téléphone VoIP peut être redémarré, ce qui déclenchera la création d'un nouveau flux SIP qui sera routé selon l'IP d'égressement mise à jour de la règle réseau.

Dépannage des inadéquations de règles réseau

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

Analyse des événements de pare-feu

Identifiez les champs pertinents, tels que Applications concernées, Application, Application Cato, IP de destination, Nom de domaine, et Règle réseau à partir de l'événement de pare-feu. Ces informations vous aideront à diagnostiquer la raison de l'inadéquation de la règle réseau.

Vérification des exceptions de règles réseau

Identifiez toute exception ajoutée à la règle réseau. Si le flux de trafic correspond à l'exception ajoutée, la règle réseau sera ignorée et la recherche de règles continuera avec le reste de la base de règles jusqu'à ce qu'une correspondance soit trouvée.

Vérification de l'application personnalisée

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

Pour éviter ce problème, veuillez consulter la section Résolution d'application personnalisée superposée.

Vérification de l'application intégrée

Si le trafic intéressant est censé correspondre à une application intégrée et que le trafic correspond à la mauvaise règle réseau, vérifiez les points suivants :

  • Quelles applications sont configurées dans la mauvaise règle réseau correspondante.
  • Si l'une de ces applications est répertoriée dans le champ Applications concernées de l'événement FW.

L'identification de l'application est un processus en plusieurs étapes qui commence par identifier le protocole, puis toutes les applications potentielles pouvant correspondre qui sont incluses dans le champ Applications concernées. Toute application « concernée » identifiée dans un flux, indépendamment de la décision de l'application finale (champ Application), correspondra à une règle réseau.

Dans l'exemple ci-dessous, l'accès à portal.azure.com correspond à la règle #7 au lieu de la règle #8. Cela est dû au fait que la règle #7 inclut l'application Microsoft Azure (inclus dans les Applications concernées) même si l'application finale (champ Application) est Azure Front Door.

Pour résoudre ce comportement attendu, consultez Ordonnancement des règles réseau

Vérification du nom de domaine

Si une règle réseau 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 réseau doit être identique à ce champ.

Gardez à l'esprit qu'un FQDN est une correspondance exacte du domaine complètement qualifié. Par exemple, le nom de domaine complet example.com ne correspond qu'à example.com.

D'autre part, un Domaine est un domaine de premier niveau (TLD) ou de second 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, consultez Résolution des problèmes de nom de domaine

Dépannage de l'interface WAN incorrecte sélectionnée

Cette section aborde le scénario où Cato est sélectionné comme transport avec les deux interfaces WAN configurées dans un déploiement Actif/Actif. Pour plus d'informations sur le routage basé sur les politiques, consultez Comment Cato sélectionne le meilleur transport ou lien

Remarque

Remarque : Les champs Nom de l'ISP et Source ISP IP dans la règle de FW peuvent ne pas être une bonne indication pour déterminer quel lien WAN est utilisé par le trafic. Ceci est dû au fait que le flux de trafic peut changer plusieurs fois de tunnel au cours de sa durée de vie.

Révision de la configuration du transport de règles de réseau

Si un déploiement Actif/Actif doit être atteint, le rôle de l'interface principale doit être réglé sur Automatique ou les deux rôles d'interface principale et secondaire doivent être configurés comme montré dans la capture d'écran ci-dessous. Régler le rôle de l'interface secondaire sur Aucun entraînera l'absence de basculement du trafic lorsque l'interface principale devient indisponible. Consulte Routage du trafic sur les interfaces Socket

Révision de l'analytique réseau

Le widget Avg Throughput affichera l'utilisation moyenne de la largeur de bande pour chaque lien WAN. Cela peut servir d'indicateur pour confirmer que la règle de réseau sélectionne la bonne connexion WAN ou équilibre correctement le trafic. Dans la capture d'écran ci-dessous, la règle de réseau a été modifiée pour sélectionner WAN2 comme transport principal.

Il est important de surveiller la performance du lien WAN, en particulier pour la perte de paquets, la gigue et la distance. Comme expliqué dans Distribution du trafic Actif/Actif, si un lien ne respecte pas les seuils de qualité de lien minimaux, il sera considéré comme malsain et ne sera pas sélectionné pour la distribution de trafic, même si le lien WAN est sélectionné comme transport principal.

Révision de l'interface WebUI du Socket

Un moyen simple de savoir si le Socket considère un lien comme malsain est la page Monitoring dans l'interface WebUI du Socket. Si les métriques de latence, de gigue ou de perte de paquets ne répondent pas aux exigences minimales, la valeur malsaine sera marquée en rouge.

Dans l'exemple ci-dessous, WAN1 a une latence assez élevée, ce qui amène le Socket à considérer le lien comme malsain. Ce problème doit être soulevé avec votre fournisseur d'accès à Internet.

Vérification de la configuration du lien WAN

Si tous les liens actif/actif sont sains, vérifiez la configuration de la largeur de bande pour chaque lien WAN dans CMA. Dans l'exemple ci-dessous, le lien WAN1 est configuré avec une largeur de bande de 100 Mbps descendant/montant, et le lien WAN2 est configuré avec 20 Mbps descendant/montant. Cela aura pour résultat d'envoyer plus de trafic à WAN1 dans un ratio de 100:20 ou 5:1 pour les directions montante et descendante.

Dépannage de l'accélération TCP appliquée ou sautée

Comme discuté dans Explication de l'accélération TCP de Cato, l'accélération TCP peut être activée dans une règle de réseau pour accélérer les connexions TCP sur le WAN. Cette fonctionnalité est généralement appliquée dans certains scénarios et l'administrateur peut ne pas être en mesure de la désactiver même si l'option Accélération TCP active dans la règle est décochée. Cette section aborde ces scénarios et comment désactiver la fonctionnalité lorsque cela est nécessaire.

Quand l'accélération TCP est appliquée

L'accélération TCP sera appliquée lorsque la règle de réseau utilise une IP de sortie ou un emplacement de sortie. Cela oblige le PoP à agir comme un proxy ce qui, à son tour, applique l'accélération TCP à tous les flux de trafic qui correspondent à la règle. La case à cocher dans la règle de réseau sera grisée.

Désactiver l'accélération TCP dans une règle de réseau ne désactivera pas la fonctionnalité quand :

  • L'inspection TLS est activée pour le compte, ce qui activera l'accélération TCP pour tout le trafic TLS même s'il est contourné TLS. Cela est dû au fait que le PoP doit agir comme un proxy pour inspecter le trafic à la recherche de fichiers malveillants et de menaces.
  • Une règle de réseau complexe existe au-dessus de la règle de réseau correspondante avec l'accélération TCP désactivée
  • La règle de réseau qui a l'accélération TCP désactivée est elle-même complexe.

Une règle de réseau complexe (également appelée règle NG) est une règle de réseau que le Socket lui-même ne peut pas évaluer. Il peut contenir : Applications, catégories d'applications, services, applications personnalisées ou objets de domaine/FQDN. Elle peut contenir : Applications, Catégories d'Applications, Services, Applications Personnalisées ou objets de Domain/FQDN.

D'autre part, une règle simple peut contenir les entités suivantes qui peuvent être évaluées par le Socket et n'ont pas besoin de l'intervention du PoP :

  • Dans le champ App/Catégorie : Plage de ports ou un service personnalisé.
  • Dans le champ App/Catégorie : Plage de Ports ou un Service Personnalisé.

Quand l'Accélération TCP est sautée

L'Accélération TCP sera appliquée uniquement au trafic TCP. Au cas où l'Accélération TCP est activée dans la règle de réseau ou appliquée comme expliqué dans la section précédente, mais le champ Accélération TCP dans l'événement CMA est 0, il est possible que le routage asymétrique sur le Cato Cloud cause le flux de trafic à être détecté comme Mode Ouvert.

Comme expliqué dans Routage asymétrique sur Cato, Mode Ouvert est un mode de connexion dans lequel le Cato Cloud n'est pas conscient du début du flux TCP (handshake en trois étapes), empêchant l'application de l'Accélération TCP. Nous vous recommandons de travailler avec le Support Cato pour déterminer la cause racine de la création de flux en Mode Ouvert.

Désactivation de l'Accélération TCP

Pour désactiver l'Accélération TCP, une règle simple sans IP de sortie ou d'emplacement peut être placée au-dessus de la base des règles de réseau comme décrit dans Ordre des règles de réseau. Comme mentionné ci-dessus, si le trafic est TLS, l'Inspection TLS doit être désactivée pour l'ensemble du Compte.

Dépannage du décalage de priorité QoS

Comme expliqué dans Quand un flux est-il assigné à une priorité QoS de 255, il pourrait y avoir des cas où la priorité QoS configurée dans la règle de réseau est différente de la priorité montrée dans l'événement FW.

La priorité QoS 255 est considérée comme la priorité par défaut pour la Gestion de BW. Il y a plusieurs raisons pour lesquelles un flux peut se voir attribuer une priorité QoS de 255, indépendamment de la configuration de la priorité bw de la règle de réseau :

  • Cato évalue le profil réseau de chaque flux, et la priorité QoS de 255 est assignée lorsque l'application spécifique n'a pas encore été identifiée.
  • Les premiers paquets (avant que le flux ne soit identifié) reçoivent une priorité QoS de 255.
  • Les flux bloqués sont attribués avec la priorité QoS 255.

Dépannage des connexions de trafic hors nuage ou Alt-WAN  

Cette section aborde le scénario où les connexions TLS ne parviennent pas à être établies entre les sites lorsque la règle de réseau WAN est configurée avec Off-Cloud ou Alt-WAN comme transport principal. Pour résoudre ce problème, suivez les étapes ci-dessous.

Analyse du flux

Lorsque le trafic est correctement routé via Off-cloud ou Alt-WAN, les flux de trafic ne génèrent pas d'événements FW dans CMA parce que ce trafic ne passe pas par le PoP.

Un moyen de confirmer que le trafic est correctement routé via Off-Cloud ou Alt-WAN est à partir de l'onglet SDWAN dans le Socket WebUI. Identifiez le flux de trafic actif et sous NIC Choisi vous verrez le transport sélectionné pour le trafic intéressant. Si le transport attendu n'est pas sélectionné, confirmez que Off-Cloud ou Alt-WAN sont correctement configurés.

Vérification de l'ordre des règles de réseau

Comme expliqué dans Échec de connexion TLS sur les liens Off-Cloud ou Alt-WAN, lorsque le trafic est TLS et que l'inspection TLS est activée, l'ordre des règles de réseau est un facteur important pour assurer le flux de trafic sur les liens Off-Cloud ou Alt-WAN.

Les Sockets ne peuvent pas évaluer les règles de réseau et router les paquets sur Off Cloud ou Alt-WAN lorsque la règle de réseau que le trafic touche est en dessous d'une règle complexe. Pour résoudre ce comportement attendu, voir Ordonnancement des Règles Réseau

Résolution des Problèmes Découverts

Résolution des Applications Personnalisées Chevauchantes

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 quant à l'application personnalisée choisie pour l'identification, donc 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, voir Travailler avec des Applications Personnalisées

Ordonnancement des Règles Réseau

Gardez à l'esprit que les Règles Réseau sont évaluées selon leur ordre, il est donc important de définir des règles plus spécifiques avant des règles plus générales. Par exemple, les Règles Réseau 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 Réseau 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é incluant des plages IP pour twitter.com et est placée au-dessus de 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 une meilleure correspondance pour le 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 Réseau basés sur le Domaine/FQDN peuvent être résolus de la manière suivante :

  • Pour les protocoles comme HTTP/S, Cato peut déterminer le domaine de destination en utilisant les sources suivantes :

    • En-tête du 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 des réponses DNS

  • Il est important de s'assurer que le domaine spécifié dans la Règle réseau est cohérent sur toutes ces sources. Notez que seul le nom de domaine le mieux correspondant (é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 de domaine en texte brut, Cato s'appuie exclusivement sur l'interception DNS pour associer le trafic à un domaine ou à un nom de domaine complet. C'est particulièrement crucial lorsque vous utilisez un DNS privé, car nous devons nous assurer que les requêtes/réponses DNS passent par Cato. Consulte Meilleures Pratiques pour le DNS et votre Compte Cato

Changement de Sélection de PoP de Sortie

Si vous souhaitez router toutes les règles de sortie pour le compte via le PoP le plus proche de la destination, au lieu de la source (comportement par défaut), veuillez contacter le Support Cato Networks en Soulevant un cas au Support Cato.

Pour les applications VoIP utilisant le protocole SIP qui nécessitent toujours l'utilisation de la même IP de Sortie, activez l'option IP Préférée pour le Trafic SIP dans les paramètres avancés.

Si un autre protocole VoIP ou toute autre Application nécessite toujours l'utilisation de la même IP de Sortie, veuillez contacter le Support Cato Networks en Soulevant un cas au Support Cato.

Soulevant un 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 global sur les utilisateurs.
  • Événements de pare-feu associés et configuration des Règles Réseau.
  • Reproduisez le problème et exécutez le Support en Libre-Service. Incluez le numéro de ticket généré par l'Outil.

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

Utilisateurs qui ont trouvé cela utile : 2 sur 2

0 commentaire