Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Vpn de groupe VPNv1

Le VPN de groupe est un ensemble de fonctionnalités nécessaires pour sécuriser le trafic de groupe multicast IP ou le trafic unicast sur un WAN privé d’origine ou de flux via un équipement.

Présentation de la VPNNv1 de groupe

Une association de sécurité IPsec (SA) est un accord unidirectionnel entre les participants du réseau privé virtuel (VPN) qui définit les règles à utiliser pour les algorithmes d’authentification et de chiffrement, les mécanismes d’échange clés et les communications sécurisées. Avec les implémentations VPN actuelles, le SA est un tunnel point à point entre deux équipements de sécurité. La vpnv1 de groupe étend l’architecture IPsec pour prendre en charge les SA partagés par un groupe d’équipements de sécurité Figure 1 (voir).

Figure 1 : VPN IPsec standard et VPN de groupe VPNv1VPN IPsec standard et VPN de groupe VPNv1

La VPNNv1 de groupe est prise en charge sur SRX100, SRX110, SRX210, SRX220, SRX240 et SRX650 périphériques. Avec la technologie VPNv1 de groupe, il est connectivité any-to-any en préservant les adresses IP source et de destination d’origine dans l’en-tête extérieur. Les paquets multicast sécurisés sont répliqués de la même manière que les paquets multicast cleartext dans le réseau central.

Depuis le Junos OS version 12.3X48-D30, les membres du groupe VPNv1 peuvent interopérabilité avec les serveurs VPNv2 de groupe.

La VPNNv1 de groupe présente des limites de propriété relatives au RFC 6407, The Group Domain of Interpretation (GDOI). Pour utiliser un VPN de groupe sans limitations propriétaires, mise à niveau vers VPNv2 de groupe. La vpnv2 de groupe est prise en charge sur les instances vSRX à partir de Junos OS Release 15.1X49-D30, les équipements SRX Series commençant par Junos OS Release 15.1X49-D40 et les équipements MX Series à partir de Junos OS Version 15.1r2.

Understanding the GDOI Protocol for Group VPNv1

La technologie VPNv1 de groupe est basée sur le RFC 3547, The Group Domain of Interpretation (GDOI). Ce RFC décrit le protocole entre les membres du groupe et un serveur de groupe pour établir des SA parmi les membres du groupe. Les messages GDOI créent, entretiennent ou suppriment les SA pour un groupe d’équipements. Le protocole GDOI s’exécute sur le port 848.

L’Association internet de sécurité et le protocole ISAKMP (Key Management Protocol) définissent deux phases de négociation pour établir des SA pour un tunnel IKE IPsec. La phase 1 permet à deux équipements d’établir un SA ISAKMP. La phase 2 établit des SA pour d’autres protocoles de sécurité, tels que GDOI.

Avec le VPN de groupe, la négociation ISAKMP SA de phase 1 est effectuée entre un serveur de groupe et un membre du groupe. Le serveur et le membre doivent utiliser la même stratégie ISAKMP. Lors de la phase 2, les échanges GDOI entre le serveur et le membre établissent des SA partagés avec les autres membres du groupe. Un membre du groupe n’a pas besoin de négocier l’IPsec avec les autres membres du groupe. Les échanges GDOI de phase 2 doivent être protégés par les SA de phase 1 ISAKMP.

Il existe deux types d’échanges GDOI:

  • groupkey-pullL’échange permet à un membre de demander des SA et des clés partagées par le groupe sur le serveur.

  • Il s’agit d’un message unique rekey qui permet au serveur d’envoyer des SA de groupe et des clés aux membres avant l’expiration des groupkey-push SA du groupe existant. Les messages clés en main sont des messages non sollicités envoyés par le serveur aux membres.

Comprendre les limites de la VPNNv1 de groupe

Les déclarations suivantes ne sont pas prise en charge dans la version VPNv1 du groupe:

  • Instances de routage non par défaut

  • Cluster de châssis

  • Clusters de serveurs

  • VPN de groupe basé sur le route

  • Déploiement basé sur l’Internet public

  • SNMP

  • Refus de la politique de Cisco GET VPN server

  • Interface J-Web pour la configuration et la surveillance

Depuis Junos OS Version 12.3X48-D30, les membres du groupe VPNv1 sur les équipements SRX100, SRX110, SRX210, SRX220, SRX240, SRX550 et SRX650 peuvent interopérabilité avec les serveurs VPNv2 de groupe. Lorsque vous configurez des membres VPNv1 de groupe pour les utiliser avec les serveurs VPNv2 de groupe, notez les limites suivantes:

  • La technologie VPNv2 de groupe prend en charge le IETF de spécification PRÉLIMINAIRE IP Delivery Delay Detection Protocol pour un mécanisme antireplay basé sur l’heure. Par conséquent, l’antireplay basé sur le protocole de détection de délai de livraison IP n’est pas pris en charge sur les membres du groupe VPNv1 et doit être désactivé sur le serveur VPNv2 de groupe à l’aide de la deactivate security group-vpn server group group-name anti-replay-time-window commande.

  • Le serveur VPNv2 de groupe ne prend pas en charge la colocation, car les fonctions du serveur de groupe et des membres du groupe existent dans le même équipement.

  • Le serveur VPNv2 de groupe ne prend pas en charge les transmissions de pulsations. La commande doit être désactivée par le membre VPNNv1 du deactivate security group-vpn member ipsec vpn vpn-name heartbeat-threshold groupe. Nous recommandons l’utilisation de clusters de serveurs VPNv2 de groupe pour éviter tout impact sur le trafic en raison de redémarrages ou d’autres interruptions sur le serveur VPNv2 de groupe.

  • Les messages groupkey-push envoyés par le serveur VPNv2 de groupe sont basés sur le RFC 6407( The Group Domain of Interpretation, GDOI) et ne sont pas pris en charge par les membres du groupe VPNv1. Par conséquent, les messages groupés clés en main doivent être désactivés sur le serveur VPNv2 de groupe avec la deactivate security group-vpn server group group-name server-member-communication commande.

    Les clés en main sont prise en charge par des messages groupés et retirés. Si les membres du groupe VPNv1 ne peuvent pas terminer l’opération de regroupement clé en main avant l’expiration de la durée de vie dure du TEK, nous recommandons d’augmenter la durée de vie du TEK afin de laisser suffisamment de temps aux membres pour effectuer l’opération de regroupement clé en main. Juniper chiffres de l’entreprise sont qualifiés avec une durée de vie de TEK de 2 heures.

  • Si le serveur VPNv2 de groupe est redémarrage ou mis à niveau, ou que les SA du groupe sont autorisé, de nouveaux membres ne peuvent pas être ajoutés au réseau jusqu’à ce que le prochain re-key se produise pour les membres existants. Les nouveaux membres ne peuvent pas envoyer de trafic à des membres existants inglés avec d’anciennes clés. Pour une solution de contournement, effacer les SA sur les membres VPNv1 de groupe existants avec la clear security group-vpn member ipsec security-associations commande.

  • Le trafic de données multicast n’étant pas pris en charge par les membres du groupe VPNv2, le trafic de données multicast ne peut pas être utilisé lorsque les membres VPNv1 et VPNv2 du groupe coexistent sur le réseau pour le même groupe.

