Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Regrouper des clusters de serveurs VPNv2

Le cluster de serveurs VPNv2 de groupe fournit une redondance contrôleur de groupe/serveur de clés (GCKS), de sorte qu’il n’y a pas de point de défaillance unique pour l’ensemble du réseau VPN de groupe.

Comprendre les clusters de serveurs VPNv2 de groupe

Dans le protocole GDOI (Group Domain of Interpretation), le contrôleur de groupe/serveur de clés (GCKS) gère les associations de sécurité VPN de groupe, génère des clés de chiffrement et les distribue aux membres du groupe. Les membres du groupe chiffrent le trafic en fonction des SA de groupe et des clés fournies par le GCKS. En cas d’échec du GCKS, les membres du groupe ne peuvent pas s’inscrire ou obtenir des clés. Un cluster de serveurs VPNv2 de groupe fournit une redondance GCKS, de sorte qu’il n’y a pas de point de défaillance unique pour l’ensemble du réseau VPN du groupe. Les clusters de serveurs VPNv2 de groupe peuvent également assurer l’équilibrage de charge, la mise à l’échelle et la redondance des liens.

Group VPNv2 est pris en charge sur les équipements et instances de Pare-feu virtuel vSRX SRX300, SRX320, SRX340, SRX345, SRX550HM, SRX1500, SRX4100, SRX4200 et SRX4600. Tous les serveurs d’un cluster de serveurs VPNv2 de groupe doivent être pris en charge sur des pare-feu SRX Series ou des instances Pare-feu virtuel vSRX. Les clusters de serveurs VPNv2 de groupe sont une solution propriétaire de Juniper Networks et ne sont pas interopérables avec les GCKS d’autres fournisseurs.

Serveur racine et sous-serveurs

Un cluster de serveurs Group VPNv2 se compose d’un serveur racine avec jusqu’à quatre sous-serveurs connectés. Tous les serveurs du cluster partagent la même SA et les mêmes clés de chiffrement qui sont distribuées aux membres du groupe VPNv2. Les serveurs du cluster peuvent être situés sur différents sites, comme illustré à la .Figure 1

Figure 1 : Cluster de serveurs VPNv2 de groupeCluster de serveurs VPNv2 de groupe

Les messages échangés entre les serveurs du cluster sont chiffrés et authentifiés par les IKE SA. Le serveur racine est responsable de la génération et de la distribution des clés de chiffrement aux sous-serveurs ; En raison de cette responsabilité, nous recommandons que le serveur racine soit configuré en tant que cluster de châssis. Les sous-serveurs sont des équipements uniques et ne peuvent pas être des clusters de châssis. Les sous-serveurs doivent pouvoir se connecter au serveur racine, bien que les liens directs entre les sous-serveurs ne soient pas nécessaires.

Si un sous-serveur perd sa connexion au serveur racine, aucune autre connexion au sous-serveur de la part des membres du groupe n’est autorisée et les SA sont supprimées. Par conséquent, nous vous recommandons d’utiliser un lien différent pour connecter chaque sous-serveur au serveur racine.

Les clusters de serveurs VPNv2 de groupe sont configurés avec les server-cluster instructions au niveau de la hiérarchie [edit security group-vpn server group-name]. Les valeurs suivantes doivent être configurées pour chaque serveur d’un cluster :

  • Le rôle serveur : spécifiez ou root-serversub-server. Un serveur donné peut faire partie de plusieurs clusters de serveurs VPNv2 de groupe, mais il doit avoir le même rôle de serveur dans tous les clusters. Un serveur ne peut pas être configuré avec le rôle de serveur racine dans un groupe et le rôle de sous-serveur dans un autre groupe.

    Vous devez vous assurer qu’il n’y a qu’un seul serveur racine à la fois pour un cluster de serveurs VPNv2 de groupe.

  • Passerelle IKE : spécifiez le nom d’une passerelle IKE configurée au niveau de la hiérarchie [edit security group-vpn server ike]. Pour un serveur racine, la passerelle IKE doit être un sous-serveur dans le cluster ; Il est possible de spécifier jusqu’à quatre sous-serveurs. Pour les sous-serveurs, la passerelle IKE doit être le serveur racine.

    Le serveur racine et les sous-serveurs doivent être configurés avec dead-peer-detection always-send une adresse IP dynamique (non spécifiée) et ne peuvent pas l’être. Les membres du groupe ne sont pas configurés avec la détection des pairs morts.

La configuration du VPN v2 de groupe doit être la même sur chaque sous-serveur d’un groupe donné.

Chaque sous-serveur du cluster de serveurs VPNv2 de groupe fonctionne comme un GCKS normal pour l’inscription et la suppression de membres. Une fois l’inscription réussie d’un membre, le serveur d’inscription est responsable de l’envoi des mises à jour au membre. Pour un groupe donné, vous pouvez configurer le nombre maximal de membres VPNv2 de groupe qui peuvent être acceptés par chaque sous-serveur ; Ce nombre doit être le même sur tous les sous-serveurs du cluster. Un sous-serveur cesse de répondre aux demandes d’inscription des nouveaux membres lorsqu’il atteint le nombre maximal configuré de membres VPNv2 de groupe. Reportez-vous à la section Équilibrage de charge.

Inscription des membres du groupe auprès de clusters de serveurs

Les membres du groupe peuvent s’inscrire auprès de n’importe quel serveur du cluster de serveurs VPNv2 du groupe pour un groupe donné, mais nous recommandons aux membres de se connecter uniquement aux sous-serveurs et non au serveur racine. Il est possible de configurer jusqu’à quatre adresses de serveur sur chaque membre du groupe. Les adresses de serveur configurées sur les membres du groupe peuvent être différentes. Dans l’exemple ci-dessous, le membre du groupe A est configuré pour les sous-serveurs 1 à 4, tandis que le membre B est configuré pour les sous-serveurs 4 et 3 :

