Ces fonctionnalités sont appliquées à chaque nœud ASA, plutôt qu’à la grappe dans son ensemble ou au nœud de contrôle.

• QoS : la politique QoS est synchronisée dans la grappe dans le cadre de la duplication de la configuration. Cependant, la politique est appliquée sur chaque nœud indépendamment. Par exemple, si vous configurez le contrôle en sortie, les valeurs de débit de conformité et de rafale de conformité s’appliquent au trafic sortant d’un ASA particulier. Dans une grappe à 3 nœuds et avec le trafic réparti uniformément, le taux de conformité devient en fait trois fois supérieur au débit de la grappe.

• Détection des menaces : la détection des menaces fonctionne sur chaque nœud indépendamment; par exemple, les statistiques principales sont propres au nœud. La détection de l’analyse de port, par exemple, ne fonctionne pas, car l’analyse du trafic sera équilibrée entre tous les nœuds et un nœud ne verra pas tout le trafic.

• Gestion des ressources : la gestion des ressources en mode contexte multiple est appliquée séparément sur chaque nœud en fonction de l’utilisation locale.

• Trafic LISP : le trafic LISP sur le port UDP 4342 est inspecté par chaque nœud de réception, mais aucun directeur n’est affecté. Chaque nœud ajoute au tableau EID qui est partagé dans la grappe, mais le trafic LISP lui-même ne participe pas au partage de l’état de la grappe.

L’AAA pour l’accès réseau comprend trois composants : l’authentification, l’autorisation et la gestion de comptes. L’authentification et l’autorisation sont mises en œuvre en tant que fonctionnalités centralisées sur le nœud de contrôle de mise en grappe avec la duplication des structures de données sur les nœuds de données de grappe. Si un nœud de contrôle est choisi, le nouveau nœud de contrôle disposera de toute l’information nécessaire pour continuer le fonctionnement ininterrompu des utilisateurs authentifiés établis et de leurs autorisations associées. Les délais d’inactivité et absolus pour l’authentification des utilisateurs sont conservés lorsqu'un changement de nœud de contrôle se produit.

La comptabilité est mise en œuvre en tant que fonctionnalité distribuée dans une grappe. La comptabilité est effectuée flux par flux, de sorte que le nœud de la grappe possédant un flux enverra les messages de démarrage et d’arrêt de comptabilité au serveur AAA lorsque la comptabilité est configurée pour un flux.

Les limites de connexion s’appliquent à l’ensemble de la grappe (voir Configuration > Firewall > Service Policy, page). Chaque nœud dispose d’une estimation des valeurs de compteur à l’échelle de la grappe en fonction des messages de diffusion. Pour des raisons d’efficacité, la limite de connexion configurée dans la grappe pourrait ne pas être appliquée exactement au nombre limite. Chaque nœud peut surévaluer ou sous-évaluer la valeur du compteur à l’échelle de la grappe à tout moment. Cependant, les informations seront mises à jour au fil du temps dans une grappe à charge équilibrée.

• Si le canal de données et les flux du canal de contrôle FTP appartiennent à différents membres de la grappe, le propriétaire du canal de données enverra périodiquement des mises à jour du délai d’inactivité au propriétaire du canal de contrôle et mettra à jour la valeur du délai d’inactivité. Cependant, si le propriétaire du flux de contrôle est rechargé et que le flux de contrôle est réhébergé, la relation de flux parent/enfant ne sera plus maintenue; le délai d’inactivité du flux de contrôle ne sera pas mis à jour.

• Si vous utilisez l’AAA pour l’accès FTP, le flux du canal de contrôle est centralisé sur le nœud de contrôle.

La NAT peut affecter le débit global de la grappe. Les paquets NAT entrants et sortants peuvent être envoyés à différents ASAdans la grappe, car l’algorithme d’équilibrage de charge repose sur les adresses IP et les ports, et la NAT fait en sorte que les paquets entrants et sortants aient des adresses IP ou des ports différents. Lorsqu’un paquet arrive à ASA qui n’est pas le propriétaire NAT, il est transféré sur la liaison de commande de grappe vers le propriétaire, ce qui entraîne un trafic important sur la liaison de commande de grappe. Notez que le nœud de réception ne crée pas de flux de transfert vers le propriétaire, car le propriétaire de la NAT peut ne pas créer de connexion pour le paquet en fonction des résultats des vérifications de sécurité et des politiques.