Understanding Group VPNv1 Servers and Members

Le serveur de groupe est au centre d’un VPN de groupe. Le serveur de groupe réalise les tâches suivantes:

  • Contrôle l’appartenance aux groupes

  • Génère des clés de chiffrement

  • Gère les SA de groupe et les clés, puis les distribue aux membres du groupe

Les membres du groupe chiffrent le trafic en fonction des SA du groupe et des clés fournies par le serveur de groupe.

Un serveur de groupe peut servir plusieurs groupes. Un seul équipement de sécurité peut être membre de plusieurs groupes.

Chaque groupe est représenté par un identifiant de groupe, qui est un numéro entre 1 et 65 535. Le serveur du groupe et les membres du groupe sont liés par l’identifiant du groupe. Il ne peut y avoir qu’un seul identifiant par groupe et plusieurs groupes ne peuvent pas utiliser le même identifiant de groupe.

Voici une vue de haut niveau du serveur VPN de groupe et des actions des membres:

  1. Le serveur de groupe écoute le port UDP 848 pour que les membres s’enregistrent. Un équipement membre doit fournir une authentification IKE phase 1 correcte pour rejoindre le groupe. L’authentification clé partagée par membre est prise en charge.

  2. Une fois l’authentification et l’enregistrement réussis, l’équipement membre récupère des SA de groupe et des clés du serveur avec un échange groupkey-pull GDOI.

  3. Le serveur ajoute un membre au groupe.

  4. Les membres du groupe échangent des paquets chiffrés avec des clés SA de groupe.

Le serveur envoie périodiquement des messages sa et des actualisations de clés à des membres avec des messages GDOI groupkey-push (rekey). Les messages re-clés sont envoyés avant l’expiration des SA ; cela garantit que les clés valides sont disponibles pour le chiffrement du trafic entre les membres du groupe.

Le serveur envoie également des messages re-clés pour fournir de nouvelles clés aux membres en cas de modification de l’appartenance au groupe ou lorsque le groupe SA a changé.

Understanding Group VPNv1 Server-Member Communication

La VPNNv1 de groupe est prise en charge sur SRX100, SRX110, SRX210, SRX220, SRX240 et SRX650 périphériques. La communication entre les serveurs permet au serveur d’envoyer des messages GDOI groupkey-push aux membres. Si la communication entre les membres du serveur n’est pas configurée pour le groupe, les membres peuvent envoyer des messages GDOI pour s’inscrire et s’inscrire auprès du serveur, mais le serveur n’est pas en mesure d’envoyer des messages clés en main aux groupkey-pull membres.

La communication entre les membres du serveur est configurée pour le groupe en utilisant l’énoncé de server-member-communication configuration au niveau de edit security group-vpn server la [ ] hiérarchie. Les options suivantes peuvent être définies:

  • Algorithme de chiffrement utilisé pour les communications entre le serveur et le membre. Vous pouvez spécifier 3des-sur-le-cas, aes-128-en-sire, aes-192-sures-256-s ou des-déses.. Il n’y a pas d’algorithme par défaut.

  • Algorithme d’authentification (md5 ou sha1) utilisé pour authentifier le membre du serveur. Il n’y a pas d’algorithme par défaut.

  • Que le serveur envoie des messages unicast ou multicast clés en main aux membres du groupe et aux paramètres liés au type de communication.

  • Intervalle au cours duquel le serveur envoie des messages de pulsation au membre du groupe. Cela permet au membre de déterminer si le serveur a été redémarré, ce qui l’obligerait à s’y réins inscrit. Le par défaut est de 300 secondes.

  • Durée de vie pour la clé de chiffrement (KEK). Le par défaut est de 3 600 secondes.

La configuration de la communication entre les serveurs est nécessaire pour que le serveur de groupe envoie des messages clés en main aux membres, mais il se peut que ce comportement ne soit pas souhaité. Par exemple, si les membres du groupe sont des pairs dynamiques (par exemple dans un bureau à domicile), les équipements ne sont pas toujours actifs et l’adresse IP d’un équipement peut être différente à chaque fois qu’il est mis sous tension. La configuration de la communication entre les membres du serveur pour un groupe de pairs dynamiques peut entraîner des transmissions inutiles par le serveur. Si vous souhaitez que IKE des négociations SA de phase 1 soient toujours effectuées afin de protéger les négociations GDOI, ne configurez pas la communication entre les membres du serveur.

Si la communication entre les membres du serveur d’un groupe n’est pas configurée, la liste de membres affichée par la commande indique aux membres du groupe qui se sont inscrits auprès du serveur ; les membres peuvent être actifs ou show security group-vpn server registered-members non. Lorsque la communication entre les membres du serveur d’un groupe est configurée, la liste de membres du groupe est autorisée. Si le type de communication est configuré en tant qu’unicast, show security group-vpn server registered-members la commande affiche uniquement les membres actifs. Si le type de communication est configuré en tant que multicast, la commande affiche les membres qui se sont enregistrés auprès du serveur après la configuration ; la liste de membres ne représente pas nécessairement les membres actifs, car les membres peuvent être invités à abandonner le service après show security group-vpn server registered-members l’inscription.

Understanding Group VPNv1 Group Key Operations

Ce sujet contient les sections suivantes:

Clés de groupe