Membre du groupe A :

Membre du groupe B :

Adresses des serveurs :

Sous-serveur 1

Sous-serveur 2

Sous-serveur 3

Sous-serveur 4

Sous-serveur 4

Sous-serveur 3

L’ordre dans lequel les adresses du serveur sont configurées sur un membre est important. Un membre du groupe tente de s’inscrire auprès du premier serveur configuré. Si l’inscription auprès d’un serveur configuré échoue, le membre du groupe tente de s’inscrire auprès du serveur configuré suivant.

Chaque serveur d’un cluster de serveurs VPNv2 de groupe fonctionne comme un GCKS normal pour l’inscription et la suppression de membres. Une fois l’inscription réussie, le serveur d’inscription est responsable de l’envoi des mises à jour au membre via groupkey-push les échanges. Pour un groupe donné, vous pouvez configurer le nombre maximal de membres du groupe qui peuvent être acceptés par chaque serveur, mais ce nombre doit être le même sur tous les serveurs du cluster pour un groupe donné. Lorsque le nombre maximal de membres du groupe est atteint, un serveur cesse de répondre aux demandes d’inscription des nouveaux membres. Reportez-vous à la section Équilibrage de charge pour plus d’informations.

Détection des pairs morts

Pour vérifier la disponibilité des serveurs homologues dans un cluster de serveurs VPNv2 de groupe, chaque serveur du cluster doit être configuré pour envoyer des demandes DPD (dead peer detection), qu’il y ait ou non du trafic IPsec sortant vers l’homologue. Ceci est configuré avec l’instruction dead-peer-detection always-send au niveau de la hiérarchie [edit security group-vpn server ike gateway gateway-name].

Un serveur actif dans un cluster de serveurs VPNv2 de groupe envoie des sondes DPD à la ou aux passerelles IKE configurées dans le cluster de serveurs. DPD ne doit pas être configuré pour un groupe, car plusieurs groupes peuvent partager la même configuration de passerelle IKE de serveur homologue. Lorsque DPD détecte qu’un serveur est en panne, la SA IKE associée à ce serveur est supprimée. Tous les groupes marquent le serveur comme inactif et DPD sur le serveur est arrêté.

DPD ne doit pas être configuré pour la passerelle IKE sur les membres du groupe.

Lorsque DPD marque le serveur racine comme inactif, les sous-serveurs cessent de répondre aux demandes des nouveaux membres du groupe, mais les SA existantes pour les membres actuels du groupe restent actives. Un sous-serveur inactif n’envoie pas de suppressions aux membres du groupe, car les SA peuvent être toujours valides et les membres du groupe peuvent continuer à utiliser les SA existantes.

Si une SA IKE expire alors qu’un serveur homologue est encore actif, DPD déclenche la négociation IKE SA. Étant donné que les serveurs racine et les sous-serveurs peuvent déclencher des IKE SA via DPD, une négociation simultanée peut entraîner plusieurs IKE SA. Dans ce cas, aucun impact sur la fonctionnalité de cluster de serveurs n’est attendu.

Équilibrage de charge

L’équilibrage de charge dans le cluster de serveurs VPNv2 de groupe peut être réalisé en configurant la valeur appropriée member-threshold pour le groupe. Lorsque le nombre de membres enregistrés sur un serveur dépasse cette valeur, l’enregistrement member-threshold ultérieur des membres sur ce serveur est rejeté. L’enregistrement des membres bascule vers le serveur suivant configuré sur le membre du groupe jusqu’à ce qu’il atteigne un serveur qui member-threshold n’est pas encore atteint.

Il y a deux restrictions à la configuration de :member-threshold

  • Pour un groupe donné, la même member-threshold valeur doit être configurée sur le serveur racine et tous les sous-serveurs d’un cluster de serveurs de groupe. Si le nombre total de membres du groupe dépasse la valeur configurée member-threshold , l’enregistrement groupkey-pull initié par un nouveau membre est rejeté (le serveur n’envoie pas de réponse).

  • Un serveur peut prendre en charge les membres de plusieurs groupes. Chaque serveur dispose d’un nombre maximal de membres de groupe qu’il peut prendre en charge. Si un serveur atteint le nombre maximum de membres qu’il peut prendre en charge, une groupkey-pull inscription initiée par un nouveau membre est rejetée même si la member-threshold valeur d’un groupe spécifique n’a pas été atteinte.

Il n’y a pas de synchronisation des membres entre les serveurs du cluster. Le serveur racine ne dispose pas d’informations sur le nombre de membres enregistrés sur les sous-serveurs. Chaque sous-serveur ne peut afficher que ses propres membres enregistrés.

Comprendre les limitations des clusters de serveurs VPNv2 de groupe