Si vous souhaitez toujours utiliser la NAT en grappe, tenez compte des directives suivantes :

• PAT avec attribution de bloc de ports : Consultez les consignes suivantes pour cette fonctionnalité :

  • La limite maximale par hôte n’est pas une limite à l’échelle de la grappe et s’applique à chaque nœud individuellement. Ainsi, dans une grappe à 3 nœuds avec la limite maximale par hôte configurée à 1, si le trafic d’un hôte est équilibré en charge sur les 3 nœuds, 3 blocs avec 1 dans chaque nœud peuvent lui être alloués.

  • Les blocs de ports créés sur le nœud de sauvegarde à partir des pools de sauvegarde ne sont pas pris en compte lors de l’application de la limite maximale par hôte.

  • Les modifications des règles PAT à la volée, où l'ensemble PAT est modifié avec une toute nouvelle plage d’adresses IP, entraîneront des échecs de création de sauvegarde xlate pour les demandes de sauvegarde xlate qui étaient encore en transit lorsque le nouvel ensemble est entré en vigueur. Ce comportement n’est pas spécifique à la fonctionnalité d’attribution de bloc de ports et il s’agit d’un problème transitoire d’ensemble PAT que l’on observe uniquement dans les déploiements en grappe où l’ensemble est distribué et le trafic est équilibré en charge sur les nœuds de la grappe.

  • Lorsque vous utilisez une grappe, vous ne pouvez pas simplement modifier la taille de l’allocation de bloc. La nouvelle taille n’est en vigueur qu’après le rechargement de chaque périphérique de la grappe. Pour éviter d’avoir à téléverser chaque périphérique, nous vous recommandons de supprimer toutes les règles d’attribution de blocage et d’effacer tous les xlates associés à ces règles. Vous pouvez ensuite modifier la taille du bloc et recréer les règles d’attribution des blocs.

• Distribution des adresses de l’ensemble NAT pour la PAT dynamique : lorsque vous configurez un ensemble PAT, la grappe divise chaque adresse IP de l’ensemble en blocs de ports. Par défaut, chaque bloc comporte 512 ports, mais si vous configurez des règles d’attribution de bloc de ports, votre paramètre de blocage est utilisé à la place. Ces blocs sont répartis uniformément entre les nœuds de la grappe, de sorte que chaque nœud ait un ou plusieurs blocs pour chaque adresse IP dans l'ensemble PAT. Ainsi, vous pourriez avoir aussi peu qu’une adresse IP dans un ensemble PAT pour une grappe, si cela est suffisant pour le nombre de connexions PAT que vous attendez. Les blocs de ports couvrent la plage de ports 1 024 à 65535, sauf si vous configurez l’option pour inclure les ports réservés, 1 à 1023, dans la règle NAT de l'ensemble PAT.

• Réutiliser un pool PAT dans plusieurs règles : pour utiliser le même pool PAT dans plusieurs règles, vous devez faire attention à la sélection d’interfaces dans les règles. Vous devez soit utiliser des interfaces spécifiques dans toutes les règles, soit utiliser « any » dans toutes les règles. Vous ne pouvez pas combiner des interfaces spécifiques et « any » dans les règles, sans quoi le système pourrait ne pas être en mesure de faire correspondre le trafic de retour vers le bon nœud dans la grappe. L’option la plus fiable est l’utilisation d'ensembles de PAT uniques par règle.

• Pas de tourniquet : le tourniquet pour un ensemble PAT n’est pas pris en charge avec la mise en grappe.

• Pas de PAT étendue : la PAT étendue n'est pas prise en charge avec la mise en grappe.

• Tableaux xlates dynamiques de NAT gérés par le nœud de contrôle : le nœud de contrôle conserve et reproduit le tableau xlate sur les nœuds de données. Lorsqu’un nœud de données reçoit une connexion qui nécessite une NAT dynamique et que le xlate n’est pas dans le tableau, il le demande au nœud de contrôle. Le nœud de données est propriétaire de la connexion.

