Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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é qui provient d’un périphérique ou transite par celui-ci.

Présentation de Group VPNv1

Une association de sécurité IPsec (SA) est un accord unidirectionnel entre les participants aux réseaux privés virtuels (VPN) qui définit les règles à utiliser pour les algorithmes d’authentification et de chiffrement, les mécanismes d’échange de clés et les communications sécurisées. Avec les implémentations VPN actuelles, le SA est un tunnel point à point entre deux dispositifs de sécurité. Le groupe VPNv1 étend l’architecture IPsec pour prendre en charge les SA partagées par un groupe d’équipements de sécurité (reportez-vous à la section Figure 1).

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

Group VPNv1 est pris en charge sur les équipements SRX100, SRX110, SRX210, SRX220, SRX240 et SRX650. Avec Group VPNv1, la connectivité any-to-any est obtenue en préservant les adresses IP source et de destination d’origine dans l’en-tête externe. Les paquets multicast sécurisés sont répliqués de la même manière que les paquets multicast en texte clair dans le réseau central.

À partir de Junos OS version 12.3X48-D30, les membres du groupe VPNv1 peuvent interagir avec les serveurs VPNv2 du groupe.

Le groupe VPNv1 a certaines limitations de propriété concernant la RFC 6407, le domaine d’interprétation du groupe (GDOI). Pour utiliser Group VPN sans limitations propriétaires, effectuez une mise à niveau vers Group VPNv2. Group VPNv2 est pris en charge sur les instances de pare-feu virtuel vSRX à partir de Junos OS version 15.1X49-D30, les pare-feu SRX Series à partir de Junos OS version 15.1X49-D40 et les périphériques MX Series à partir de Junos OS version 15.1r2.

Comprendre le protocole GDOI pour le groupe VPNv1

Le groupe VPNv1 est basé sur la RFC 3547, le domaine d’interprétation du groupe (GDOI). Cette RFC décrit le protocole entre les membres d’un groupe et un serveur de groupe pour établir des SA entre les membres du groupe. Les messages GDOI créent, maintiennent ou suppriment des SA pour un groupe d’appareils. Le protocole GDOI fonctionne sur le port 848.

L’Internet Security Association and Key Management Protocol (ISAKMP) définit deux phases de négociation pour établir des SA pour un tunnel IPsec IKE AutoKey. La phase 1 permet à deux appareils d’établir une 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. Dans la phase 2, les échanges GDOI entre le serveur et le membre établissent les SA qui sont partagées avec d’autres membres du groupe. Un membre du groupe n’a pas besoin de négocier IPsec avec les autres membres du groupe. Les échanges GDOI en phase 2 doivent être protégés par les SA ISAKMP Phase 1.

Il existe deux types d’échanges GDOI :

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

  • L’échange groupkey-push est un message de recléage unique qui permet au serveur d’envoyer des SA et des clés de groupe aux membres avant l’expiration des SA de groupe existantes. Les messages de recléage sont des messages non sollicités envoyés par le serveur aux membres.

Comprendre les limitations de Group VPNv1

Les éléments suivants ne sont pas pris en charge dans cette version pour le groupe VPNv1 :

  • Instances de routage autres que celles par défaut

  • Cluster de châssis

  • Clusters de serveurs

  • VPN de groupe basé sur le routage

  • Déploiement public basé sur l’Internet

  • SNMP

  • Refuser la stratégie du serveur VPN Cisco GET

  • Interface J-Web pour la configuration et la surveillance