Group VPNv2 est pris en charge sur les équipements et instances de Pare-feu virtuel vSRX SRX300, SRX320, SRX340, SRX345, SRX550HM, SRX1500, SRX4100, SRX4200 et SRX4600. Notez les mises en garde suivantes lors de la configuration de clusters de serveurs VPNv2 de groupe :

  • L’authentification par certificat n’est pas prise en charge pour l’authentification du serveur ; Seules les clés prépartagées peuvent être configurées.

  • Il n’y a pas de synchronisation de configuration entre les serveurs du cluster de serveurs Group VPNv2.

  • Lors de l’activation d’un cluster de serveurs VPN v2 de groupe, la configuration doit d’abord être effectuée sur le serveur racine, puis sur les sous-serveurs. Tant que la configuration n’est pas synchronisée manuellement entre les serveurs, on peut s’attendre à une perte de trafic lors de la modification de la configuration.

  • Dans certains cas particuliers, les SA sur les membres du groupe VPNv2 peuvent ne pas être synchronisées. Les membres d’un VPN de groupe peuvent synchroniser les SA en obtenant une nouvelle clé par le biais d’un groupkey-pull échange. Vous pouvez effacer manuellement les SA d’un membre du groupe VPNv2 à l’aide des commandes ou clear security group-vpn member group pour accélérer la clear security group-vpn member ipsec security-associations récupération.

  • Le cluster de serveurs Group VPNv2 ne prend pas en charge ISSU.

  • Si le dernier groupkey-pull message est perdu lors de l’inscription d’un membre VPNv2 de groupe, un serveur peut considérer le membre comme un membre enregistré, même s’il peut basculer vers le serveur suivant du cluster de serveurs. Dans ce cas, le même membre peut sembler être enregistré sur plusieurs serveurs. Si le nombre total de membres sur tous les serveurs est égal au nombre total de membres déployés, les membres suivants du groupe peuvent ne pas s’inscrire.

Notez les mises en garde suivantes concernant les opérations de cluster de châssis sur le serveur racine :

  • Aucune statistique n’est conservée.

  • Aucune donnée ou état de négociation n’est enregistré. Si un basculement de cluster de châssis de serveur racine se produit au cours d’une négociation ougroupkey-push, la négociation n’est groupkey-pull pas redémarrée après le basculement.

  • Si les deux nœuds du cluster de châssis d’un serveur racine tombent en panne lors d’une nouvelle clé de chiffrement, certains membres du groupe VPNv2 peuvent recevoir la nouvelle clé tandis que d’autres ne le reçoivent pas. Le trafic pourrait être affecté. L’effacement manuel des SA sur un membre VPN v2 de groupe à l’aide clear security group-vpn member ipsec security-associations des commandes ou clear security group-vpn member group peut aider à accélérer la récupération lorsque le serveur racine devient accessible.

  • Dans un environnement à grande échelle, le basculement RG0 sur le serveur racine peut prendre du temps. Si l’intervalle DPD et le seuil d’un sous-serveur sont configurés avec de petites valeurs, le sous-serveur peut marquer le serveur racine comme inactif lors d’un basculement RG0. Le trafic pourrait être affecté. Nous vous recommandons de configurer la passerelle IKE pour le sous-serveur avec une valeur DPD interval * threshold supérieure à 150 secondes.

Comprendre les messages du cluster de serveurs VPNv2 de groupe

Group VPNv2 est pris en charge sur les équipements et instances de Pare-feu virtuel vSRX SRX300, SRX320, SRX340, SRX345, SRX550HM, SRX1500, SRX4100, SRX4200 et SRX4600. Tous les messages entre les serveurs d’un cluster de serveurs Group VPNv2 sont chiffrés et authentifiés par une association de sécurité IKE (SA). Chaque sous-serveur initie une IKE SA avec le serveur racine ; cette SA IKE doit être établie avant que les messages puissent être échangés entre les serveurs.

Cette section décrit les messages échangés entre le serveur racine et les sous-serveurs.

Échanges de clusters

Figure 2 affiche les messages de base échangés entre le cluster de serveurs VPNv2 du groupe et les membres du groupe VPNv2.

Figure 2 : Messages du cluster de serveurs VPNv2 de groupeMessages du cluster de serveurs VPNv2 de groupe

Échanges cluster-initialisation

Un sous-serveur lance un échange d’initialisation de cluster (cluster-init) avec le serveur racine pour obtenir des informations sur la SA et la clé de chiffrement. Le serveur racine répond en envoyant des informations SA actuelles au sous-serveur par le biais de l’échange cluster-init .

Les sous-serveurs peuvent ensuite répondre aux demandes d’enregistrement des membres du groupe VPNv2 par le biais d’un groupkey-pull échange. L’échange groupkey-pull permet à un membre VPNv2 de groupe de demander des SA et des clés partagées par le groupe à partir d’un sous-serveur.

Les sous-serveurs démarrent un cluster-init échange avec le serveur racine lorsque :

  • Le serveur racine est considéré comme inactif. Il s’agit de l’état initial supposé du serveur racine. S’il n’y a pas de SA IKE entre le serveur racine et le sous-serveur, le sous-serveur initie une SA IKE avec le serveur racine. Après un échange réussi cluster-init , le sous-serveur obtient des informations sur les SA et marque le serveur racine comme actif.

  • La durée de vie souple du SA a expiré.

  • Un cluster-update message est reçu pour supprimer toutes les SA.

  • Des modifications ont été apportées à la configuration des groupes.

En cas d’échec de l’échange, le sous-serveur retente l’échange cluster-init avec le serveur racine toutes les 5 secondes.

Messages de mise à jour du cluster

Il groupkey-push s’agit d’un message de renouvellement de clé unique qui permet à un contrôleur/serveur de clés de groupe (GCKS) d’envoyer des SA et des clés de groupe aux membres avant l’expiration des SA de groupe existantes et de mettre à jour l’appartenance au groupe. Les messages de renouvellement de clé sont des messages non sollicités envoyés par le GCKS aux membres

Lors de la génération de nouvelles clés de chiffrement pour une SA, le serveur racine envoie les mises à jour de la SA à tous les sous-serveurs actifs par le biais d’un cluster-update message. Après réception d’un par le serveur racine, le sous-serveur installe la nouvelle SA et envoie les nouvelles informations SA par l’intermédiaire d’un cluster-updategroupkey-push à ses membres de groupe enregistrés.