• Disques xlates périmés : le temps d’inactivité xlate sur le propriétaire de la connexion n’est pas mis à jour. Ainsi, le temps d’inactivité peut dépasser le délai d’inactivité. Une valeur de minuteur d’inactivité supérieure au délai d’expiration configuré avec un contrôle de référence de 0 est une indication d’un xlate périmé.

• Fonctionnalité PAT par session : bien qu’elle ne soit pas exclusive à la mise en grappe, la fonctionnalité PAT par session améliore l’évolutivité de PAT et, pour la mise en grappe, permet à chaque nœud de données de posséder des connexions PAT; en revanche, les connexions PAT multisessions doivent être transférées au nœud de contrôle et détenues par celui-ci. Par défaut, tout le trafic TCP et le trafic DNS UDP utilisent un xlate PAT par session, tandis que ICMP et tout le reste du trafic UDP utilise la multisession. Vous pouvez configurer des règles NAT par session pour modifier ces valeurs par défaut pour TCP et UDP, mais vous ne pouvez pas configurer la PAT par session pour ICMP. Par exemple, en raison de l’utilisation croissante du protocole Quic sur le port UDP/443 comme alternative de performance à HTTPS TLS sur TCP/443, vous devriez activer la traduction d’adresses par session (PAT) pour UDP/443. Pour le trafic qui bénéficie de la PAT multisession, comme le H.323, le SIP ou l'interface simplifiée, vous pouvez désactiver la PAT par session pour les ports TCP associés (les ports UDP de ces ports H.323 et SIP sont déjà multisession en par défaut). Référez-vous au guide de configuration du pare-feu pour obtenir plus de renseignements sur les serveurs mandataires TLS.

• Pas de PAT statique pour les inspections suivantes :

  • FTP

  • PPTP

  • RSH

  • SQLNET

  • TFTP

  • XDMCP

  • SIP

• Si vous avez un nombre extrêmement important de règles NAT, plus de dix mille, vous devez activer le modèle de validation transactionnelle à l’aide de la commande asp rule-engine transactional-commit nat dans l’interface de ligne de commande du périphérique. Sinon, le nœud pourrait ne pas être en mesure de rejoindre la grappe.

Une association SCTP peut être créée sur n’importe quel nœud (en raison de l’équilibrage de la charge); ses connexions multi-hébergement doivent résider sur le même nœud.

Un flux de contrôle peut être créé sur n’importe quel nœud (en raison de l’équilibrage de la charge); ses flux de données enfants doivent résider sur le même nœud.

La configuration du mandataire TLS n’est pas prise en charge.

Un agent SNMP interroge chaque ASA en fonction de l’adresse IP locale de son . Vous ne pouvez pas interroger les données consolidées de la grappe.

Vous devez toujours utiliser l’adresse locale, et non l’adresse IP de la grappe principale pour l’interrogation SNMP. Si l’agent SNMP interroge l’adresse IP de la grappe principale, si un nouveau nœud de contrôle est choisi, l’interrogation du nouveau nœud de contrôle échouera.

Lorsque vous utilisez SNMPv3 avec la mise en grappe et que vous ajoutez un nouveau nœud de grappe après la formation initiale de la grappe, les utilisateurs SNMPv3 ne seront pas répliqués sur le nouveau nœud.Vous devez les rajouter sur le nœud de contrôle pour forcer les utilisateurs à se reproduire vers le nouveau nœud, ou directement sur le nœud de données.

L’inspection STUN est prise en charge dans les modes de basculement et de grappe, car les sténopés sont dupliqués. Cependant, l’ID de transaction n’est pas répliqué sur les nœuds. Dans le cas où un nœud tombe en panne après avoir reçu une demande STUN et qu’un autre nœud a reçu la réponse STUN, la réponse STUN sera abandonnée.