Le serveur de groupe tient à jour une base de données afin de suivre la relation entre les groupes VPN, les membres des groupes et les clés de groupe. Le serveur télécharge deux types de clés de groupe aux membres:

  • Clé de chiffrement (KEK): utilisée pour chiffrer les messages re-clés. Un KEK est pris en charge par groupe.

  • Clé de chiffrement du trafic (TEK): utilisée pour chiffrer et déchiffrer le trafic de données IPsec entre les membres du groupe.

La clé associée au SA n’est acceptée par un membre du groupe que si une stratégie de portée de correspondance est configurée sur le membre. Une clé acceptée est installée pour le VPN de groupe, tandis qu’une clé rejetée est écartée.

Messages clés en main

Si le groupe est configuré pour les communications entre les serveurs, le serveur envoie périodiquement des messages sa et des actualisations clés aux membres avec des groupkey-push messages re-clés. Les messages re-clés sont envoyés avant l’expiration des SA ; cela garantit que les clés valides sont disponibles pour le chiffrement du trafic entre les membres du groupe.

Le serveur envoie également des messages clés clés aux membres en cas de modification de l’appartenance au groupe ou de la modification du groupe SA (par exemple, une stratégie de groupe est ajoutée ou supprimée).

Les options de communications entre les membres du serveur doivent être configurées sur le serveur pour permettre au serveur d’envoyer des messages clés en main aux membres du groupe. Ces options spécifient le type de message et les intervalles à partir des lesquels les messages sont envoyés, comme expliqué dans les sections suivantes:

Il existe deux types de messages clés en main:

  • Messages clés en main: le serveur de groupe envoie une copie du message re-clé à chaque membre du groupe. Une fois le message re-clé reçu, les membres doivent envoyer un message d’accusé de réception (ACK) au serveur. Si le serveur ne reçoit pas d’ACK de la part d’un membre (y compris la retransmission de messages clés en main), le serveur considère qu’il est inactif et le supprime de la liste de membres. Le serveur cesse d’envoyer des messages clés en main au membre.

    Les déclarations de configuration et les instructions de configuration pour les communications membres du serveur contrôlent le re-transmission des messages clés en main par le serveur lorsqu’aucun ACK n’est reçu number-of-retransmissionretransmission-period d’un membre.

  • Messages clés en main multicast: le serveur de groupe envoie une copie du message re-clé de l’interface sortante spécifiée à l’adresse de groupe multicast configurée. Les membres n’envoient pas d’accusé de réception de messages clés en multicast. La liste de membres inscrits ne représente pas nécessairement des membres actifs, car les membres peuvent être abandonns après l’inscription initiale. Tous les membres du groupe doivent être configurés pour prendre en charge les messages multicast.

    Les protocoles multicast IP doivent être configurés pour permettre la diffusion du trafic multicast sur le réseau. Pour plus d’informations sur la configuration des protocoles multicast sur Juniper Networks, consultez le Guide de l’utilisateur des protocoles multicast.

L’intervalle au cours duquel le serveur envoie des messages clés en main est calculé en fonction des valeurs des énoncés de configuration et de la hiérarchie lifetime-secondsactivation-time-delay [ edit security group-vpn server group ] L’intervalle est calculé en lifetime-seconds minus 4*(activation-time-delay) tant que .

Le kek est configuré dans le cadre des communications entre les membres du serveur ; le par défaut est lifetime-seconds de 3 600 secondes. Le TEK est configuré pour la proposition IPsec ; le par défaut est lifetime-seconds de 3 600 secondes. Le groupe est configuré pour le groupe sur le serveur ; le temps par défaut activation-time-delay est de 15 secondes. L’intervalle entre les valeurs par défaut et l’intervalle au cours duquel le serveur envoie des messages clés est lifetime-secondsactivation-time-delay de 3600 minus 4*15 3 540 secondes.

Inscription aux membres

Si un membre du groupe ne reçoit pas de nouvelle clé SA sur le serveur avant l’expiration de la clé actuelle, le membre doit s’résinsindre au serveur et obtenir les clés mises à jour à l’aide d’un échange groupkey-pull GDOI. Dans ce cas, l’intervalle au cours duquel le serveur envoie des messages clés en main est calculé comme suit: lifetime-seconds moins 3*( activation-time-delay ). L’intervalle entre les valeurs par défaut et l’intervalle au cours duquel le serveur envoie des messages clés en main est de lifetime-secondsactivation-time-delay 3 600 moins 3*15, ou 3 555 secondes.

La re-agrégation des membres peut avoir lieu pour les raisons suivantes:

  • Le membre détecte un redémarrage du serveur en l’absence de pulsations reçues du serveur.

  • Le message rekey du serveur de groupe est perdu ou différé, et la durée de vie du TEK a expiré.

Activation des clés

Lorsqu’un membre reçoit une nouvelle clé du serveur, elle attend avant d’utiliser la clé de chiffrement. Cette période est déterminée par l’énoncé de activation-time-delay configuration et la réception de la clé par le biais d’un message clé envoyé depuis le serveur ou par le fait que le membre s’est ré-inscrit au serveur.

Si la clé est reçue par le biais d’un message rekey envoyé depuis le serveur, le membre attend 2*( ) secondes avant activation-time-delay d’utiliser la clé. Si la clé est reçue par le biais de la re-agrégation des membres, le membre attend le nombre de secondes spécifiées par la activation-time-delay valeur.

Un membre conserve les deux clés les plus récentes envoyées depuis le serveur pour chaque groupe DE SA installé sur le membre. Les deux clés peuvent être utilisées pour le déchiffrement, tandis que la clé la plus récente est utilisée pour le chiffrement. La clé précédente est supprimée le nombre de secondes spécifiées par la valeur après activation-time-delay l’activation de la nouvelle clé.

L’énoncé de activation-time-delay configuration est par défaut de 15 secondes. En d’autres temps, un paquet peut être abandonné sur un membre du groupe distant avant l’installation de la nouvelle clé. Prenons en compte les délais de transport du système et de la topologie du réseau lorsque vous modifiez la activation-time-delay valeur. Pour les transmissions unicast, le délai de transport du système est proportionnel au nombre de membres du groupe.