À partir de la version 12.3X48-D30 de Junos OS, les membres du groupe VPNv1 sur les équipements SRX100, SRX110, SRX210, SRX220, SRX240, SRX550 et SRX650 peuvent interagir avec les serveurs VPNv2 du groupe. Lorsque vous configurez des membres VPNv1 de groupe pour une utilisation avec des serveurs VPNv2 de groupe, notez les limitations suivantes :

  • Le groupe VPNv2 prend en charge le protocole de détection des délais de livraison IP de l’IETF pour un mécanisme antirejeu basé sur le temps. Par conséquent, l’antireplay basé sur le protocole de détection du délai de remise IP n’est pas pris en charge sur les membres VPNv1 du groupe et doit être désactivé sur le serveur VPNv2 du groupe à l’aide de la deactivate security group-vpn server group group-name anti-replay-time-window commande.

  • Le serveur VPN v2 de groupe ne prend pas en charge la colocalisation, c’est-à-dire que les fonctions de serveur de groupe et de membre de groupe existent dans le même appareil.

  • Le serveur Group VPNv2 ne prend pas en charge les transmissions de pulsations. La pulsation doit être désactivée sur le membre Group VPNv1 avec la deactivate security group-vpn member ipsec vpn vpn-name heartbeat-threshold commande. Nous vous recommandons d’utiliser des clusters de serveurs VPNv2 de groupe pour éviter tout impact sur le trafic dû à des redémarrages ou à d’autres interruptions sur le serveur VPNv2 de groupe.

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

    Les nouvelles clés sont prises en charge avec les messages groupkey-pull. S’il existe des problèmes de mise à l’échelle où les membres de Group VPNv1 ne peuvent pas terminer l’opération groupkey-pull avant l’expiration de la durée de vie matérielle TEK, nous vous recommandons d’augmenter la durée de vie TEK pour laisser suffisamment de temps aux membres pour terminer l’opération groupkey-pull. Les chiffres de mise à l’échelle de Juniper ont une durée de vie TEK de 2 heures.

  • Si le serveur VPNv2 de groupe est redémarré ou mis à niveau, ou si les SA du groupe sont effacées, de nouveaux membres ne peuvent pas être ajoutés au réseau tant que la prochaine recléage n’a pas lieu pour les membres existants. Les nouveaux membres ne peuvent pas envoyer de trafic aux membres existants qui ont d’anciennes clés. Pour contourner ce problème, effacez les SA sur les membres du groupe VPNv1 existants à l’aide de la clear security group-vpn member ipsec security-associations commande.

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

Comprendre les serveurs et les membres VPNv1 de groupe

Le centre d’un VPN de groupe est le serveur de groupe. Le serveur de groupe effectue les tâches suivantes :

  • Contrôle l’appartenance à un groupe

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

  • Gère les SA et les clés de groupe 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 serveur de groupe.

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

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

Voici une vue d’ensemble des actions du serveur VPN de groupe et des membres :

  1. Le serveur de groupe écoute les membres sur le port UDP 848 pour qu’ils s’inscrivent. Un appareil membre doit fournir une authentification IKE phase 1 correcte pour rejoindre le groupe. L’authentification par clé pré-partagée est prise en charge.

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

  3. Le serveur ajoute le membre à l’appartenance 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 SA et des actualisations de clés aux membres du groupe avec des messages de renouvellement de clé (GDOI groupkey-push). Les messages de renouvellement de clé sont envoyés avant l’expiration des SA ; Cela permet de s’assurer que des clés valides sont disponibles pour chiffrer le trafic entre les membres du groupe.

Le serveur envoie également des messages de recléage pour fournir de nouvelles clés aux membres lorsqu’il y a un changement dans l’appartenance au groupe ou lorsque la SA du groupe a changé.

Comprendre la communication serveur-membre d’un groupe VPNv1

Group VPNv1 est pris en charge sur les équipements SRX100, SRX110, SRX210, SRX220, SRX240 et SRX650. La communication serveur-membre permet au serveur d’envoyer des messages GDOI groupkey-push aux membres. Si la communication serveur-membre n’est pas configurée pour le groupe, les membres peuvent envoyer des messages GDOI groupkey-pull pour s’inscrire et se réinscrire auprès du serveur, mais le serveur n’est pas en mesure d’envoyer des messages de recléage aux membres.

La communication entre les membres du serveur est configurée pour le groupe à l’aide de server-member-communication l’instruction de configuration dans la hiérarchie [edit security group-vpn server]. 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-cbc, aes-128-cbc, aes-192-cbc, aes-256-cbc ou des-cbc. Il n’y a pas d’algorithme par défaut.

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

  • Indique si le serveur envoie des messages de recléage unicast ou multicast aux membres du groupe et les paramètres liés au type de communication.

  • Intervalle auquel le serveur envoie des messages de pulsation au membre du groupe. Cela permet au membre de déterminer si le serveur a redémarré, ce qui l’oblige à se réinscrire auprès du serveur. La valeur par défaut est de 300 secondes.

  • Durée de vie de la clé de chiffrement de clé (KEK). La valeur par défaut est de 3600 secondes.

La configuration de la communication serveur-membre est nécessaire pour que le serveur de groupe envoie des messages de recléage aux membres, mais il peut y avoir des situations dans lesquelles ce comportement n’est pas souhaité. Par exemple, si les membres d’un groupe sont des pairs dynamiques (comme dans un bureau à domicile), les appareils ne sont pas toujours opérationnels et l’adresse IP d’un appareil peut être différente à chaque fois qu’il est allumé. La configuration de la communication entre les membres du serveur pour un groupe d’homologues dynamiques peut entraîner des transmissions inutiles de la part du serveur. Si vous souhaitez que la négociation IKE Phase 1 SA soit toujours effectuée pour protéger la négociation GDOI, ne configurez pas la communication serveur-membre.