• Syslog : chaque nœud de la grappe génère ses propres messages de journal système. Vous pouvez configurer la journalisation de sorte que chaque nœud utilise le même ID d’appareil ou un ID d’appareil différent dans le champ d’en-tête du message syslog. Par exemple, la configuration du nom d’hôte est répliquée et partagée par tous les nœuds de la grappe. Si vous configurez la journalisation pour utiliser le nom d’hôte comme ID d’appareil, les messages syslog générés par tous les nœuds semblent provenir d’un seul nœud. Si vous configurez la journalisation pour utiliser le nom de nœud local attribué dans la configuration de démarrage de la grappe comme ID d’appareil, les messages du journal système semblent provenir de nœuds différents.

• NetFlow : chaque nœud de la grappe génère son propre flux NetFlow. Le collecteur NetFlow peut traiter chaque appareil ASA uniquement comme un exportateur NetFlow distinct.

Seul le nœud de contrôle reçoit les informations des balises de groupe de sécurité (SGT). Le nœud de contrôle remplit ensuite la balise SGT pour les nœuds de données, et les nœuds de données peuvent prendre une décision de correspondance pour la balise SGT en fonction de la politique de sécurité.

Lorsqu’un nœud de la grappe tombe en panne, les connexions hébergées par ce nœud sont transférées en toute transparence vers d’autres nœuds; Les renseignements d’état sur les flux de trafic sont partagés sur la liaison de commande de grappe du nœud de contrôle.

Si le nœud de contrôle échoue, un autre membre de la grappe ayant la priorité la plus élevée (numéro le plus bas) devient le nœud de contrôle.

ASA tente automatiquement de rejoindre la grappe, en fonction de l’événement d’échec.

Remarque

Lorsque ASA devient inactif et ne parvient pas à rejoindre automatiquement la grappe, toutes les interfaces de données sont fermées; Seule l’interface de gestion uniquement peut envoyer et recevoir du trafic. L’interface de gestion reste active en utilisant l’adresse IP que le nœud a reçue de l'ensemble d’adresses IP de la grappe. Cependant, si vous rechargez et que le nœud est toujours inactif dans la grappe, l'interface de gestion est désactivée. Vous devez utiliser le port de console pour toute autre configuration.

Chaque connexion a un propriétaire et au moins un propriétaire secondaire dans la grappe. Le propriétaire de secours ne prend pas en charge la connexion en cas d’échec; au lieu de cela, il stocke les informations d’état TCP/UDP, de sorte que la connexion puisse être transférée de manière transparente à un nouveau propriétaire en cas de défaillance. Le propriétaire de la sauvegarde est généralement aussi le directeur.

Certains trafics nécessitent des informations d’état au-dessus de la couche TCP ou UDP. Consultez le tableau suivant pour connaître la prise en charge ou l’absence de prise en charge de ce type de trafic.

Consultez les rôles suivants, définis pour chaque connexion :

• Propriétaire : généralement, le nœud qui reçoit initialement la connexion. Le propriétaire gère l’état TCP et traite les paquets. Une connexion n’a qu’un seul propriétaire. Si le propriétaire d’origine échoue, lorsque les nouveaux nœuds reçoivent des paquets de la connexion, le directeur choisit un nouveau propriétaire dans ces nœuds.

• Propriétaire de la sauvegarde : nœud qui stocke les informations d’état TCP/UDP reçues du propriétaire, de sorte que la connexion puisse être transférée en toute transparence à un nouveau propriétaire en cas de défaillance. Le propriétaire de secours ne prend pas en charge la connexion en cas d’échec. Si le propriétaire devient indisponible, le premier nœud à recevoir les paquets de la connexion (selon l’équilibrage de la charge) contacte le propriétaire de secours pour obtenir les informations d’état pertinentes, afin qu’il puisse devenir le nouveau propriétaire.

  Tant que le directeur (voir ci-dessous) n’est pas le même nœud que le propriétaire, le directeur est également le propriétaire secondaire. Si le propriétaire se choisit lui-même directeur, un propriétaire de secours distinct est choisi.

  Pour la mise en grappe sur le périphérique Firepower 9300, qui peut inclure jusqu’à 3 nœuds de grappe dans un châssis, si le propriétaire de secours se trouve sur le même châssis que le propriétaire, un propriétaire de secours supplémentaire sera choisi dans un autre châssis pour protéger les flux d’une défaillance du châssis.

  Si vous activez la localisation du directeur pour la mise en grappe inter-sites, il existe deux rôles de propriétaire de la sauvegarde : le rôle de sauvegarde locale et de sauvegarde globale. Le propriétaire choisit toujours une sauvegarde locale sur le même site que lui (en fonction de l’ID du site). La sauvegarde globale peut se trouver sur n’importe quel site et peut même se trouver sur le même nœud que la sauvegarde locale. Le propriétaire envoie des informations sur l’état de la connexion aux deux sauvegardes.

  Si vous activez la redondance de sites et que le propriétaire de secours se trouve sur le même site que le propriétaire, un propriétaire de secours supplémentaire sera choisi dans un autre site pour protéger les flux d’une défaillance du site. La sauvegarde de châssis et la sauvegarde de site sont indépendantes. Par conséquent, dans certains cas, un flux comportera à la fois une sauvegarde de châssis et une sauvegarde de site.