Un serveur VPNv1 de groupe peut envoyer plusieurs clés de chiffrement du trafic (TEK) à un membre du groupe VPNv1 en réponse à une groupkey-pull demande. Les descriptions suivantes expliquent comment le membre du groupe VPNv1 gère le TEK existant et les TEK qu’il reçoit du serveur:

  • Si le membre VPNv1 du groupe reçoit au moins deux TEK, il contient les deux derniers TEK et supprime le TEK existant. Sur les deux TEK maintenus, le TEK plus ancien est activé immédiatement et le dernier TEK est activé une fois que le serveur VPNv1 de groupe configuré s’est écoulé (le temps par défaut est activation-time-delay de 15 secondes).

  • Si le membre VPNv1 du groupe ne reçoit qu’un seul TEK ou qu’il reçoit un TEK par le biais d’un message du serveur, le TEK existant n’est pas supprimé jusqu’à l’expiration de la durée de vie groupkey-push dure. La durée de vie n’est pas raccourcie pour le TEK existant.

Le membre VPNv1 du groupe installe toujours un TEK reçu même si la durée de vie du TEK est deux fois plus activation-time-delay importante.

Messages de pulsations VPNv1 de groupe

Lorsque la communication entre les membres du serveur est configurée, le serveur VPNv1 du groupe envoie des messages de pulsation aux membres à intervalles spécifiés (l’intervalle par défaut est de 300 secondes). Le mécanisme de pulsation permet aux membres de s’résinsiner au serveur si le nombre de pulsations spécifié n’est pas reçu. Par exemple, les membres ne reçoivent pas de messages de pulsation lors du redémarrage du serveur. Une fois le redémarrage du serveur, les membres s’inscritnt à nouveau au serveur.

Les battements de cœur sont transmis par groupkey-push les messages. Le numéro de séquence est incrémenté sur chaque message de pulsation, ce qui protège les membres des attaques en réponse. Contrairement aux messages re-clés, les messages de pulsation ne sont pas reconnus par les destinataires et ne sont pas retransmises par le serveur.

Les messages de pulsation contiennent les informations suivantes:

  • État actuel et configuration des clés sur le serveur

  • Temps relatif, si l’antireplay est activé

En comparant ces informations par pulsations, un membre peut détecter s’il a manqué des informations sur le serveur ou des messages re-clés. Le membre se ré-inscrit afin de s’synchroniser avec le serveur.

Les messages de pulsation peuvent augmenter la congestion du réseau et entraîner des regroupements inutiles de membres. Ainsi, la détection des pulsations peut être désactivée sur le membre si nécessaire.

Understanding Group VPNv1 Server-Member Colocation Mode

Les fonctions de serveur de groupe et de membre du groupe sont séparées et ne se chevauchent pas. Les fonctions de serveur et de membre peuvent coexister dans le même équipement physique, appelé mode de colocation. En mode de colocation, il n’y a aucun changement en termes de fonctionnalité et de comportement du serveur ou d’un membre, mais le serveur et le membre doivent se voir attribuer différentes adresses IP afin que les paquets soient livrés correctement. En mode de colocation, une seule adresse IP peut être attribuée au serveur et une seule adresse IP peut être attribuée au membre de tous les groupes.

Présentation de la configuration VPNv1 de groupe

Ce sujet décrit les tâches principales pour la configuration de la VPNNv1 de groupe.

Sur le serveur de groupe, configurez les configurations suivantes:

  1. IKE phase 1. Utilisez la hiérarchie [ ] pour configurer la IKE edit security group-vpn server ike phase 1 SA. Découvrez understanding IKE phase 1 pour le groupe VPNv2.
  2. PHASE 2 SA IPsec. Voir Understanding IPsec SA Configuration for Group VPNv1.
  3. groupe VPN. Voir la présentation de la configuration VPNv1 des groupes.

Au membre du groupe, configurez les configurations suivantes:

  1. IKE phase 1. Utilisez la [ ] hiérarchie pour configurer IKE edit security group-vpn member ike phase 1 SA. Découvrez understanding IKE phase 1 pour le groupe VPNv1.

  2. PHASE 2 SA IPsec. Voir Understanding IPsec SA Configuration for Group VPNv1.

  3. Politique de portée qui détermine les stratégies de groupe installées sur le membre. Voir Understanding Dynamic Policies for Group VPNv1.

Pour éviter les problèmes de fragmentation des paquets, nous recommandons de configurer l’interface utilisée par le membre du groupe pour se connecter au réseau MPLS pour une taille de MTU (MTU) ne supérieure à 1 400 octets. Utilisez set interface mtu l’instruction de configuration pour définir la MTU taille.

Le groupe VPN est configuré sur le serveur avec l’énoncé de group configuration au niveau de edit security group-vpn server la hiérarchie []

Les informations du groupe sont constituées des informations suivantes:

  • Identifiant de groupe: valeur entre 1 et 65 535 qui identifie le groupe VPN. Le même identifiant de groupe doit être configuré sur le membre du groupe pour l’identification IKE.

  • Les membres du groupe, tels que configurés avec ike-gateway l’énoncé de configuration. Cette instruction de configuration peut prendre plusieurs instances, à raison d’une pour chaque membre du groupe.

  • Adresse IP du serveur (l’adresse de l’interface de bouclation est recommandée).

  • Stratégies de groupe: stratégies à télécharger pour les membres. Les stratégies de groupe décrivent le trafic auquel s’appliquent les sa et clés. Voir Understanding Dynamic Policies for Group VPNv1.

  • Communication entre les serveurs: configuration facultative permettant au serveur d’envoyer des messages clés en main aux membres. Voir la présentation du groupe VPNv1.

  • Antireplay: configuration facultative qui détecte l’interception et la rejeu des paquets. Voir Understanding Antireplay for Group VPNv1.

Compréhension IKE de phase 1 pour LAVPNv1 de groupe

Un IKE sa de phase 1 entre le serveur du groupe et un membre du groupe établit un canal sécurisé au sein duquel négocier les SA IPsec partagées par un groupe. Pour les VPN IPsec standard sur Juniper Networks de sécurité, la configuration SA de phase 1 consiste à spécifier une proposition, une stratégie et une passerelle de IKE de données. Pour les VPN de groupe VPNv1, la configuration IKE SA de phase 1 est similaire à celle des VPN IPsec standard, mais s’effectue au niveau de la hiérarchie edit security group-vpn []