Si la communication serveur-membre d’un groupe n’est pas configurée, la liste des membres affichée par la show security group-vpn server registered-members commande affiche les membres du groupe qui se sont inscrits auprès du serveur ; les membres peuvent être actifs ou non. Lorsque la communication serveur-membre d’un groupe est configurée, la liste des membres du groupe est effacée. Si le type de communication est configuré en unicast, la commande n’affiche que les show security group-vpn server registered-members membres actifs. Si le type de communication est configuré en multidiffusion, la commande affiche les membres qui se sont inscrits auprès du serveur après la configuration ; la show security group-vpn server registered-members liste des membres ne représente pas nécessairement les membres actifs, car les membres peuvent abandonner après l’enregistrement.

Comprendre les opérations clés du groupe VPNv1

Cette rubrique contient les sections suivantes :

Clés de groupe

Le serveur de groupe gère une base de données pour suivre la relation entre les groupes VPN, les membres du groupe et les clés de groupe. Il existe deux types de clés de groupe que le serveur télécharge pour les membres :

  • Key Encryption Key (KEK) : utilisée pour chiffrer les messages de reclé. 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 à une SA n’est acceptée par un membre du groupe que si une stratégie d’étendue correspondante 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 ignorée.

Resaisir les messages

Si le groupe est configuré pour les communications entre membres du serveur, le serveur envoie régulièrement des SA et des actualisations de clés aux membres du groupe avec des messages de renouvellement de clé (GDOI groupkey-push). Les messages de renouvellement de clé sont envoyés avant l’expiration des SA ; Cela permet de s’assurer que des clés valides sont disponibles pour chiffrer le trafic entre les membres du groupe.

Le serveur envoie également des messages de renouvellement de clé pour fournir de nouvelles clés aux membres lorsqu’il y a un changement dans l’appartenance au groupe ou que la SA du groupe a changé (par exemple, une stratégie de groupe est ajoutée ou supprimée).

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

Il existe deux types de messages de renouvellement de clé :

  • Messages de renouvellement de clé unicast : le serveur de groupe envoie une copie du message de renouvellement de clé à chaque membre du groupe. À la réception du message de reclé, les membres doivent envoyer un accusé de réception (ACK) au serveur. Si le serveur ne reçoit pas d’accusé de réception d’un membre (y compris la retransmission des messages de reclé), il considère que le membre est inactif et le supprime de la liste des membres. Le serveur cesse d’envoyer des messages de renouvellement de clé au membre.

    Les number-of-retransmission instructions et retransmission-period configuration pour les communications entre membres du serveur contrôlent le renvoi des messages de recléage par le serveur lorsqu’aucun accusé de réception n’est reçu d’un membre.

  • Messages de renouvellement de clé de multidiffusion : le serveur de groupe envoie une copie du message de renouvellement de clé de l’interface sortante spécifiée à l’adresse de groupe de multidiffusion configurée. Les membres n’envoient pas d’accusé de réception des messages de renouvellement de clé de multidiffusion. La liste des membres inscrits ne représente pas nécessairement les membres actifs, car les membres peuvent abandonner 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 distribution du trafic multicast dans le réseau. Pour plus d’informations sur la configuration des protocoles multicast sur les équipements Juniper Networks, reportez-vous au Guide de l’utilisateur des protocoles multicast .

L’intervalle auquel le serveur envoie les messages de renouvellement de clé est calculé en fonction des valeurs des instructions de lifetime-seconds configuration et activation-time-delay de la hiérarchie [edit security group-vpn server group]. L’intervalle est calculé comme lifetime-seconds minus 4*(activation-time-delay).

Le lifetime-seconds pour la KEK est configuré dans le cadre des communications entre les membres du serveur ; la valeur par défaut est de 3600 secondes. Le lifetime-seconds pour le TEK est configuré pour la proposition IPsec ; la valeur par défaut est 3600 secondes. Le activation-time-delay est configuré pour le groupe sur le serveur, la valeur par défaut est de 15 secondes. En utilisant les valeurs par défaut pour lifetime-seconds et activation-time-delay, l’intervalle auquel le serveur envoie des messages de recléage est 3600 minus 4*15de , soit 3540 secondes.

Inscription des membres

