Haute disponibilité multinodale à deux nœuds

Groupes de redondance de services

Un groupe de redondance de services (SRG) est une unité de basculement dans une configuration haute disponibilité à plusieurs nœuds. Il existe deux types de SSR :

• SRG0 : gère le service de sécurité de la couche 4 à la couche 7, à l’exception des services VPN IPsec. Le SRG0 fonctionne en mode actif sur les deux nœuds à tout moment. Sur SRG0, chaque session de sécurité doit traverser le nœud dans un flux symétrique, La sauvegarde de ces flux est entièrement synchronisée avec l’autre nœud,
• SRG1+ : gère les services IPsec et les adresses IP virtuelles en mode passerelle hybride et par défaut, et les sauvegarde sur l’autre nœud. Le SRG1 fonctionne en mode actif sur un nœud et en nœud de secours sur un autre nœud.

La figure 8 montre SRG0 et SRG1 dans une configuration haute disponibilité à plusieurs nœuds.

Figure 8 : Prise en charge d’un seul SRG en haute disponibilité multi nodale (mode de sauvegarde active)

La figure 9 montre SRG0 et SRG1+ dans une configuration haute disponibilité à plusieurs nœuds.

Figure 9 : Prise en charge de Multi SRG en haute disponibilité multinodale (mode actif-actif)

À partir de la version 22.4R1 de Junos OS, vous pouvez configurer la haute disponibilité multinodale pour qu’elle fonctionne en mode actif-actif avec prise en charge de plusieurs SRG1 (SRG1+). Dans ce mode, certains SRG restent actifs sur un nœud et d’autres restent actifs sur un autre nœud. Un SRG particulier fonctionne toujours en mode de sauvegarde active ; Il fonctionne en mode actif sur un nœud et en mode sauvegarde sur un autre nœud. Dans ce cas, les deux nœuds peuvent avoir les services dynamiques de transfert SRG1 actifs. Chaque nœud possède un ensemble différent d’adresses IP flottantes attribuées à SRG1+.

Le Tableau 1 explique le comportement des SRG dans une configuration haute disponibilité à plusieurs nœuds.

À partir de la version 23.4R1 de Junos OS, la configuration haute disponibilité multi nœuds fonctionne en mode combiné. Vous n’avez pas besoin de redémarrer le système lorsque vous ajoutez ou supprimez des configurations SRG (SRG0 ou SRG1+).

Détermination de l’activité et application

Dans une configuration haute disponibilité à plusieurs nœuds, l’activité est déterminée au niveau du service et non au niveau du nœud. L’état actif/de secours se situe au niveau du SRG et le trafic est dirigé vers le SRG actif. SRG0 reste actif sur les deux nœuds, tandis que SRG1 peut rester actif ou en état de sauvegarde dans chaque nœud

Si vous préférez qu’un certain nœud prenne le relais en tant que nœud actif au démarrage, vous pouvez effectuer l’une des opérations suivantes :

• Configurez les routeurs en amont pour inclure des préférences pour le chemin où se trouve le nœud.
• Configurez la priorité d’activité.
• Autorisez le nœud avec un ID de nœud plus élevé (dans le cas où les deux options ci-dessus ne sont pas configurées) à prendre le rôle actif.

Dans une configuration haute disponibilité à plusieurs nœuds, les deux pare-feu SRX Series annoncent initialement la route de l’adresse IP flottante vers les routeurs en amont. Il n’y a pas de préférence spécifique entre les deux chemins annoncés par les pare-feu SRX Series. Cependant, le routeur peut avoir ses propres préférences sur l’un des chemins en fonction des mesures configurées.

La figure 10 représente la séquence d’événements pour la détermination de l’activité et l’application de l’activité.

Figure 10 : Détermination de l’activité et application de la loi

1. Au démarrage, les appareils passent en mode attente et commencent à sonder en continu. Les appareils utilisent l’adresse IP flottante (adresse IP source de sonde d’activité) comme adresse IP source et les adresses IP des routeurs en amont comme adresse IP de destination pour la sonde de détermination de l’activité.

2. Le routeur hébergeant l’adresse IP de destination de la sonde répond au pare-feu SRX Series disponible sur son chemin de routage préféré. Dans l’exemple suivant, SRX-1 obtient la réponse du routeur en amont.

   Figure 11 : Détermination de l’activité et application de la loi

3. SRX-1 se promeut au rôle actif depuis qu’il a reçu la réponse de la sonde. Le SRX-1 communique son changement de rôle à l’autre appareil et assume le rôle actif.