Dans la IKE de proposition, vous définissez la méthode d’authentification et les algorithmes d’authentification et de chiffrement qui seront utilisés pour ouvrir un canal sécurisé entre les participants. Dans la configuration d’une stratégie de IKE, vous définissez le mode (principal ou agressif) dans lequel le canal de phase 1 sera négocié, spécifiez le type d’échange de clés à utiliser et faites référence à la proposition de phase 1. Dans la IKE, vous faites référence à la stratégie de phase 1.

L’option d’algorithme d’authentification est uniquement prise en charge par les vpn de groupe VPNv2 sur les équipements sha-256 SRX100, SRX110, SRX210, SRX220, SRX240, SRX550 et SRX650. Lorsque les membres VPNv1 du groupe sont interopérables avec les serveurs VPNv2 de groupe, cette option doit être configurée sur les membres VPNv1 du groupe à l’achat de la edit security group-vpn member ike proposal proposal-name authentication-algorithm sha-256 commande. Sur le serveur VPNv2 de groupe, doit être configuré pour IKE propositions et doit être configuré pour les authentication-algorithm sha-256authentication-algorithm hmac-sha-256-128 propositions IPsec.

Si une passerelle IKE d’un membre du groupe VPNv1 est configurée avec plusieurs adresses de passerelle, le message d’erreur « Une seule adresse à distance est autorisée à être configurée par configuration de la passerelle IKE » s’affiche lorsque la configuration est engagée.

La configuration IKE phase 1 du serveur de groupe doit correspondre à la configuration IKE phase 1 du groupe de membres.

Understanding IPsec SA Configuration for Group VPNv1

Une fois que le serveur et les membres ont établi un canal sécurisé et authentifié dans le cadre des négociations de phase 1, ils vont jusqu’à la phase 2. Les négociations de phase 2 établissent les SA IPsec partagées par les membres du groupe pour sécuriser les données transmises par les membres. Bien que la configuration SA IPsec pour VPN de groupe soit similaire à celle des VPN standard, un membre du groupe n’a pas besoin de négocier le SA avec les autres membres du groupe.

La configuration IPsec de phase 2 pour VPNNv1 de groupe se compose des informations suivantes:

  • Proposition d’algorithme de chiffrement, d’authentification et de protocole de sécurité à utiliser pour le sa. La proposition SA IPsec est configurée sur le serveur de groupe avec l’énoncé de proposal configuration au niveau edit security group-vpn server ipsec de la hiérarchie []

  • Une politique de groupe qui fait référence à la proposition. Une stratégie de groupe spécifie le trafic (protocole, adresse source, port source, adresse de destination et port de destination) auquel s’appliquent le SA et les clés. La stratégie de groupe est configurée sur le serveur avec l’énoncé de ipsec-sa configuration au niveau de la hiérarchie edit security group-vpn server group []

  • Une interface de IKE qui fait référence à l’identifiant de groupe, au serveur de groupe (configuré avec l’instruction de configuration) et à l’interface utilisée par le membre pour se connecter ike-gateway au groupe. L’IKE clé en main est configurée sur le membre avec l’énoncé de ipsec vpn configuration au niveau de la hiérarchie edit security group-vpn member []

Understanding Dynamic Policies for Group VPNv1

Le serveur de groupe distribue des SA de groupe et des clés aux membres d’un groupe spécifié. Tous les membres du même groupe peuvent partager les mêmes SA IPsec. Cependant, tous les SA configurés pour un groupe ne sont pas installés sur chaque membre du groupe. Le sa installé sur un membre spécifique est déterminé par la stratégie associée au groupe SA et les stratégies de sécurité configurées sur le membre.

Dans un groupe VPN, chaque sa de groupe et la clé que le serveur pousse à un membre sont associées à une stratégie de groupe. La stratégie de groupe décrit le trafic sur lequel la clé doit être utilisée, y compris le protocole, l’adresse source, le port source, l’adresse de destination et le port de destination.

Les stratégies de groupe identiques (configurées avec les mêmes valeurs d’adresse source, de destination, de port source, de port de destination et de protocole) ne peuvent pas exister pour un seul groupe. Une erreur est renvoyée si vous tentez de valider une configuration contenant des stratégies de groupe identiques pour un groupe. Si c’est le cas, vous devez supprimer l’une des stratégies de groupe identiques.

Pour un membre du groupe, une politique de portée doit être configurée pour définir le champ d’application de la stratégie de groupe téléchargée depuis le serveur. Une stratégie de groupe distribuée depuis le serveur est comparée aux stratégies d’envergure configurées sur le membre. Pour qu’une politique de groupe soit installée sur le membre, les conditions suivantes doivent être remplies:

  • Toutes les adresses indiquées dans la stratégie de groupe doivent se trouver dans la plage d’adresses indiquées dans la stratégie d’ampleur.

  • Le port source, le port de destination et le protocole spécifiés dans la stratégie de groupe doivent correspondre à ceux configurés dans la stratégie de portée.

Une stratégie de groupe installée sur un membre s’appelle une stratégie dynamique.

Une stratégie de portée peut faire partie d’une liste de stratégies de sécurité pour un contexte spécifique de zone à zone. Junos OS effectue une recherche des stratégies de sécurité sur les paquets entrants en commençant par le haut de la liste classement.

Selon la position de la politique de portée au sein de la liste énumérée de stratégies de sécurité, il existe plusieurs possibilités d’examen dynamique des stratégies:

  • Si le paquet entrant correspond à une stratégie de sécurité avant que la stratégie de portée ne soit envisagée, une recherche dynamique de la stratégie ne se produit pas.

  • Si une stratégie entrante correspond à une stratégie d’envergure, le processus de recherche se poursuit pour obtenir une stratégie dynamique correspondant. Si une stratégie dynamique équivalente est mise en place, l’action de la stratégie (permise) est exécutée. S’il n’existe pas de stratégie dynamique équivalente, le processus de recherche continue de rechercher les stratégies ci-dessous la stratégie d’application.

    Seule une politique d’ampleur est autorisée tunnel dans cette version. Aucune autre action n’est prise en charge.

Vous configurez une stratégie d’envergure pour un membre du groupe en utilisant l’énoncé de policies configuration au niveau edit security de la hiérarchie [ ] Utilisez l’énoncé de configuration dans la règle de tunnel d’autorisation pour faire référence au VPN de groupe ; cela permet aux membres du groupe ipsec-group-vpn de partager un seul SA.