Si un membre du groupe ne reçoit pas de nouvelle clé SA du serveur avant l’expiration de la clé actuelle, le membre doit se réinscrire auprès du serveur et obtenir des clés mises à jour auprès d’un échange GDOI groupkey-pull . Dans ce cas, l’intervalle auquel le serveur envoie les messages de recléage est calculé comme suit : lifetime-seconds moins 3*(activation-time-delay). En utilisant les valeurs par défaut pour lifetime-seconds et activation-time-delay, l’intervalle auquel le serveur envoie des messages de recléage est de 3600 moins 3*15, soit 3555 secondes.

La réinscription d’un membre peut avoir lieu pour les raisons suivantes :

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

  • Le message de renouvellement de clé du serveur de groupe est perdu ou retardé, et la durée de vie de TEK a expiré.

Activation de la clé

Lorsqu’un membre reçoit une nouvelle clé du serveur, il attend un certain temps avant d’utiliser la clé pour le chiffrement. Cette période de temps est déterminée par activation-time-delay l’instruction de configuration et si la clé est reçue par le biais d’un message de renouvellement de clé envoyé par le serveur ou à la suite d’un réenregistrement du membre auprès du serveur.

Si la clé est reçue par le biais d’un message de recléage envoyé par le serveur, le membre attend 2*(activation-time-delay) secondes avant d’utiliser la clé. Si la clé est reçue par le biais d’un réenregistrement de membre, le membre attend le nombre de secondes spécifié par la activation-time-delay valeur.

Un membre conserve les deux clés les plus récentes envoyées par le serveur pour chaque SA de groupe installée 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 touche précédente est supprimée le nombre de secondes spécifié par la valeur après l’activation de la activation-time-delay nouvelle clé.

La valeur par défaut de l’instruction de configuration est 15 activation-time-delay secondes. Si cette période est trop petite, un paquet peut être abandonné chez un membre du groupe distant avant l’installation de la nouvelle clé. Tenez compte de la topologie du réseau et des délais de transport du système 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 VPNv1 du groupe en réponse à une groupkey-pull demande. Ce qui suit décrit comment le membre VPNv1 du groupe gère les TEK existants et les TEK qu’il reçoit du serveur :

  • Si le membre VPNv1 du groupe reçoit au moins deux TEK, il conserve les deux TEK les plus récents et supprime le TEK existant. Des deux TEK détenus, le TEK le plus ancien est activé immédiatement, et le TEK le plus récent est activé une fois que le TEK configuré sur le serveur VPNv1 de groupe s’est écoulé (la valeur par défaut est de activation-time-delay 15 secondes).

  • Si le membre VPNv1 du groupe ne reçoit qu’un seul TEK, ou s’il reçoit un TEK par le biais d’un groupkey-push message du serveur, le TEK existant n’est pas supprimé avant l’expiration de la durée de vie du matériel. 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 inférieure à deux fois la activation-time-delay valeur.

Comprendre les messages de pulsation de groupe VPNv1

Lorsque la communication serveur-membre est configurée, le serveur VPNv1 du groupe envoie des messages de pulsation aux membres à des intervalles spécifiés (l’intervalle par défaut est de 300 secondes). Le mécanisme de pulsation permet aux membres de se réinscrire auprès du serveur si le nombre spécifié de pulsations n’est pas reçu. Par exemple, les membres ne recevront pas de messages de pulsation lors d’un redémarrage du serveur. Lorsque le serveur a redémarré, les membres se réinscrivent auprès du serveur.

Les battements de cœur sont transmis par le biais groupkey-push de messages. Le numéro de séquence est incrémenté à chaque message de pulsation, ce qui protège les membres contre les attaques de réponse. Contrairement aux messages de reclé, les messages de pulsation ne sont pas reconnus par les destinataires et ne sont pas retransmis 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’antirelecture est activée

En comparant les informations contenues dans les pulsations, un membre peut détecter s’il a manqué des informations sur le serveur ou s’il a oublié des messages de reclé. Le membre se réinscrit pour se synchroniser avec le serveur.

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

Comprendre le mode de colocation serveur-membre du serveur VPNv1 de groupe

Les fonctions de serveur de groupe et de membre de groupe sont distinctes et ne se chevauchent pas. Les fonctions serveur et membre peuvent coexister dans le même périphérique physique, ce que l’on appelle le mode de colocation. En mode colocation, il n’y a pas de changement en termes de fonctionnalité et de comportement du serveur ou d’un membre, mais le serveur et le membre doivent chacun se voir attribuer des adresses IP différentes pour que les paquets puissent être livrés correctement. En mode colocation, il ne peut y avoir qu’une seule adresse IP attribuée au serveur et une seule adresse IP attribuée au membre dans tous les groupes.