• Directeur : nœud qui gère les demandes de recherche de propriétaire provenant des transitaires. Lorsque le propriétaire reçoit une nouvelle connexion, il choisit un directeur en fonction d’un hachage de l’adresse IP source/de destination et des ports (voir ci-dessous pour les détails du hachage ICMP) et envoie un message au directeur pour enregistrer la nouvelle connexion. Si les paquets arrivent à un nœud autre que le propriétaire, le nœud interroge le directeur sur quel nœud est le propriétaire afin qu’il puisse transférer les paquets. Une connexion n’a qu’un seul directeur. En cas de défaillance d’un directeur, le propriétaire en choisit un nouveau.

  Tant que le directeur ne se trouve pas sur le même nœud que le propriétaire, le directeur est également le propriétaire suppléant (voir ci-dessus). Si le propriétaire se choisit lui-même directeur, un propriétaire de secours distinct est choisi.

  Si vous activez la localisation de directeur pour la mise en grappe inter-sites, il y a deux rôles de directeur : le directeur local et le directeur global. Pour un paquet de nouveau flux, le membre de réception sélectionne le directeur local parmi les membres du site du membre de réception. Le directeur global peut se trouver sur n’importe quel site et peut même être le même membre que le directeur local. En cas de défaillance du propriétaire d’origine et lorsque la localisation s’applique, le directeur local choisit un nouveau propriétaire de connexion sur le site du directeur local.

  Détails du hachage ICMP/ICMPv6 :

  • Pour les paquets Echo, le port source correspond à l’identifiant ICMP et le port de destination est 0.

  • Pour les paquets de réponse, le port source est 0 et le port de destination est l’identifiant ICMP.

  • Pour les autres paquets, les ports source et de destination sont à 0.

• Transitaire : nœud qui transfère les paquets au propriétaire. Si un transitaire reçoit un paquet pour une connexion qu’il ne possède pas, il interroge le directeur à propos du propriétaire, puis établit un flux vers le propriétaire pour tout autre paquet qu’il reçoit pour cette connexion. Le directeur peut également être un transitaire. Si vous activez la localisation de directeur, le redirecteur interroge le directeur local lorsque la localisation s’applique. Le transitaire interroge le directeur global si le directeur local ne connaît pas le propriétaire, si la connexion appartient à un autre site ou si la localisation est contournée. Une requête de directeur intersite est le comportement attendu dans ces cas. Notez que si un transitaire reçoit le paquet SYN-ACK, il peut en dériver le propriétaire directement d’un témoin SYN dans le paquet, donc il n’a pas besoin d’interroger le directeur. (Si vous désactivez la répartition aléatoire de la séquence TCP, le témoin SYN n’est pas utilisé; une requête au directeur est requise.) Pour les flux de courte durée tels que DNS et ICMP, au lieu d’interroger, le redirecteur envoie immédiatement le paquet au directeur, qui l’envoie ensuite au propriétaire. Une connexion peut avoir plusieurs redirecteurs; le débit le plus efficace est obtenu par une bonne méthode d’équilibrage de la charge où il n’y a pas de redirecteurs et où tous les paquets d’une connexion sont reçus par le propriétaire.

  Remarque

  Nous vous déconseillons de désactiver la répartition aléatoire de la séquence TCP lors de l’utilisation de la mise en grappe. Il y a un faible risque que certaines sessions TCP ne soient pas établies, car le paquet SYN/ACK sera abandonné.