Un cluster-update message envoyé à partir du serveur racine nécessite un accusé de réception de la part du sous-serveur. S’il n’y a pas d’accusé de réception reçu d’un sous-serveur, le serveur racine retransmet le cluster-update à la période de retransmission configurée (la valeur par défaut est de 10 secondes). Le serveur racine ne retransmet pas si la détection de l’homologue mort (DPD) indique que le sous-serveur n’est pas disponible. Si un sous-serveur ne parvient pas à mettre à jour les informations SA après avoir reçu un cluster-update, il n’envoie pas d’accusé de réception et le serveur racine retransmet le cluster-update message.

Si la durée de vie logicielle d’une SA expire avant qu’une nouvelle SA ne soit reçue du serveur racine, le sous-serveur envoie un cluster-init message au serveur racine pour obtenir toutes les SA et n’envoie pas de groupkey-push message à ses membres tant qu’il n’a pas une nouvelle mise à jour. Si la durée de vie matérielle d’une SA expire sur le sous-serveur avant qu’il ne reçoive une nouvelle SA, le sous-serveur marque le serveur racine comme inactif, supprime tous les membres du groupe enregistrés et continue d’envoyer cluster-init des messages au serveur racine.

Un cluster-update message peut être envoyé pour supprimer une SA ou un membre du groupe ; cela peut être le résultat d’une clear commande ou d’un changement de configuration. Si un sous-serveur reçoit un message lui demandant de supprimer une SA, il envoie un cluster-updategroupkey-push message de suppression aux membres de son groupe et supprime la SA correspondante. Si toutes les SA d’un groupe sont supprimées, le sous-serveur initie un cluster-init échange avec le serveur racine. Si tous les membres enregistrés sont supprimés, le sous-serveur supprime tous les membres enregistrés localement.

Comprendre les modifications de configuration avec les clusters de serveurs VPNv2 de groupe

Group VPNv2 est pris en charge sur les équipements et instances de Pare-feu virtuel vSRX SRX300, SRX320, SRX340, SRX345, SRX550HM, SRX1500, SRX4100, SRX4200 et SRX4600. Les clusters de serveurs VPNv2 de groupe se comportent différemment des serveurs VPNv2 de groupe autonomes lorsque des modifications de configuration entraînent de nouvelles clés de chiffrement et des modifications des associations de sécurité (SA). Le serveur racine envoie des mises à jour ou des suppressions de SA aux sous-serveurs par le biais cluster-update de messages. Les sous-serveurs envoient groupkey-push ensuite des messages aux membres. Les sous-serveurs ne peuvent pas envoyer de messages de suppression aux membres du groupe sans avoir d’abord reçu des messages de suppression du serveur racine.

Toutes les modifications de configuration doivent être effectuées d’abord sur le serveur racine, puis sur les sous-serveurs, pour s’assurer que les membres du groupe reçoivent les mises à jour ou les suppressions comme prévu. Tant que la configuration n’est pas synchronisée entre les serveurs du cluster de serveurs Group VPNv2, une perte de trafic peut être attendue.

Tableau 1 décrit les effets de diverses modifications de configuration sur les serveurs Group VPNv2.

Tableau 1 : Effets des modifications de configuration sur les serveurs VPNv2 de groupe

Modification de la configuration

Action de serveur VPNv2 de groupe autonome

Action de cluster de serveurs VPNv2 de groupe

Serveur racine

Sous-serveur

Modifier la proposition, la stratégie ou la passerelle IKE

Supprimez l’IKE SA de la passerelle concernée. Pour les suppressions de propositions, de stratégies ou de passerelles IKE, supprimez les membres enregistrés de la passerelle concernée.

Modification de la proposition IPsec

Les modifications prennent effet après la nouvelle clé de chiffrement du trafic (TEK).

Changements de groupe :

Supprimer le nom du groupe

Envoyez « tout supprimer » aux membres du groupe. Supprimez toutes les SA IKE du groupe. Supprimez immédiatement toutes les clés du groupe. Supprimez tous les membres inscrits dans le groupe.

Envoyez « supprimer tout » aux sous-serveurs. Supprimez immédiatement toutes les clés du groupe. Marquer tous les pairs comme inactifs. Supprimez les SA IKE de sous-serveur. Supprimez toutes les IKE SA membres.

Supprimez toutes les IKE SA membres. Supprimez immédiatement toutes les clés du groupe. Supprimez tous les membres inscrits dans le groupe. Marquer l’homologue comme inactif. Supprimez les SA IKE du serveur pair.

ID de modification

Envoyez « supprimer tout » à tous les membres. Supprimez toutes les SA IKE du groupe. Supprimez immédiatement toutes les clés du groupe. Supprimez tous les membres inscrits dans le groupe. Générez de nouvelles clés en fonction de la configuration.

Envoyez « supprimer tout » aux sous-serveurs. Supprimez toutes les SA IKE membres du groupe. Supprimez immédiatement toutes les clés du groupe. Marquer tous les pairs comme inactifs. Supprimez toutes les SA IKE du serveur pair. Générez de nouvelles clés en fonction de la configuration.

Supprimez toutes les SA IKE membres du groupe. Supprimez immédiatement toutes les clés du groupe. Supprimez tous les membres inscrits dans le groupe. Marquer l’homologue comme inactif. Supprimez les SA IKE du serveur pair. Initier un nouvel cluster-init échange.

Ajouter ou supprimer une passerelle IKE

Aucun changement pour les ajouts. Pour les suppressions, supprimez l’IKE SA et les membres enregistrés pour la passerelle concernée.

Ajouter ou modifier la fenêtre temporelle de l’anti-relecture