Vue d’ensemble de la configuration de Group VPNv1

Cette rubrique décrit les principales tâches de configuration du groupe VPNv1.

Sur le serveur de groupe, configurez les éléments suivants :

  1. Négociation IKE Phase 1. Utilisez la hiérarchie [edit security group-vpn server ike] pour configurer la SA IKE Phase 1. Reportez-vous à la section Présentation de la configuration IKE Phase 1 pour le VPNv2 de groupe .
  2. Phase 2 IPsec SA. Reportez-vous à la section Présentation de la configuration IPsec SA pour le groupe VPNv1.
  3. Groupe VPN. Reportez-vous à la section Vue d’ensemble de la configuration de Group VPNv1.

Sur le membre du groupe, configurez les éléments suivants :

  1. Négociation IKE Phase 1. Utilisez la hiérarchie [edit security group-vpn member ike] pour configurer l’IKE Phase 1 SA. Reportez-vous à la section Présentation de la configuration IKE Phase 1 pour le groupe VPNv1 .

  2. Phase 2 IPsec SA. Reportez-vous à la section Présentation de la configuration IPsec SA pour le groupe VPNv1.

  3. Stratégie d’étendue qui détermine les stratégies de groupe installées sur le membre. Reportez-vous à la section Présentation des stratégies dynamiques pour le VPN de groupe 1.See Understanding Dynamic Policies for Group VPNv1.

Pour éviter les problèmes de fragmentation des paquets, nous vous recommandons de configurer l’interface utilisée par le membre du groupe pour se connecter au réseau MPLS de manière à ce que la taille maximale de l’unité de transmission (MTU) ne dépasse pas 1400 octets. Utilisez l’instruction de set interface mtu configuration pour définir la taille de la MTU.

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

Les informations du groupe sont les suivantes :

Comprendre la configuration IKE Phase 1 pour le VPN de groupe VPNv1

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

Dans la configuration de la proposition IKE, 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 de la stratégie 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 référencez la proposition de phase 1. Dans la configuration de la passerelle IKE, vous référencez la stratégie de phase 1.

Étant donné que Group VPNv2 ne prend en charge que les algorithmes forts, l’option d’algorithme d’authentification est prise en charge pour les sha-256 membres Group VPNv1 sur les appareils SRX100, SRX110, SRX210, SRX220, SRX240, SRX550 et SRX650. Lorsque les membres du groupe VPNv1 interagissent avec les serveurs du groupe VPNv2, cette option doit être configurée sur les membres du groupe VPNv1 à l’aide de la edit security group-vpn member ike proposal proposal-name authentication-algorithm sha-256 commande. Sur le serveur VPNv2 de groupe, authentication-algorithm sha-256 doit être configuré pour les propositions IKE et authentication-algorithm hmac-sha-256-128 doit être configuré pour les propositions IPsec.

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

La configuration IKE Phase 1 sur le serveur de groupe doit correspondre à la configuration IKE Phase 1 sur les membres du groupe.

Comprendre la configuration IPsec SA pour le groupe VPNv1

Une fois que le serveur et le membre ont établi un canal sécurisé et authentifié dans la négociation de la phase 1, ils passent à la phase 2. La négociation de phase 2 établit les SA IPsec qui sont partagées par les membres du groupe pour sécuriser les données transmises entre les membres. Bien que la configuration IPsec SA pour les VPN de groupe soit similaire à la configuration pour les VPN standard, un membre du groupe n’a pas besoin de négocier la SA avec les autres membres du groupe.

Phase 2 : La configuration IPsec pour le groupe VPNv1 se compose des informations suivantes :

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

  • Une stratégie 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 la SA et les clés. La stratégie de groupe est configurée sur le serveur avec l’instruction ipsec-sa de configuration dans la hiérarchie [edit security group-vpn server group ].

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

Comprendre les stratégies dynamiques pour le VPNv1 de groupe

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

Dans un groupe VPN, chaque SA de groupe et chaque clé que le serveur envoie à 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 la même adresse source, la même adresse de destination, le même port source, le même port de destination et les mêmes valeurs de protocole) ne peuvent pas exister pour un seul groupe. Une erreur est renvoyée si vous tentez de valider une configuration qui contient des stratégies de groupe identiques pour un groupe. Si tel est le cas, vous devez supprimer l’une des stratégies de groupe identiques.