• Propriétaire de fragment : pour les paquets fragmentés, les nœuds de la grappe qui reçoivent un fragment déterminent le propriétaire du fragment à l’aide d’un hachage de l’adresse IP source du fragment, de l’adresse IP de destination et de l’ID de paquet. Tous les fragments sont ensuite transférés au propriétaire du fragment sur la liaison de commande de grappe. Les fragments peuvent être équilibrés en charge vers différents nœuds de grappe, car seul le premier fragment comprend le quintuple utilisé dans le hachage d’équilibrage de charge du commutateur. Les autres fragments ne contiennent pas les ports source et de destination et peuvent être répartis en charge vers d’autres nœuds de la grappe. Le propriétaire du fragment rassemble temporairement le paquet afin de pouvoir déterminer le directeur en fonction d’un hachage de l’adresse IP source/de destination et des ports. S’il s’agit d’une nouvelle connexion, le propriétaire du fragment s’enregistrera en tant que propriétaire de la connexion. S'il s’agit d’une connexion existante, le propriétaire du fragment transfère tous les fragments au propriétaire de la connexion fourni par la liaison de commande de grappe. Le propriétaire de la connexion rassemblera ensuite tous les fragments.

L’exemple suivant montre l’établissement d’une nouvelle connexion.

1. Le paquet SYN provient du client et est livré à un ASA (selon la méthode d’équilibrage de la charge), qui devient le propriétaire. Le propriétaire crée un flux, code les renseignements sur le propriétaire dans un témoin SYN et transfère le paquet au serveur.

2. Le paquet SYN-ACK provient du serveur et est livré à un ASA différent (selon la méthode d’équilibrage de la charge). Cet ASA est le transitaire.

3. Comme le transitaire n’est pas propriétaire de la connexion, il décode les informations sur le propriétaire à partir du témoin SYN, crée un flux de transfert vers le propriétaire et transmet le SYN-ACK au propriétaire.

4. Le propriétaire envoie une mise à jour de l’état au directeur et transmet le SYN-ACK au client.

5. Le directeur reçoit la mise à jour d’état du propriétaire, crée un flux à destination du propriétaire et enregistre les informations d’état TCP ainsi que le propriétaire. Le directeur agit en tant que propriétaire secondaire pour la connexion.

6. Tous les paquets suivants livrés au transitaire seront transférés au propriétaire.

7. Si des paquets sont livrés à d’autres nœuds, il interrogera le directeur à propos du propriétaire et établira un flux.

8. Tout changement d’état du flux entraîne une mise à jour d’état du propriétaire au directeur.

L’exemple suivant montre l’établissement d’une nouvelle connexion.

1. 

   Le premier paquet UDP provient du client et est remis à un ASA (selon la méthode d’équilibrage de la charge).

2. Le nœud qui a reçu le premier paquet interroge le nœud directeur qui est choisi en fonction d’un hachage de l’adresse IP et des ports source/de destination.

3. Le directeur ne trouve aucun flux existant, crée un flux de directeur et renvoie le paquet au nœud précédent. Autrement dit, le directeur a choisi un propriétaire pour ce flux.

4. Le propriétaire crée le flux, envoie une mise à jour d’état au directeur et transfère le paquet au serveur.

5. Le deuxième paquet UDP provient du serveur et est livré au redirecteur.

6. Le transitaire interroge le directeur pour fournir les renseignements sur la propriété. Pour les flux de courte durée tels que le DNS, au lieu d’interroger, le redirecteur envoie immédiatement le paquet au directeur, qui l’envoie ensuite au propriétaire.

7. Le directeur répond au transitaire avec les renseignements de propriété.

8. Le transitaire crée un flux de transfert pour enregistrer les informations sur le propriétaire et transfère le paquet au propriétaire.

9. Le propriétaire transfère le paquet au client.