La nouvelle valeur prend effet après la nouvelle clé TEK.

Ajouter ou modifier l’absence d’anti-rejeu

La nouvelle valeur prend effet après la nouvelle clé TEK.

Modifications apportées à la communication entre les membres du serveur :

Ajouter

Supprimez tous les membres inscrits. Générer clé de chiffrement (KEK) SA.

Générez KEK SA. Envoyez la nouvelle SA KEK au sous-serveur. Supprimez toutes les IKE SA membres.

Supprimez tous les membres inscrits.

Changement

La nouvelle valeur prend effet après la nouvelle clé KEK.

Supprimer

Envoyer supprimer pour supprimer toutes les SA KEK. Supprimer KEK SA.

Envoyer la suppression aux sous-serveurs. Supprimer KEK SA. Supprimez toutes les IKE SA membres.

Supprimer KEK SA.

SA IPsec :

Ajouter

Générer une nouvelle SA TEK. Mettre à jour la nouvelle SA TEK sur les membres.

Générer une nouvelle SA TEK. Envoyez de nouveaux TEK SA aux sous-serveurs.

Pas d’action.

Changement

La nouvelle valeur prend effet après la recléation TEK.

Si la stratégie de correspondance change, le TEK actuel est immédiatement supprimé et delete groupkey-push est envoyé, car les membres doivent être explicitement avertis que cette configuration est supprimée.

Si la stratégie de correspondance change, envoyez la suppression aux sous-serveurs. Supprimez TEK immédiatement.

Si la politique de correspondance change, supprimez immédiatement TEK.

Supprimer

Supprimez TEK immédiatement. Envoyer delete pour supprimer cette SA TEK.

Envoyer la suppression aux sous-serveurs. Supprimez TEK immédiatement.

Supprimez TEK immédiatement.

Tableau 2 décrit les effets de la modification de la configuration du cluster de serveurs VPNv2 de groupe.

Vous devez vous assurer qu’il n’y a qu’un seul serveur racine dans un cluster de serveurs à tout moment.

Tableau 2 : Effets des modifications apportées à la configuration du cluster de serveurs VPNv2 de groupe

Modification de la configuration du cluster de serveurs

Cluster de serveurs VPNv2 de groupe

Serveur racine

Sous-serveur

Proposition, stratégie ou passerelle IKE (pair de cluster)

Pour les ajouts, il n’y a pas de changement. Pour les modifications ou les suppressions, supprimez l’IKE SA de l’homologue concerné.

Cluster de serveurs :

Ajouter

Aucun.

Envoyez « tout supprimer » aux membres du groupe. Supprimez toutes les SA IKE membres du groupe. Supprimez immédiatement tous les TEK et KEK du groupe. Supprimez tous les membres inscrits dans le groupe. Envoyer cluster-init au serveur racine.

Changer de rôle

Vous devez vous assurer qu’il n’y a qu’un seul serveur racine dans un cluster de serveurs à tout moment.

Envoyez « supprimer tout » aux sous-serveurs. Supprimez toutes les SA IKE membres du groupe. Supprimez immédiatement tous les TEK et KEK du groupe. Marquer tous les pairs comme inactifs. Supprimez toutes les SA IKE du serveur pair. Envoyer cluster-init au serveur racine.

Rekey TEK. Redéfinir la clé KEK. Envoyez de nouvelles clés aux sous-serveurs. Envoyez de nouvelles clés aux membres.

Ajouter un pair

Aucun.

Supprimer l’homologue

Marquer l’homologue comme inactif. Effacer l’homologue IKE SA.

Marquer l’homologue comme inactif. Effacer KEK. Effacer TEK. Effacer l’homologue IKE SA.

Modifier la période de retransmission

Aucun.

Supprimer un cluster de serveurs

Envoyez « supprimer tout » aux sous-serveurs. Supprimez immédiatement tous les TEK et KEK du groupe. Marquer tous les pairs comme inactifs. Supprimez toutes les SA IKE du serveur pair. Générez de nouveaux TEK et KEK en fonction de la configuration.

Supprimez toutes les SA IKE membres du groupe. Supprimez immédiatement tous les TEK et KEK du groupe. Supprimez tous les membres inscrits dans le groupe. Marquer l’homologue comme inactif. Supprimez les SA IKE du serveur pair. Générez de nouveaux TEK et KEK en fonction de la configuration.

Migration d’un serveur VPNv2 de groupe autonome vers un cluster de serveurs VPNv2 de groupe

Group VPNv2 est pris en charge sur les pare-feu et les instances de Pare-feu virtuel vSRX SRX300, SRX320, SRX340, SRX345, SRX550HM, SRX1500, SRX4100, SRX4200 et SRX4600 Series. Cette section décrit comment migrer un serveur VPN v2 de groupe autonome vers un cluster de serveurs VPNv2 de groupe.

Pour migrer un serveur VPN VPNv2 de groupe autonome vers un serveur racine :

Nous vous recommandons vivement d’utiliser le serveur racine sous châssis.

  1. Mettez à niveau le serveur Group VPNv2 autonome vers un cluster de châssis. Pour plus d’informations, reportez-vous au Guide de l’utilisateur du cluster de châssis pour les équipements SRX Series

    Un redémarrage est nécessaire lors de la mise à niveau d’un pare-feu SRX Series autonome vers un nud de cluster de châssis. Des pertes de trafic sont à prévoir.

  2. Sur le cluster de châssis, ajoutez la configuration du serveur racine du cluster de serveurs Group VPNv2. Le rôle serveur configuré pour le cluster doit être root-server.

    Il ne doit pas y avoir de perte de trafic parmi les membres du groupe existants lors de la modification de la configuration.

