Ces fonctionnalités ne peuvent pas être configurées lorsque la mise en grappe est activée, et les commandes seront rejetées.

Remarque

Pour afficher les fonctionnalités FlexConfig qui ne sont pas non plus prises en charge avec la mise en grappe, par exemple l’inspection WCCP, consultez le guide de configuration des opérations générales ASA. FlexConfig vous permet de configurer de nombreuses fonctionnalités ASA qui ne sont pas présentes dans l’interface graphique .

• VPN d'accès à distance (VPN SSL et VPN IPsec)

• Le VPN de site à site (basé sur des politiques et basé sur des routes) n’est pas pris en charge dans les nuages publics.

• Client DHCP, serveur et serveur mandataire. Le relais DHCP est pris en charge.

• Interfaces de tunnel virtuel (VTI)

• Haute disponibilité

• Routage et pont intégrés

• Mode UCAPL/CC

• Client DHCP, serveur et serveur mandataire. Le relais DHCP est pris en charge.

Les limites de connexion s’appliquent à l’ensemble de la grappe. 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.

La NAT peut affecter le débit global de la grappe. Les paquets NAT entrants et sortants peuvent être envoyés à différents Firewall Threat Defense dans 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 à Firewall Threat Defense 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 blocs de ports 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 taille de bloc 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’interface 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.

• 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é.

• Pas de PAT statique pour les inspections suivantes :

  • FTP

  • 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.

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.

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 supprimer les utilisateurs, les rajouter, puis redéployer votre configuration pour forcer la réplication des utilisateurs sur le nouveau nœud.

• 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.

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.

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

Remarque

Lorsque Firewall Threat Defense devient inactif et ne parvient pas à rejoindre automatiquement la grappe, toutes les interfaces de données sont fermées; Seule l’interface peut envoyer et recevoir du trafic.

Chaque connexion a un propriétaire et au moins un propriétaire de secours 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 secours 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 secours : 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 de secours. 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.

• 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 de secours (voir ci-dessus). Si le propriétaire se choisit lui-même directeur, un propriétaire de secours distinct est choisi.

  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. 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 transitaire envoie immédiatement le paquet au directeur, qui l’envoie ensuite au propriétaire. Une connexion peut avoir plusieurs transitaires; 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 transitaires 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 Firewall Threat Defense (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 Firewall Threat Defense différent (selon la méthode d’équilibrage de la charge). Ce Firewall Threat Defense 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 de secours 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, ceux-ci interrogeront 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 Firewall Threat Defense (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 transitaire.

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 transitaire 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.