Sur un membre du groupe, une stratégie d’étendue doit être configurée pour définir l’étendue de la stratégie de groupe téléchargée à partir du serveur. Une stratégie de groupe distribuée à partir du serveur est comparée aux stratégies d’étendue configurées sur le membre. Pour qu’une stratégie de groupe puisse être installée sur le membre, les conditions suivantes doivent être remplies :

  • Toutes les adresses spécifiées dans la stratégie de groupe doivent se trouver dans la plage d’adresses spécifiée dans la stratégie d’étendue.

  • 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 d’étendue.

Une stratégie de groupe installée sur un membre est appelée stratégie dynamique.

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

En fonction de la position de la stratégie d’étendue dans la liste ordonnée des stratégies de sécurité, il existe plusieurs possibilités de recherche dynamique de stratégie :

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

  • Si une stratégie entrante correspond à une stratégie d’étendue, le processus de recherche d’une stratégie dynamique correspondante se poursuit. S’il existe une stratégie dynamique correspondante, cette action de stratégie (autorisation) est exécutée. S’il n’y a pas de stratégie dynamique correspondante, le processus de recherche continue de rechercher les stratégies situées sous la stratégie d’étendue.

    Dans cette version, seule l’action est autorisée pour une stratégie d’étendue tunnel . Les autres actions ne sont pas prises en charge.

Vous configurez une stratégie d’étendue sur un membre du groupe à l’aide de policies l’instruction de configuration dans la hiérarchie [edit security]. Utilisez l’instruction de configuration de la règle de tunnel d’autorisation ipsec-group-vpn pour référencer le VPN de groupe, ce qui permet aux membres du groupe de partager une seule SA.

Comprendre l’antireplay pour le VPN de groupe v1

L’antireplay est une fonctionnalité IPsec capable de détecter lorsqu’un paquet est intercepté puis rejoué par des attaquants. L’antirelecture est activée par défaut pour les VPN de groupe, mais peut être désactivée pour un groupe avec no-anti-replay l’instruction de configuration.

Lorsque l’antirelecture est activée, le serveur de groupe synchronise l’heure entre les membres du groupe. Chaque paquet IPsec contient un horodatage. Le membre du groupe vérifie si l’horodatage du paquet correspond à la valeur configurée anti-replay-time-window (la valeur par défaut est de 100 secondes). Un paquet est abandonné si l’horodatage dépasse la valeur.

Exemple : Configuration du serveur VPNv1 de groupe et de ses membres

Cet exemple montre comment configurer le groupe VPNv1 pour étendre l’architecture IPsec afin de prendre en charge les SA partagées par un groupe d’équipements de sécurité. Group VPNv1 est pris en charge sur les équipements SRX100, SRX110, SRX210, SRX220, SRX240 et SRX650.

Conditions préalables

Avant de commencer :

Présentation

Dans Figure 2, un VPN de groupe se compose de deux périphériques membres (member1 et member2) et d’un serveur de groupe (l’adresse IP de l’interface de bouclage sur le serveur est 20.0.0.1). L’identificateur de groupe est 1.

Figure 2 : Exemple de configuration d’un membre serveurExemple de configuration d’un membre serveur

Les SA VPN de groupe Phase 2 doivent être protégées par une SA Phase 1. Par conséquent, la configuration du VPN de groupe doit inclure la configuration des négociations IKE Phase 1 sur le serveur du groupe et les membres du groupe. En outre, le même identifiant de groupe doit être configuré à la fois sur le serveur de 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 quelles stratégies de groupe sont réellement installées sur le 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 : autorise tout le trafic de 10.1.0.0/16 à 10.2.0.0./16

  • p2 : autorise tout le trafic de 10.2.0.0./16 à 10.1.0.0/16

  • p3 : autorise le trafic multicast à partir de la version 10.1.1.1/32

L’appareil member1 est configuré avec des stratégies d’étendue qui autorisent tout le trafic unicast à destination et en provenance du sous-réseau 10.0.0.0/8. Il n’existe pas de stratégie de portée configurée sur member1 pour autoriser le trafic multicast ; par conséquent, la politique SA p3 n’est pas installée sur le membre1.

L’appareil member2 est configuré avec des stratégies d’étendue qui suppriment le trafic de la version 10.1.0.0/16 de la zone de confiance vers la zone d’approbation et vers la version 10.1.0.0/16 de la zone d’approbation vers la zone d’approbation. Par conséquent, la politique SA p2 n’est pas installée sur member2.

Configuration

Configuration du serveur de groupe

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.