Pour ajouter un sous-serveur au cluster de serveurs VPNv2 de groupe :

  1. Sur le serveur racine, configurez à la fois une passerelle IKE pour le serveur Group VPNv2 et une passerelle IKE pour le sous-serveur. Les SA et le trafic des membres existants ne devraient pas être affectés.

  2. Sur le sous-serveur, configurez le cluster de serveurs. N’oubliez pas que la configuration du groupe VPNv2 doit être la même sur chaque serveur du cluster, à l’exception des passerelles IKE du serveur VPNv2 du groupe, du rôle serveur dans le cluster et des configurations de passerelle IKE du cluster de serveurs. Sur le sous-serveur, le rôle de serveur configuré dans le cluster doit être sub-server. Configurez une passerelle IKE de serveur VPNv2 de groupe et une passerelle IKE de cluster de serveurs pour le serveur racine.

Pour supprimer un sous-serveur du cluster de serveurs Group VPNv2 :

  1. Sur le serveur racine, supprimez à la fois les configurations de la passerelle IKE du serveur Group VPNv2 et de la passerelle IKE du cluster de serveurs pour le sous-serveur. Les SA et le trafic des membres existants ne devraient pas être affectés.

  2. Mettez le sous-serveur hors tension.

Exemple : Configuration d’un groupe, d’un cluster de serveurs VPNv2 et de ses membres

Cet exemple montre comment configurer un cluster de serveurs VPNv2 de groupe pour fournir un contrôleur de groupe/serveur de clés (GCKS) et une mise à l’échelle aux membres du groupe VPNv2. Group VPNv2 est pris en charge sur les équipements et instances de Pare-feu virtuel vSRX SRX300, SRX320, SRX340, SRX345, SRX550HM, SRX1500, SRX4100, SRX4200 et SRX4600.

Conditions préalables

L’exemple utilise les composants matériels et logiciels suivants :

  • Huit instances de pare-feu SRX Series ou de pare-feu virtuel vSRX prises en charge exécutant Junos OS version 15.1X49-D30 ou ultérieure qui prennent en charge Group VPNv2 :

    • Deux équipements ou instances sont configurés pour fonctionner comme un cluster de châssis. Le cluster de châssis fonctionne en tant que serveur racine dans le cluster de serveurs VPNv2 du groupe. Les équipements ou instances doivent avoir la même version logicielle et les mêmes licences.

      Le serveur racine est responsable de la génération et de la distribution des clés de chiffrement aux sous-serveurs du cluster de serveurs VPN du groupe ; En raison de cette responsabilité, nous recommandons que le serveur racine soit un cluster châssis.

    • Quatre autres appareils ou instances fonctionnent en tant que sous-serveurs dans le cluster de serveurs VPNv2 de groupe.

    • Deux autres appareils ou instances fonctionnent en tant que membres du groupe VPNv2.

  • Deux équipements MX Series pris en charge exécutant Junos OS version 15.1R2 ou ultérieure qui prennent en charge Group VPNv2. Ces appareils fonctionnent en tant que membres d’un groupe VPNv2.

Un nom d’hôte, un mot de passe administrateur racine et un accès de gestion doivent être configurés sur chaque instance de pare-feu SRX Series ou de pare-feu virtuel vSRX. Nous vous recommandons également de configurer NTP sur chaque équipement.

Les configurations de cet exemple se concentrent sur ce qui est nécessaire pour le fonctionnement de groupe VPNv2, en fonction de la topologie illustrée à Figure 3. Certaines configurations, telles que les configurations d’interface, de routage ou de cluster de châssis, ne sont pas incluses ici. Par exemple, le fonctionnement de Group VPNv2 nécessite une topologie de routage fonctionnelle qui permet aux appareils clients d’atteindre les sites prévus sur le réseau. Cet exemple ne couvre pas la configuration du routage statique ou dynamique.

Présentation

Dans cet exemple, le réseau VPNv2 de groupe se compose d’un cluster de serveurs et de quatre membres. Le cluster de serveurs se compose d’un serveur racine et de quatre sous-serveurs. Deux des membres sont des pare-feu SRX Series ou des instances de pare-feu virtuel vSRX, tandis que les deux autres membres sont des équipements MX Series.

Les SA VPN de groupe doivent être protégées par une SA de phase 1. Par conséquent, la configuration VPN de groupe doit inclure la configuration des négociations IKE Phase 1 sur le serveur racine, les sous-serveurs et les membres du groupe. Les configurations IKE sont décrites comme suit.

Sur le serveur racine :

  • La stratégie SubSrv IKE est utilisée pour établir des SA de phase 1 avec chaque sous-serveur.

  • Une passerelle IKE est configurée avec la détection d’homologue mort (DPD) pour chaque sous-serveur.

  • Le rôle de cluster de serveurs est et chaque sous-serveur est root-server configuré en tant que passerelle IKE pour le cluster de serveurs.

Le serveur racine doit être configuré pour prendre en charge le fonctionnement du cluster de châssis. Dans l’exemple, des interfaces Ethernet redondantes sur le serveur racine se connectent à chacun des sous-serveurs du cluster de serveurs ; L’ensemble de la configuration du cluster de châssis n’est pas affiché.