Understanding Antireplay for Group VPNv1

L’anti-attaque est une fonctionnalité IPsec qui peut détecter lorsqu’un paquet est intercepté, puis rejeu par les pirates. L’antireplay est activé par défaut pour les VPN de groupe mais peut être désactivé pour un groupe avec no-anti-replay l’énoncé de configuration.

Lorsque l’antireplay est activé, le serveur de groupe synchronise le temps entre les membres du groupe. Chaque paquet IPsec contient un timestamp. Le membre du groupe vérifie si le délai d’attente du paquet tombe dans la valeur configurée (le par défaut est anti-replay-time-window de 100 secondes). Un paquet est abandonné si le timestamp dépasse la valeur.

Exemple: Configuration du serveur VPNv1 de groupe et des membres

Cet exemple montre comment configurer la VPNNv1 de groupe pour étendre l’architecture IPsec afin de prendre en charge les SA partagés par un groupe d’équipements de sécurité. La VPNNv1 de groupe est prise en charge sur SRX100, SRX110, SRX210, SRX220, SRX240 et SRX650 périphériques.

Conditions préalables

Avant de commencer:

Présentation

Dans , un VPN de groupe se compose de deux équipements membres (membre1 et membre2) et d’un serveur de groupe (l’adresse IP de l’interface de bouclation du serveur est Figure 2 20.0.0.1). L’identifiant de groupe est 1.

Figure 2 : Exemple de configuration pour les membres du serveurExemple de configuration pour les membres du serveur

Les SA VPN de phase 2 doivent être protégés par un SA de phase 1. La configuration VPN du groupe doit donc inclure la configuration IKE des négociations de phase 1 sur le serveur du groupe et sur les membres du groupe. En outre, le même identifiant de groupe doit être configuré à la fois sur le serveur du groupe et sur les membres du groupe.

Les stratégies de groupe sont configurées sur le serveur de groupe. Toutes les stratégies de groupe configurées pour un groupe sont téléchargées pour les membres du groupe. Les stratégies d’étendue configurées sur un membre du groupe déterminent les stratégies de groupe effectivement installées sur ce membre. Dans cet exemple, les stratégies de groupe suivantes sont configurées sur le serveur de groupe pour être téléchargées par tous les membres du groupe:

  • p1: permet l’ensemble du trafic de 10.1.0.0/16 à 10.2.0.0./16

  • p2: permet l’ensemble du trafic de 10.2.0./0./16 à 10.1.0.0/16

  • p3: permet le trafic multicast à partir de 10.1.1.1/32

L’équipement membre1 est configuré avec des stratégies d’application qui autorisent tout le trafic unicast à l’aller et au-delà du sous-réseau 10.0.0.0/8. Aucune politique d’ampleur n’est configurée sur le membre 1 pour autoriser le trafic multicast. par conséquent, la stratégie SA p3 n’est pas installée sur le membre 1.

L’équipement membre2 est configuré avec des stratégies d’application qui font passer le trafic de 10.1.0.0/16 de la zone de confiance à la zone non protégée et à 10.1.0.0/16 de la zone non protégée à la zone de confiance. Par conséquent, la stratégie SA p2 n’est pas installée sur le membre 2.

Configuration

Configuration du serveur de groupe

CLI configuration rapide

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les interruptions de ligne, modifiez tous les détails nécessaires pour correspondre à votre configuration réseau, copiez et collez les commandes dans le CLI au niveau de la hiérarchie, puis entrez dans le [edit]commit mode de configuration.

Procédure étape par étape

L’exemple suivant vous oblige à naviguer dans différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur la manière de vous y rendre, consultez le manuel Using the CLI Editor in Configuration Mode.

Pour configurer le serveur de groupe:

  1. Configurez l’adresse loopback de l’équipement.

  2. Configurez IKE SA de phase 1 (cette configuration doit correspondre au SA de phase 1 configuré sur les membres du groupe).

  3. Définissez la stratégie IKE et définissez les passerelles distantes.

  4. Configurez l’échange SA de phase 2.

  5. Configurez l’identifiant de groupe et IKE passerelle.

  6. Configurer les communications entre serveurs.

  7. Configurez les stratégies de groupe à télécharger pour grouper les membres.

Résultats

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

Si vous avez terminé la configuration de l’équipement, commit saisissez-le en mode de configuration.

Configuration du membre 1

CLI configuration rapide

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les interruptions de ligne, modifiez tous les détails nécessaires pour correspondre à votre configuration réseau, copiez et collez les commandes dans le CLI au niveau de la hiérarchie, puis entrez dans le [edit]commit mode de configuration.

Procédure étape par étape

L’exemple suivant vous oblige à naviguer dans différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur la manière de vous y rendre, consultez le manuel Using the CLI Editor in Configuration Mode.

Pour configurer le membre 1:

  1. Configurer la phase 1 SA (cette configuration doit correspondre à la phase 1 SA configurée sur le serveur de groupe).

  2. Définissez la stratégie IKE et définissez les passerelles distantes.

  3. Configurez l’identifiant de groupe, la IKE et l’interface du membre 1.

    Pour éviter les problèmes de fragmentation des paquets, nous recommandons de configurer l’interface utilisée par les membres du groupe pour se connecter au réseau MPLS pour une taille MTU ne supérieure à 1 400 octets. Utilisez set interface mtu l’instruction de configuration pour définir la MTU taille.

  4. Créez des carnets d’adresses et fixez des zones.

  5. Configurez une stratégie de portée depuis la zone de confiance vers la zone non protégée pour autoriser le trafic unicast à partir du sous-réseau 10.0.0.0/8.

  6. Configurez une stratégie de portée depuis la zone non protégée vers la zone de confiance, qui permet le trafic unicast à partir du sous-réseau 10.0.0.0/8.

Résultats

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

Si vous avez terminé la configuration de l’équipement, commit saisissez-le en mode de configuration.

Configuration du membre2

CLI configuration rapide

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les interruptions de ligne, modifiez tous les détails nécessaires pour correspondre à votre configuration réseau, copiez et collez les commandes dans le CLI au niveau de la hiérarchie, puis entrez dans le [edit]commit mode de configuration.