4. Une fois l’activité déterminée, le nœud actif (SRX-1) :

   • Héberge l’adresse IP flottante qui lui a été attribuée.
   • Annonce le chemin de préférence élevée aux voisins BGP adjacents.
   • Continue d’annoncer le chemin de préférence actif (le plus élevé) pour toutes les routes distantes et locales afin d’attirer le trafic.
   • Notifie l’état du nœud actif à l’autre nœud via l’ICL.

5. L’autre périphérique (SRX-2) arrête de sonder et prend le rôle de sauvegarde. Le nœud de sauvegarde annonce la priorité par défaut (inférieure), ce qui permet aux routeurs en amont de ne pas transférer de paquets au nœud de secours.

Le module Multinode High Availability ajoute des routes de signal actives et de secours pour le SRG à la table de routage lorsque le nœud passe au rôle actif. En cas de défaillance d’un nœud, l’ICL tombe en panne et le nœud actif actuel libère son rôle actif et supprime la route du signal actif. Le nœud de secours détecte alors la condition via ses sondes et passe au rôle actif. La préférence de route est permutée pour diriger tout le trafic vers le nouveau nœud actif.

Le commutateur dans l’annonce des préférences de routage fait partie des stratégies de routage configurées sur les pare-feu SRX Series. Vous devez configurer la politique de routage pour inclure la route du signal actif avec la if-route-exists condition.

• Pour les déploiements de passerelles par défaut
• Pour les déploiements hybrides
• Priorité active et préemption
• Configuration des paramètres de sonde d’activité

Résilience et basculement

La solution haute disponibilité multinodale prend en charge la redondance au niveau du service. La redondance au niveau du service minimise l’effort nécessaire pour synchroniser le plan de contrôle sur les nœuds.

Une fois que le programme d’installation de haute disponibilité multinodale a déterminé l’activité, il négocie l’état de haute disponibilité (HA) suivant via l’ICL. Le nœud de secours envoie des sondes ICMP à l’aide de l’adresse IP flottante. Si l’ICL est actif, le nœud reçoit la réponse à sa sonde et reste le nœud de secours. Si l’ICL est en panne et qu’il n’y a pas de réponse de la sonde, le nœud de secours passe au nœud actif.

Le SRG1 du nœud de sauvegarde précédent passe maintenant à l’état actif et continue de fonctionner de manière transparente. Lorsque la transition se produit, l’adresse IP flottante est attribuée au SRG1 actif. De cette façon, l’adresse IP flotte entre les nœuds actifs et de secours et reste accessible à tous les hôtes connectés. Ainsi, le trafic continue à circuler sans aucune perturbation.

Les services, tels que le VPN IPsec, qui nécessitent à la fois des états de plan de contrôle et de plan de données sont synchronisés sur les nœuds. Chaque fois qu’un nœud actif échoue pour cette fonction de service, le plan de contrôle et le plan de données basculent simultanément vers le nœud de secours.

Les nœuds utilisent les messages suivants pour synchroniser les données :

• Messages de l’application de contrôle du moteur de routage vers le moteur de routage
• Messages liés à la configuration du moteur de routage
• Messages RTO du plan de données

Chiffrement des liaisons interchâssis (ICL)

Dans la haute disponibilité multinodale, les nœuds actif et de secours communiquent entre eux à l’aide d’une liaison interchâssis (ICL) connectée sur un réseau routé ou connectée directement. L’ICL est une liaison IP logique établie à l’aide d’adresses IP routables dans le réseau.

Les nœuds utilisent l’ICL pour synchroniser les états du plan de contrôle et du plan de données entre eux. La communication ICL peut passer par un réseau partagé ou non fiable, et les paquets envoyés sur l’ICL peuvent emprunter un chemin qui n’est pas toujours fiable. Par conséquent, vous devez sécuriser les paquets traversant l’ICL en chiffrant le trafic à l’aide des normes IPsec.

IPsec protège le trafic en établissant un tunnel de chiffrement pour l’ICL. Lorsque vous appliquez le chiffrement de liaison HA, le trafic HA circule entre les nœuds uniquement via le tunnel sécurisé et chiffré. Sans chiffrement des liaisons HA, la communication entre les nœuds peut ne pas être sécurisée.

Pour chiffrer le lien HA pour l’ICL :

• Installez le package Junos IKE sur votre pare-feu SRX Series à l’aide de la commande suivante :

  request system software add optional://junos-ike.tgz .

• Configurez un profil VPN pour le trafic HA et appliquez le profil aux deux nœuds. Le tunnel IPsec négocié entre les pare-feu SRX Series utilise le protocole IKEv2.