Sur chaque sous-serveur :

  • Deux stratégies IKE sont configurées : RootSrv est utilisé pour établir une SA de phase 1 avec le serveur racine et GMs est utilisé pour établir des SA de phase 1 avec chaque membre du groupe.

    Les clés prépartagées sont utilisées pour sécuriser les SA de phase 1 entre le serveur racine et les sous-serveurs, ainsi qu’entre les sous-serveurs et les membres du groupe. Assurez-vous que les clés prépartagées utilisées sont des clés fortes. Sur les sous-serveurs, la clé prépartagée configurée pour la stratégie IKE doit correspondre à la clé prépartagée configurée sur le serveur racine, et la clé prépartagée configurée pour la stratégie RootSrvGMs IKE doit correspondre à la clé prépartagée configurée sur les membres du groupe.

  • Une passerelle IKE est configurée avec DPD pour le serveur racine. De plus, une passerelle IKE est configurée pour chaque membre du groupe.

  • Le rôle de cluster de serveurs est et le serveur racine est sub-server configuré en tant que passerelle IKE pour le cluster de serveurs.

Sur chaque membre du groupe :

  • La stratégie SubSrv IKE est utilisée pour établir des SA de phase 1 avec les sous-serveurs.

  • La configuration de la passerelle IKE inclut les adresses des sous-serveurs.

Sur les pare-feu SRX Series ou les membres du groupe de pare-feu virtuel vSRX, une stratégie IPsec est configurée pour le groupe dont la zone LAN est la zone de départ (trafic entrant) et la zone WAN la zone de destination (trafic sortant). Une stratégie de sécurité est également nécessaire pour autoriser le trafic entre les zones LAN et WAN.

Le même identificateur de groupe doit être configuré à la fois sur le serveur du groupe et sur les membres du groupe. Dans cet exemple, le nom du groupe est GROUP_ID-0001 et l’identificateur de groupe est 1. La stratégie de groupe configurée sur le serveur spécifie que la SA et la clé sont appliquées au trafic entre les sous-réseaux dans la plage 172.16.0.0/12.

Topologie

Figure 3 affiche les équipements Juniper Networks à configurer pour cet exemple.

Figure 3 : Cluster de serveurs VPNv2 en groupe avec des membres SRX Series ou pare-feu virtuel vSRX et MX SeriesCluster de serveurs VPNv2 en groupe avec des membres SRX Series ou pare-feu virtuel vSRX et MX Series

Configuration

Configuration du serveur racine

Configuration rapide de l’interface de ligne de commande

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à la configuration de votre réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit en mode de configuration.

Procédure étape par étape

L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur la façon de procéder, consultez Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur CLI.

Pour configurer le serveur racine :

  1. Configurez les zones de sécurité et les stratégies de sécurité.

  2. Configurez le cluster de châssis.

  3. Configurez la proposition, la stratégie et la passerelle IKE.

  4. Configurez la SA IPsec.

  5. Configurez le groupe VPN.

  6. Configurez la stratégie de groupe.

Résultats

À partir du mode de configuration, confirmez votre configuration en saisissant les commandes show interfaces, show chassis clusteret show security . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.

Configuration du sous-serveur 1

Configuration rapide de l’interface de ligne de commande

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à la configuration de votre réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit en mode de configuration.

Procédure étape par étape

L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur la façon de procéder, consultez Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur CLI.

Pour configurer le sous-serveur dans le cluster de serveurs VPNv2 de groupe :

  1. Configurez les interfaces, les zones de sécurité et les stratégies de sécurité.

  2. Configurez la proposition, la stratégie et la passerelle IKE.

  3. Configurez la SA IPsec.

  4. Configurez le groupe VPN.

  5. Configurez la stratégie de groupe.

Résultats

À partir du mode de configuration, confirmez votre configuration en entrant les show interfacescommandes et show security . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.

Configuration du sous-serveur 2

Configuration rapide de l’interface de ligne de commande

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à la configuration de votre réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit en mode de configuration.

Procédure étape par étape

L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur la façon de procéder, consultez Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur CLI.

Pour configurer le sous-serveur dans le cluster de serveurs VPNv2 de groupe :

  1. Configurez les interfaces, les zones de sécurité et les stratégies de sécurité.

  2. Configurez la proposition, la stratégie et la passerelle IKE.

  3. Configurez la SA IPsec.

  4. Configurez le groupe VPN.

  5. Configurez la stratégie de groupe.

Résultats

À partir du mode de configuration, confirmez votre configuration en entrant les commandes show interfaces et show security . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.

Configuration du sous-serveur 3

Configuration rapide de l’interface de ligne de commande

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à la configuration de votre réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit en mode de configuration.

Procédure étape par étape

L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur la façon de procéder, consultez Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur CLI.

Pour configurer le sous-serveur dans le cluster de serveurs VPNv2 de groupe :

  1. Configurez les interfaces, les zones de sécurité et les stratégies de sécurité.

  2. Configurez la proposition, la stratégie et la passerelle IKE.

  3. Configurez la SA IPsec.

  4. Configurez le groupe VPN.

  5. Configurez la stratégie de groupe.

Résultats

À partir du mode de configuration, confirmez votre configuration en entrant les commandes show interfaces et show security . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.

Configuration du sous-serveur 4

Configuration rapide de l’interface de ligne de commande

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à la configuration de votre réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit en mode de configuration.

Procédure étape par étape

L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur la façon de procéder, consultez Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur CLI.

Pour configurer le sous-serveur dans le cluster de serveurs VPNv2 de groupe :

  1. Configurez les interfaces, les zones de sécurité et les stratégies de sécurité.

  2. Configurez la proposition, la stratégie et la passerelle IKE.

  3. Configurez la SA IPsec.

  4. Configurez le groupe VPN.

  5. Configurez la stratégie de groupe.

Résultats

À partir du mode de configuration, confirmez votre configuration en entrant les commandes show interfaces et show security . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.

Configuration de GM-0001 (pare-feu SRX Series ou instance de pare-feu virtuel vSRX)

Configuration rapide de l’interface de ligne de commande

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à la configuration de votre réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit en mode de configuration.