Procédure étape par étape

L’exemple suivant vous oblige à naviguer dans différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur la manière de vous y rendre, consultez le manuel Using the CLI Editor in Configuration Mode.

Pour configurer le membre2:

  1. Configurer la phase 1 SA (cette configuration doit correspondre à la phase 1 SA configurée sur le serveur de groupe).

  2. Définissez la stratégie IKE et définissez la passerelle distante.

  3. Configurez l’identifiant de groupe, la IKE et l’interface du membre 2.

    Pour éviter les problèmes de fragmentation des paquets, nous recommandons de configurer l’interface utilisée par les membres du groupe pour se connecter au réseau MPLS pour une taille MTU ne supérieure à 1 400 octets. Utilisez set interface mtu l’instruction de configuration pour définir la MTU taille.

  4. Créez un carnet d’adresses et fixez-le à la zone de confiance.

  5. Créez un autre carnet d’adresses et fixez-le à la zone non protégée.

  6. Configurez une stratégie de portée depuis la zone de confiance vers la zone non protégée qui bloque le trafic à partir de 10.1.0.0/16.

  7. Configurez une stratégie de portée depuis la zone non protégée vers la zone de confiance qui bloque le trafic vers 10.1.0.0/16.

Résultats

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

Si vous avez terminé la configuration de l’équipement, commit saisissez-le en mode de configuration.

Vérification

Pour vérifier que la configuration fonctionne correctement, exécutez cette tâche:

Vérification des stratégies dynamiques pour le membre 1

But

Affichez les stratégies dynamiques installées sur le membre 1.

Action

Une fois que le serveur de groupe a téléchargé les clés du membre 1, saisissez show security dynamic-policies la commande depuis le mode opérationnel.

Sens

La stratégie multicast p3 du serveur n’est pas installée sur le membre 1 car aucune stratégie de portée n’est configurée sur le membre 1 permettant le trafic multicast.

Vérification des stratégies dynamiques pour le membre 2

But

Affichez les stratégies dynamiques installées sur le membre 2.

Action

Une fois que le serveur de groupe a téléchargé les clés du membre 2, saisissez show security dynamic-policies la commande depuis le mode opérationnel.

Sens

La stratégie p2 (pour le trafic de 10.1.0.0/16 à 10.2.0.0/16) du serveur n’est pas installée sur le membre 2, car elle est correspondance avec la stratégie de sécurité deny2 configurée sur le membre2.

Exemple: Configuration des communications de groupe VPNv1 serveur-membre pour les messages clés en main unicast

Cet exemple montre comment permettre au serveur d’envoyer des messages clés en mode unicast re-key aux membres du groupe afin de s’assurer que les clés valides sont disponibles pour le chiffrement du trafic entre les membres du groupe. La VPNNv1 de groupe est prise en charge sur SRX100, SRX110, SRX210, SRX220, SRX240 et SRX650 périphériques.

Conditions préalables

Avant de commencer:

  • Configurer le serveur du groupe et les membres pour une négociation IKE phase 1.

  • Configurez le serveur de groupe et les membres pour la phase 2 IPsec SA.

  • Configurez le groupe g1 sur le serveur de groupe.

Présentation

Dans cet exemple, vous spécifiez les paramètres de communication suivants pour le groupe de membres du g1 serveur:

  • Le serveur envoie des messages unicast rekey aux membres du groupe.

  • 3des-s est utilisé pour chiffrer le trafic entre le serveur et les membres.

  • sha1 est utilisé pour l’authentification des membres.

Les valeurs par défaut sont utilisées pour les pulsations du serveur, la durée de vie du KEK et les retransmissions.

Configuration

Procédure

Procédure étape par étape

L’exemple suivant vous oblige à naviguer dans différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur la manière de vous y rendre, consultez le manuel Using the CLI Editor in Configuration Mode.

Pour configurer la communication entre les serveurs:

  1. Définissez le type de communication.

  2. Définissez l’algorithme de chiffrement.

  3. Définissez l’authentification des membres.

Vérification

Pour vérifier que la configuration fonctionne correctement, saisissez la show security group-vpn server group g1 server-member-communication commande.

Exemple: Configuration des communications de groupe VPNv1 serveur-membre pour les messages multicast clés en main

Cet exemple montre comment permettre au serveur d’envoyer des messages clés en multicast resserrés à des membres afin de s’assurer que des clés valides sont disponibles pour chiffrer le trafic entre les membres du groupe. La VPNNv1 de groupe est prise en charge sur SRX100, SRX110, SRX210, SRX220, SRX240 et SRX650 périphériques.

Conditions préalables

Avant de commencer:

Présentation

Dans cet exemple, vous spécifiez la communication serveur-membre du groupe suivante pour le g1 groupe:

  • Le serveur envoie des messages multicast re-clés en plusieurs groupes de membres à l’adresse multicast 226.1.1.1 et à interface ge-0/0/1.0.

  • 3des-s est utilisé pour chiffrer le trafic entre le serveur et les membres.

  • sha1 est utilisé pour l’authentification des membres.

Les valeurs par défaut sont utilisées pour les pulsations du serveur, la durée de vie du KEK et les retransmissions.

Configuration

Procédure

CLI configuration rapide

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les interruptions de ligne, modifiez tous les détails nécessaires pour correspondre à votre configuration réseau, copiez et collez les commandes dans le CLI au niveau de la hiérarchie, puis entrez dans le [edit]commit mode de configuration.

Procédure étape par étape

L’exemple suivant vous oblige à naviguer dans différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur la manière de vous y rendre, consultez le manuel Using the CLI Editor in Configuration Mode.

Pour configurer la communication entre les serveurs et les membres du serveur pour les messages multicast clés en main:

  1. Définissez le type de communication.

  2. Définissez le groupe de multicast.

  3. Définissez l’interface pour les messages multicast sortants.

  4. Définissez l’algorithme de chiffrement.

  5. Définissez l’authentification des membres.

Résultats

À partir du mode de configuration, confirmez votre configuration en entrant la show security group-vpn server group g1 server-member-communication commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration dans cet exemple pour la corriger.

Si vous avez terminé la configuration de l’équipement, commit saisissez-le en mode de configuration.

Vérification

Pour vérifier que la configuration fonctionne correctement, exécutez les tâches suivantes:

Vérification des communications entre les serveurs et les membres pour les messages clés en main multicast

But

Vérifiez que les paramètres de communication pour le message multicast rekey pour les membres du serveur sont correctement configurés afin de s’assurer que des clés valides sont disponibles pour le chiffrement du trafic entre les membres du groupe.

Action

À partir du mode opérationnel, saisissez la show security group-vpn server group g1 server-member-communication commande.

Exemple: Configuration de la VPNNv1 de groupe avec colocation avec les membres du serveur

Cet exemple montre comment configurer un équipement en mode de colocation, qui permet aux fonctions serveur et membre de coexister sur le même équipement physique. La VPNNv1 de groupe est prise en charge sur SRX100, SRX110, SRX210, SRX220, SRX240 et SRX650 périphériques.

Conditions préalables

Avant de commencer:

Présentation

Lorsque le mode de colocation est configuré, les fonctions de serveur de groupe et de membre du groupe peuvent coexister dans le même équipement. En mode de colocation, le serveur et le membre doivent avoir différentes adresses IP pour que les paquets soient correctement livrés.

Dans , un VPN de groupe (identifiant de groupe est 1) se compose de deux membres (membre1 et membre2) et d’un serveur de groupe (l’adresse IP de l’interface de bouclation est Figure 3 20.0.0.1). Remarque: le membre 1 coexiste dans le même équipement que le serveur de groupe. Dans cet exemple, l’interface que member1 utilise pour se connecter au réseau MPLS (ge-0/1/0) se voit attribuer l’adresse IP 10.1.0.1/32.

Figure 3 : Exemple de colocation pour les membres d’un serveurExemple de colocation pour les membres d’un serveur

Les instructions de configuration de ce sujet décrivent comment configurer l’équipement serveur-membre1 du groupe pour le mode de colocation. Pour configurer le membre2, consultez l’exemple: Configuration du serveur VPNv1 de groupe et des membres .

Pour éviter tout problème de fragmentation des paquets, il est recommandé de configurer l’interface utilisée par le membre du groupe pour se connecter au réseau MPLS pour une taille MTU supérieure à 1 400 octets. Utilisez set interface mtu l’instruction de configuration pour définir la MTU taille.

Configuration

Procédure

CLI configuration rapide

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les interruptions de ligne, modifiez tous les détails nécessaires pour correspondre à votre configuration réseau, copiez et collez les commandes dans le CLI au niveau de la hiérarchie, puis entrez dans le [edit]commit mode de configuration.

Procédure étape par étape

L’exemple suivant vous oblige à naviguer dans différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur la manière de vous y rendre, consultez le manuel Using the CLI Editor in Configuration Mode.

Pour configurer un VPN de groupe avec colocation par les membres du serveur:

  1. Configurez l’adresse loopback de l’équipement.

  2. Configurez l’interface que member1 utilise pour se connecter au MPLS réseau.

  3. Configurez la colocation VPN de groupe sur l’équipement.

  4. Configurez IKE SA de phase 1 pour le serveur (cette configuration doit correspondre au SA de phase 1 configuré sur les membres du groupe).

  5. Définissez la stratégie IKE et définissez les passerelles distantes.

  6. Configurez l’échange SA de phase 2 pour le serveur.

  7. Configurez l’identifiant de groupe, IKE passerelle, l’heure d’antireplay et l’adresse serveur sur le serveur.

  8. Configurer le serveur sur les communications membres.

  9. Configurez les stratégies de groupe à télécharger pour grouper les membres.

  10. Configurer la phase 1 SA pour le membre 1 (cette configuration doit correspondre au SA de phase 1 configuré pour le serveur de groupe).

  11. Définissez la stratégie et définissez la passerelle distante pour le membre 1.

  12. Configurez l’identifiant de groupe, la IKE et l’interface du membre 1.

  13. Créez des carnets d’adresses et fixez-les aux zones.

  14. Configurez une stratégie de portée depuis la zone de confiance vers la zone non protégée pour autoriser le trafic unicast à partir du sous-réseau 10.0.0.0/8.

  15. Configurez une stratégie de portée depuis la zone non protégée vers la zone de confiance, qui permet le trafic unicast à partir du sous-réseau 10.0.0.0/8.

Résultats

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

Dans la liste des stratégies de sécurité configurées, assurez-vous que les stratégies d’étendue sont répertoriées avant les stratégies par défaut.

Si vous avez terminé la configuration de l’équipement, commit saisissez-le en mode de configuration.

Vérification

Pour vérifier que la configuration fonctionne correctement, exécutez les tâches suivantes:

Vérification de l’inscription des membres du VPN de groupe

But

Vérifiez que les membres VPN du groupe sont correctement enregistrés.

Action

À partir du mode opérationnel, saisissez la show security group-vpn registered-members commande.

Vérification des associations de sécurité de serveur VPN de groupe pour les IKE

But

Vérifiez les SA pour le serveur VPN de groupe pour IKE.

Action

À partir du mode opérationnel, saisissez la show security group-vpn server ike security-associations commande.

Vérification des associations de sécurité de serveur VPN de groupe pour IPsec

But

Vérifier les SA pour le serveur VPN de groupe pour IPsec.

Action

À partir du mode opérationnel, saisissez la show security group-vpn server ipsec security-associations commande.

Vérification des associations de sécurité des membres vpn de groupe pour les IKE

But

Vérifier les SA pour les membres VPN du groupe pour les IKE.

Action

À partir du mode opérationnel, saisissez la show security group-vpn member ike security-associations commande.

Vérification des associations de sécurité des membres vpn de groupe pour IPsec

But

Vérifier les SA pour les membres VPN de groupe pour IPsec.

Action

À partir du mode opérationnel, saisissez la show security group-vpn member ipsec security-associations commande.

Tableau de l'historique des versions
Version
Description
12.3X48-D30
Depuis le Junos OS version 12.3X48-D30, les membres du groupe VPNv1 peuvent interopérabilité avec les serveurs VPNv2 de groupe.
12.3X48-D30
Depuis Junos OS Version 12.3X48-D30, les membres du groupe VPNv1 sur les équipements SRX100, SRX110, SRX210, SRX220, SRX240, SRX550 et SRX650 peuvent interopérabilité avec les serveurs VPNv2 de groupe.