• Assurez-vous d’avoir inclus la déclaration ha-link-encryption dans votre configuration VPN IPsec. Exemple : user@host# set security ipsec vpn vpn-name ha-link-encryption.

Nous vous recommandons ce qui suit pour configurer une ICL :

• Utilisez des ports et un réseau moins saturés.

• Ne pas utiliser les ports HA dédiés (ports de contrôle et de fabric, si disponibles sur votre pare-feu SRX Series)

• Liez l’ICL à l’interface de bouclage (lo0) ou à une interface Ethernet agrégée (ae0) et disposez de plusieurs liaisons physiques (LAG/LACP) qui garantissent une diversité de chemins pour une résilience maximale.

• Vous pouvez utiliser un port Ethernet payant sur les pare-feu SRX Series pour configurer une connexion ICL. Assurez-vous de séparer le trafic de transit dans les interfaces payantes du trafic haute disponibilité (HA).

• Des contrôles de validation ont été introduits pour restreindre la configuration de tunnel MTU pour les tunnels de chiffrement de liens HA dans une configuration à haute disponibilité multi-nœuds. Le contrôle de validation garantit que la MTU de bout en bout pour les liaisons HA utilisant le chiffrement IPv6 répond à l’exigence minimale de 2000 octets, ce qui permet de maintenir des performances et une fiabilité optimales pendant les opérations de haute disponibilité.

  Par exemple, si votre configuration inclut la strophe suivante où tunnel-mtu est inférieur à 2000, vous recevrez une erreur de vérification de validation : user@host# set security ipsec vpn L3HA_IPSEC_VPN tunnel-mtu <octets>

Voir Configuration de la haute disponibilité multi nodale pour plus de détails.

Chiffrement des liens PKI pour ICL

À partir de la version 22.3R1 de Junos OS, nous prenons en charge le chiffrement des liens PKI pour les liaisons interchâssis (ICL) en haute disponibilité multinodale. Dans le cadre de cette prise en charge, vous pouvez désormais générer et stocker des objets PKI spécifiques à un nœud, tels que des paires de clés locales, des certificats locaux et des demandes de signature de certificat sur les deux nœuds. Les objets sont spécifiques aux nœuds locaux et sont stockés à des emplacements spécifiques sur les deux nœuds.

Les objets locaux du nœud vous permettent de distinguer les objets PKI utilisés pour le chiffrement ICL des objets PKI utilisés pour le tunnel VPN IPsec créé entre deux points de terminaison.

Vous pouvez utiliser les commandes suivantes exécutées sur le nœud local pour utiliser des objets PKI spécifiques au nœud.

Sur votre équipement de sécurité en haute disponibilité multinodale, si vous avez configuré l'option de réinscription automatique et si l'ICL tombe en panne au moment du déclenchement de la réinscription, les deux appareils commencent à enrôler le même certificat séparément auprès du serveur d'AC et téléchargent le même fichier CRL. Une fois que la haute disponibilité multinodale rétablit l’ICL, la configuration n’utilise qu’un seul certificat local. Vous devez synchroniser les certificats du nœud actif vers le nœud de sauvegarde à l’aide de la user@host> request security pki sync-from-peer commande sur le nœud de sauvegarde.

Si vous ne synchronisez pas les certificats, le problème d'incompatibilité de certificat entre les nœuds pairs persiste jusqu'à la prochaine réinscription.

En option, vous pouvez activer le TPM (module Trusted Platform) sur les deux nœuds avant de générer des paires de clés sur les nœuds. Voir Utilisation du Trusted Platform Module pour lier des secrets sur les périphériques SRX Series.

Split-Brain Sablage basé sur l’ICMP

Imaginez un scénario dans lequel deux équipements SRX Series font partie d’une configuration haute disponibilité multi nodale. Considérons SRX-1 comme nœud local et SRX-2 comme nœud distant. Le nœud local joue actuellement un rôle actif et héberge une adresse IP flottante pour diriger le trafic vers lui. Le routeur en amont a un chemin de priorité plus élevé pour le nœud local.

Lorsque l’ICL entre les nœuds tombe en panne, les deux nœuds lancent une sonde de détermination de l’activité (sonde ICMP). Les nœuds utilisent l’adresse IP flottante (détermination de l’activité, adresse IP) comme adresse IP source, et les adresses IP des routeurs en amont comme adresse IP de destination pour les sondes.

Cas 1 : Si le nœud actif est actif

Figure 12 : Le nœud actif est en place et ICL est en panne