Procédure étape par étape

L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur la façon de procéder, consultez Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur CLI.

Pour configurer le membre VPNv2 de groupe :

  1. Configurez les interfaces, les zones de sécurité et les stratégies de sécurité.

  2. Configurez la proposition, la stratégie et la passerelle IKE.

  3. Configurez la SA IPsec.

  4. Configurez la stratégie IPsec.

Résultats

À partir du mode de configuration, confirmez votre configuration en entrant les commandes show interfaces et show security . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.

Configuration de GM-0002 (pare-feu SRX Series ou instance Pare-feu virtuel vSRX)

Configuration rapide de l’interface de ligne de commande

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à la configuration de votre réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit en mode de configuration.

Procédure étape par étape

L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur la façon de procéder, consultez Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur CLI.

Pour configurer le membre VPNv2 de groupe :

  1. Configurez les interfaces, les zones de sécurité et les stratégies de sécurité.

  2. Configurez la proposition, la stratégie et la passerelle IKE.

  3. Configurez la SA IPsec.

  4. Configurez la stratégie IPsec.

Résultats

À partir du mode de configuration, confirmez votre configuration en entrant les commandes show interfaces et show security . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.

Configuration de GM-0003 (équipement MX Series)

Configuration rapide de l’interface de ligne de commande

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à la configuration de votre réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit en mode de configuration.

Procédure étape par étape

L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur la façon de procéder, consultez Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur CLI.

Pour configurer le membre VPNv2 de groupe :

  1. Configurez les interfaces.

  2. Configurez la proposition, la stratégie et la passerelle IKE.

  3. Configurez la SA IPsec.

  4. Configurez le filtre de service.

  5. Configurez l’ensemble de services.

Résultats

À partir du mode de configuration, confirmez votre configuration en saisissant les commandes show interfaces, show security, show serviceset show firewall. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.

Configuration de GM-0004 (équipement MX Series)

Configuration rapide de l’interface de ligne de commande

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à la configuration de votre réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit en mode de configuration.

Procédure étape par étape

L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur la façon de procéder, consultez Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur CLI.

Pour configurer le membre VPNv2 de groupe :

  1. Configurez les interfaces.

  2. Configurez la proposition, la stratégie et la passerelle IKE.

  3. Configurez la SA IPsec.

  4. Configurez le filtre de service.

  5. Configurez l’ensemble de services.

Résultats

À partir du mode de configuration, confirmez votre configuration en saisissant les commandes show interfaces, show security, show serviceset show firewall. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.

Vérification

Vérifiez que la configuration fonctionne correctement.

Vérification du fonctionnement du cluster de serveurs

But

Vérifiez que les périphériques du cluster de serveurs reconnaissent les serveurs homologues du groupe. Assurez-vous que les serveurs sont actifs et que les rôles du cluster sont correctement attribués.

Action

En mode opérationnel, entrez les show security group-vpn server server-clustercommandes , show security group-vpn server server-cluster detail, et show security group-vpn server statistics sur le serveur racine.

À partir du mode opérationnel, entrez les show security group-vpn server server-clustercommandes , show security group-vpn server server-cluster detail, et show security group-vpn server statistics sur chaque sous-serveur.

Vérification de la distribution des SA aux membres

But

Vérifiez que les sous-serveurs ont reçu les SA pour les distribuer aux membres du groupe et que les membres du groupe ont reçu les SA appropriées.

Action

À partir du mode opérationnel, entrez les commandes et show security group-vpn server kek security-associationsshow security group-vpn server kek security-associations detail sur le serveur racine.

À partir du mode opérationnel, entrez les show security group-vpn server kek security-associations commandes et show security group-vpn server kek security-associations detail sur chaque sous-serveur.

À partir du mode opérationnel, entrez les commandes et show security group-vpn member kek security-associationsshow security group-vpn member kek security-associations detail sur chaque membre du groupe.

Pour les membres du groupe Pare-feu SRX Series ou pare-feu virtuel vSRX :

Pour les membres du groupe MX :

Vérification des IKE SA sur les serveurs

But

Affichez les associations de sécurité IKE (SA) sur les serveurs.

Action

À partir du mode opérationnel, entrez les commandes et show security group-vpn server ike security-associationsshow security group-vpn server ike security-associations detail sur le serveur racine.

À partir du mode opérationnel, entrez les show security group-vpn server ike security-associations commandes et show security group-vpn server ike security-associations detail sur chaque sous-serveur.

Vérification des SA IPsec sur les serveurs et les membres du groupe

But

Affichez les associations de sécurité IPsec sur les serveurs et les membres du groupe.

Action

À partir du mode opérationnel, entrez les commandes et show security group-vpn server ipsec security-associationsshow security group-vpn server ipsec security-associations detail sur le serveur racine.

À partir du mode opérationnel, entrez les show security group-vpn server ipsec security-associations commandes et show security group-vpn server ipsec security-associations detail sur chaque sous-serveur.

À partir du mode opérationnel, entrez les show security group-vpn member ipsec security-associations commandes et show security group-vpn member ipsec security-associations detail sur chaque membre du groupe

Pour les membres du groupe Pare-feu SRX Series ou pare-feu virtuel vSRX :

Pour les membres du groupe MX :

Vérification des stratégies IPsec sur les membres d’un groupe

But

Affichez la stratégie IPsec sur un pare-feu SRX Series ou un membre du groupe pare-feu virtuel vSRX.

Cette commande n’est pas disponible pour les membres du groupe MX Series.

Action

En mode opérationnel, entrez la commande sur les membres du show security group-vpn member policy groupe Pare-feu SRX Series ou pare-feu virtuel vSRX.