Pour configurer le serveur de groupe :

  1. Configurez l’adresse de bouclage sur l’appareil.

  2. Configurez l’IKE Phase 1 SA (cette configuration doit correspondre à la Phase 1 SA configurée 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’identificateur de groupe et la passerelle IKE.

  6. Configurez les communications serveur-membre.

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

Résultats

À partir du mode 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 de cet exemple pour la corriger.

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

Configuration de Member1

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.

Pour configurer le membre1 :

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

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

  3. Configurez l’identificateur de groupe, la passerelle IKE et l’interface pour member1.

    Pour éviter les problèmes de fragmentation des paquets, nous recommandons que l’interface utilisée par les membres du groupe pour se connecter au réseau MPLS soit configurée pour une taille de MTU ne dépassant pas 1400 octets. Utilisez l’instruction de set interface mtu configuration pour définir la taille de la MTU.

  4. Créez des carnets d’adresses et attachez-y des zones.

  5. Configurez une stratégie d’étendue de la zone de confiance à la zone non approuvée qui autorise le trafic unicast à destination et en provenance du sous-réseau 10.0.0.0/8.

  6. Configurez une stratégie d’étendue de la zone d’approbation à la zone d’approbation qui autorise le trafic unicast à destination et en provenance du sous-réseau 10.0.0.0/8.

Résultats

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

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

Configuration de Member2

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.

Pour configurer le membre2 :

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

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

  3. Configurez l’identificateur de groupe, la passerelle IKE et l’interface pour member2.

    Pour éviter les problèmes de fragmentation des paquets, nous recommandons que l’interface utilisée par les membres du groupe pour se connecter au réseau MPLS soit configurée pour une taille de MTU ne dépassant pas 1400 octets. Utilisez l’instruction de set interface mtu configuration pour définir la taille de la MTU.

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

  5. Créez un autre carnet d’adresses et joignez-le à la zone de méfiance.

  6. Configurez une stratégie d’étendue de la zone de confiance à la zone non approuvée qui bloque le trafic à partir de la version 10.1.0.0/16.

  7. Configurez une stratégie d’étendue de la zone d’approbation à la zone d’approbation qui bloque le trafic vers la version 10.1.0.0/16.

Résultats

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

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

Vérification

Pour vérifier que la configuration fonctionne correctement, effectuez la tâche suivante :

Vérification des stratégies dynamiques pour Member1

But

Affichez les stratégies dynamiques installées sur member1.

Action

Une fois que le serveur de groupe a téléchargé les clés sur member1, entrez la show security dynamic-policies commande à partir du mode opérationnel.

Sens

La stratégie de multidiffusion p3 du serveur n’est pas installée sur le membre1, car il n’y a pas de stratégie d’étendue configurée sur le membre1 qui autorise le trafic de multidiffusion.

Vérification des stratégies dynamiques pour Member2

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 sur member2, entrez la show security dynamic-policies commande à partir du 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 member2, car elle correspond à la stratégie de sécurité deny2 configurée sur member2.

Exemple : Configuration de la communication serveur-membre du groupe VPNv1 pour les messages de renouvellement de clé de monodiffusion

Cet exemple montre comment permettre au serveur d’envoyer des messages de renouvellement de clé unicast aux membres du groupe afin de s’assurer que des clés valides sont disponibles pour chiffrer le trafic entre les membres du groupe. Group VPNv1 est pris en charge sur les équipements SRX100, SRX110, SRX210, SRX220, SRX240 et SRX650.

Conditions préalables

Avant de commencer :

  • Configurez le serveur et les membres du groupe pour la négociation IKE Phase 1.

  • Configurez le serveur de groupe et les membres pour la phase 2 de l’AS IPsec.

  • Configurez le groupe sur le serveur de groupe g1 .

Présentation

Dans cet exemple, vous spécifiez les paramètres de communication serveur-membre suivants pour group g1:

  • Le serveur envoie des messages de renouvellement de clé unicast aux membres du groupe.

  • 3des-cbc 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 de la KEK et les retransmissions.

Configuration

Procédure

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.

Pour configurer la communication entre les membres du serveur :

  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, entrez la show security group-vpn server group g1 server-member-communication commande.

Exemple : Configuration de la communication serveur-membre du groupe VPNv1 pour les messages de renouvellement de clé multicast

Cet exemple montre comment permettre au serveur d’envoyer des messages de renouvellement de clé multicast aux membres du groupe afin de s’assurer que des clés valides sont disponibles pour chiffrer le trafic entre les membres du groupe. Group VPNv1 est pris en charge sur les équipements SRX100, SRX110, SRX210, SRX220, SRX240 et SRX650.

Conditions préalables

Avant de commencer :

Présentation

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

  • Le serveur envoie des messages de recléabilité multicast aux membres du groupe au moyen de l’adresse multicast 226.1.1.1 et de l’interface ge-0/0/1.0.

  • 3des-cbc 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 de la KEK et les retransmissions.

Configuration

Procédure

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.

Pour configurer la communication entre les membres du serveur pour les messages de renouvellement de clé multicast :

  1. Définissez le type de communication.

  2. Définissez le groupe 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 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 de cet exemple pour la corriger.

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

Vérification

Pour vérifier que la configuration fonctionne correctement, effectuez les opérations suivantes :

Vérification de la communication entre les membres du serveur pour les messages de renouvellement de clé de multidiffusion

But

Vérifiez que les paramètres de communication serveur-membre pour le message de renouvellement de clé multicast sont correctement configurés pour vous assurer que des clés valides sont disponibles pour chiffrer le trafic entre les membres du groupe.

Action

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

Exemple : Configuration de groupe VPNv1 avec colocalisation serveur-membre

Cet exemple montre comment configurer un périphérique pour le mode de colocalisation, qui permet aux fonctions serveur et membre de coexister sur le même périphérique physique. Group VPNv1 est pris en charge sur les équipements SRX100, SRX110, SRX210, SRX220, SRX240 et SRX650.

Conditions préalables

Avant de commencer :

Présentation

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

Dans Figure 3, un VPN de groupe (l’identificateur 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 bouclage est 20.0.0.1). Notez que member1 coexiste sur le même périphérique 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 serveur-membreExemple de colocation serveur-membre

Les instructions de configuration de cette rubrique décrivent comment configurer le périphérique de groupe server-member1 pour le mode de colocation. Pour configurer member2, reportez-vous à l’exemple : Configuration du serveur VPNv1 de groupe et de ses membres.

Pour éviter les problèmes de fragmentation des paquets, nous recommandons que l’interface utilisée par le membre du groupe pour se connecter au réseau MPLS soit configurée pour une taille de MTU ne dépassant pas 1400 octets. Utilisez l’instruction de set interface mtu configuration pour définir la taille de la MTU.

Configuration

Procédure

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.

Pour configurer un VPN de groupe avec colocalisation entre les membres du serveur :

  1. Configurez l’adresse de bouclage sur l’appareil.

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

  3. Configurez la colocalisation VPN de groupe sur l’appareil.

  4. Configurez l’IKE Phase 1 SA pour le serveur (cette configuration doit correspondre à la Phase 1 SA configurée 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’identificateur de groupe, la passerelle IKE, l’heure de l’anti-relecture et l’adresse du serveur sur le serveur.

  8. Configurez les communications entre le serveur et les membres.

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

  10. Configurez l’AS de phase 1 pour le membre1 (cette configuration doit correspondre à l’AS de phase 1 configurée pour le serveur de groupe).

  11. Définissez la stratégie et définissez la passerelle distante pour member1.

  12. Configurez l’identificateur de groupe, la passerelle IKE et l’interface pour member1.

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

  14. Configurez une stratégie d’étendue de la zone de confiance à la zone non approuvée qui autorise le trafic unicast à destination et en provenance du sous-réseau 10.0.0.0/8.

  15. Configurez une stratégie d’étendue de la zone d’approbation à la zone d’approbation qui autorise le trafic unicast à destination et en provenance 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 and show security policies . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration de 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é de configurer l’appareil, passez commit en mode de configuration.

Vérification

Pour vérifier que la configuration fonctionne correctement, effectuez les opérations suivantes :

Vérification de l’inscription d’un membre VPN de groupe

But

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

Action

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

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

But

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

Action

À partir du mode opérationnel, entrez 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érifiez les SA du serveur VPN de groupe pour IPsec.

Action

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

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

But

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

Action

À partir du mode opérationnel, entrez 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érifiez les SA des membres VPN du groupe pour IPsec.

Action

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

Tableau de l'historique des modifications

La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l' Feature Explorer pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.

Version
Description
12.3X48-D30
À partir de Junos OS version 12.3X48-D30, les membres du groupe VPNv1 peuvent interagir avec les serveurs VPNv2 du groupe.
12.3X48-D30
À partir de la version 12.3X48-D30 de Junos OS, les membres du groupe VPNv1 sur les équipements SRX100, SRX110, SRX210, SRX220, SRX240, SRX550 et SRX650 peuvent interagir avec les serveurs VPNv2 du groupe.