• Le routeur en amont, qui héberge l’adresse IP de destination de la sonde, reçoit les sondes ICMP des deux nœuds.
• Le routeur en amont ne répond qu’au nœud actif ; car sa configuration a un chemin de préférence plus élevé pour le nœud actif
• Le nœud actif conserve le rôle actif.

Si le nœud actif est en panne :

Figure 13 : Le nœud actif est en panne et ICL est en panne

• Le nœud distant redémarre les sondes de détermination de l’activité.
• Le routeur hébergeant l’adresse IP de destination de la sonde a perdu son chemin de préférence le plus élevé (de l’ancien nœud actif) et répond au nœud distant.
• Le résultat de la sonde est un succès pour le nœud distant et le nœud distant passe à l’état actif.
• Comme démontré dans les cas ci-dessus, les sondes de détermination de l’activité et la configuration d’une préférence de chemin plus élevée dans le routeur en amont garantissent qu’un nœud reste toujours dans le rôle actif et empêchent le fractionnement du cerveau.

Split-Brain Sobing basé sur BFD

Dans Junos OS version 23.4R1, nous prenons en charge le sondage Split-Brain basé sur BFD pour la passerelle par défaut et le mode hybride des déploiements pour la haute disponibilité multi nodale.

La défaillance de la liaison interchâssis (ICL) peut souvent être attribuée à deux facteurs clés : des perturbations du réseau ou des configurations incohérentes. Vous pouvez utiliser une sonde d’activité pour déterminer le nœud qui peut jouer un rôle actif pour chaque SRG1+. En fonction du résultat de la sonde, l’un des nœuds passe à l’état actif et cette action empêche le scénario de déversement de cerveau.

Grâce au sondage Split-Brain basé sur BFD, vous pouvez désormais avoir un contrôle plus précis sur les sondes car vous pouvez définir l’interface, l’intervalle minimal et les multiplicateurs. Dans le sondage Split-Brain basé sur BFD, le sondage commence immédiatement après la configuration d’un SRG et commence à fonctionner. Dans le sondage Split-Brain basé sur ICMP par défaut, le sondage ne démarre qu’après l’interruption de la liaison ICL.

En comparaison, le sondage basé sur le BFD est beaucoup plus proactif de la manière suivante pour assurer une réponse plus rapide afin d’éviter les scénarios de cerveau divisé :

• Le sondage démarre directement après une configuration SRG.

• Si ICL BFD et la sonde Split-Brain se cassent en même temps, le nœud de secours assume immédiatement le rôle actif et prend en charge le VIP.

Cela garantit une réponse plus rapide pour éviter les scénarios de split-brain.

• Comment ça marche ?
• Différence entre les sondages ICMP et BFD

show chassis 
high-availability services-redundancy-group 1 
activeness-probe
dest-ip {
    192.168.21.1; 
    src-ip 192.168.21.2;
    }

show chassis 
high-availability services-redundancy-group 1 
activeness-probe
bfd-liveliness {
    source-ip 192.168.21.1; (inet address of the local SRX sub interface) 
    destination-ip 192.168.21.2; (inet address of the peers SRX sub interface) 
    interface xe-0/0/1.0;     
}

La figure suivante illustre les options de configuration pour le sondage basé sur ICMP et le sondage BFD pour la détection Split-Brain.

Figure 14 : Configuration des sondes d’activité pour les sondages basés sur ICMP et BFD

En mode hybride et dans les déploiements de passerelle par défaut, vous pouvez configurer l’intervalle et le seuil d’activité-sonde aux deux niveaux suivants :

• Niveau global, applicable aux sondages Split-Brain basés sur l’ICMP

• Niveau de vivacité BFD spécifique à la sonde BFD à cerveau divisé. Lorsque vous configurez le sondage basé sur BFD, ne configurez pas les options globales minimum-interval et multiplier sous l’instruction activeness-probe .

Pour configurer la sonde d’activité pour les déploiements de passerelle par défaut, utilisez l’interface d’adresse IP virtuelle principale (VIP1) sur les deux nœuds (local et pair) pour configurer votre sonde d’activité. L’adresse IP de destination provient du nœud homologue et l’adresse IP source provient de votre nœud local. Les deux VIP doivent avoir la même valeur d’index. Les adresses IP doivent être les adresses inet attribuées à l’interface LAN du pare-feu SRX Series.

Configurer le Split-Brain Probing

• Exemple de configuration
• Vérification

Figure 15 : configuration haute disponibilité multinodale pour le sondage Split-Brain

Considérons SRX-1 comme un nœud local et SRX-2 comme un nœud distant. Le nœud local joue actuellement un rôle actif et le routeur en amont dispose d’un chemin de priorité plus élevé pour le nœud local.

Pour activeness-probe, vous devez configurer les options suivantes :

• Adresse IP source : utilisez l’adresse IP virtuelle 1 (VIP1) de SRG1 du nœud local.

• Adresse IP de destination : Utilisez l’adresse VIP1 de SRG1 du nœud homologue.

• Interface : Interface associée à VIP1

Dans cet exemple, attribuez une adresse IP virtuelle (VIP) (192.168.21.1) et une interface xe-0/0/1.0 pour la vivacité du BFD. Ici, vous configurez le sondage Split-Brain basé sur BFD en spécifiant les adresses IP source et de destination ainsi que l’interface.

Les nœuds utilisent l’adresse inet de famille de l’interface associée à l’adresse IP virtuelle (VIP1) de SRG1.

Les deux nœuds lancent une sonde de détermination de l’activité (sonde basée sur BFD) dès que les SRG commencent à fonctionner.

Le tableau suivant montre comment la configuration haute disponibilité multinodale résout une situation de cerveau divisé avec un sondage basé sur BFD lorsque l’ICL est en panne. En fonction de l’état des nœuds et des résultats des sondes, le système de haute disponibilité multinœud sélectionne le nœud qui jouera le rôle actif.

Le Tableau 4 montre comment la configuration haute disponibilité multinodale résout les problèmes de cerveau partagé avec l’exploration basée sur BFD lorsque l’ICL est en panne. En fonction de l’état des nœuds et des résultats des sondes, le système de haute disponibilité multinœud sélectionne le nœud qui jouera le rôle actif.

Dans cet exemple, nous supposons que SRG1 du nœud 1 a la priorité d’activité la plus élevée.

• Utilisez la show chassis high-availability services-redundancy-group 1 commande pour voir le type de sonde split-brain configuré sur l’appareil.

  (Sondage basé sur BFD) (Sondage basé sur ICMP)

• Utilisez la commande pour voir si l’état de la sonde basée sur BFD show bfd session .

  Dans l’exemple, vous pouvez remarquer que le sondage Split-Brain basé sur BFD est en cours d’exécution pour l’interface xe-0/0/1.0.

• Utilisez la show chassis high-availability services-redundancy-group 1 commande pour obtenir les détails des sondes basées sur BFD.

Prise en charge des systèmes logiques et des systèmes de location

Les systèmes logiques des pare-feu SRX Series vous permettent de partitionner un seul périphérique en contextes sécurisés et Un système de locataire partitionne logiquement le pare-feu physique en pare-feu logique séparés et isolés.

Un système de locataire partitionne logiquement le pare-feu physique en pare-feu logiques distincts et isolés. Bien que similaires aux systèmes logiques, les systèmes de location présentent une évolutivité beaucoup plus élevée et moins de fonctionnalités de routage.

Pare-feu SRX Series en haute disponibilité multi nœuds Configurer les systèmes logiques et les systèmes de location sur les services Groupe de redondance 0 (SRG0).

Le comportement d’une configuration haute disponibilité multinodale avec des pare-feu SRX Series exécutant des systèmes logiques est le même que celui d’une configuration où les nœuds SRX Series n’exécutent pas de systèmes logiques. Il n’y a aucune différence dans les événements qui déclenchent un basculement de nœud. Plus précisément, si la surveillance de l’interface est activée sous SRG0 et qu’une liaison associée à un seul système logique tombe en panne (ce qui est en cours de surveillance), l’équipement bascule vers un autre nœud. Ce basculement s’effectue par le biais d’annonces de préférences de routage dans la configuration de haute disponibilité multi nodale.

Avant de configurer les systèmes logiques ou locataires, vous devez configurer la haute disponibilité multi nodale. Chaque nœud de la configuration haute disponibilité doit avoir une configuration identique. Assurez-vous que le nom, le profil et les fonctionnalités de sécurité correspondantes des systèmes logiques ou des systèmes locataires sont identiques. Toutes les configurations du système logique ou du système de location sont synchronisées et répliquées entre les deux nœuds.

Lorsque vous utilisez des pare-feu SRX Series avec des systèmes logiques dans une haute disponibilité multi nodale, vous devez acheter et installer le même nombre de licences pour chaque nœud de la configuration.

Pour plus d’informations, consultez Guide de l’utilisateur des systèmes logiques et des systèmes de location pour les appareils de sécurité.