Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

VPNv1 de groupe

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 ou transite par un équipement.

Présentation du VPNv1 du 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 de 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é. Le VPNv1 de groupe étend l’architecture IPsec pour prendre en charge les systèmes de sécurité partagés par un groupe d’équipements de sécurité (voir Figure 1).

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

Le VPNv1 de groupe est pris en charge sur les équipements SRX100, SRX110, SRX210, SRX220, SRX240 et SRX650. Avec le VPNv1 de groupe, la connectivité any-to-any est atteinte en conservant 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 la version 12.3X48-D30 de Junos OS, les membres VPNv1 du groupe peuvent interagir avec les serveurs VPNv2 du groupe.

Le VPNv1 du groupe a certaines limitations de propriété concernant la RFC 6407, Le domaine d’interprétation du groupe (GDOI). Pour utiliser un VPN de groupe sans limitations propriétaires, passez à VPNv2 de groupe. VpNv2 de groupe est pris en charge sur les instances vSRX à partir de Junos OS version 15.1X49-D30, les équipements SRX Series à partir de la version 15.1X49-D40 de Junos OS et les équipements MX Series à partir de Junos OS version 15.1r2.

Comprendre le protocole GDOI pour VPNv1 de groupe

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

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

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 re-clé unique qui permet au serveur d’envoyer des sas et des clés de groupe aux membres avant l’expiration des sas de groupe existants. Les messages de re-clé sont des messages non sollicités envoyés par le serveur aux membres.

Comprendre les limites du VPNv1 du groupe

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

  • Instances de routage non par défaut

  • Cluster de châssis

  • Clusters de serveurs

  • VPN de groupe basé sur le routage

  • Déploiement basé sur l’Internet public

  • SNMP

  • Politique de refus du serveur VPN Cisco GET

  • Interface J-Web pour la configuration et la surveillance

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

  • VpNv2 de groupe prend en charge le protocole de détection des retards de livraison IP de l’IETF pour un mécanisme antireplay basé sur le temps. Par conséquent, l’antireplay basé sur le protocole de détection des retards de livraison IP n’est pas pris en charge sur les membres VPNv1 du groupe et doit être désactivé sur le serveur VPNv2 du groupe avec 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, lorsque le serveur du groupe et les fonctions membres du groupe existent dans le même équipement.

  • Le serveur VPNv2 du groupe ne prend pas en charge les transmissions de battements cardiaques. Les battements cardiaques doivent être désactivés sur le membre VPNv1 du groupe avec la deactivate security group-vpn member ipsec vpn vpn-name heartbeat-threshold commande. Nous vous recommandons d’utiliser les clusters de serveurs VPNv2 du groupe pour éviter tout impact sur le trafic en raison de redémarrages ou d’autres interruptions sur le serveur VPNv2 du groupe.

  • Les messages Groupkey-push envoyés depuis le serveur VPNv2 du groupe sont basés sur la RFC 6407, Le domaine d’interprétation du groupe (GDOI) et ne sont pas pris en charge sur les membres VPNv1 du groupe. Par conséquent, les messages groupkey-push doivent être désactivés sur le serveur VPNv2 du groupe avec la deactivate security group-vpn server group group-name server-member-communication commande.

    Les rekeys sont prises en charge par des messages groupkey-pull. S’il y a des problèmes d’évolutivité où les membres du groupe VPNv1 ne peuvent pas terminer l’opération groupkey-pull avant l’expiration de la durée de vie difficile du TEK, nous vous recommandons d’augmenter la durée de vie du TEK afin de laisser suffisamment de temps aux membres pour terminer l’opération groupkey-pull. Les chiffres d’évolutivité de Juniper sont qualifiés avec une durée de vie TEK de 2 heures.

  • Si le serveur VPNv2 du groupe est redémarré ou mis à niveau, ou si les SAs du groupe sont autorisés, de nouveaux membres ne peuvent pas être ajoutés au réseau tant que la prochaine re-clé n’a pas lieu pour les membres existants. Les nouveaux membres ne peuvent pas envoyer de trafic aux membres existants qui possèdent d’anciennes clés. Pour contourner les problèmes, effacez les SA sur les membres VPNv1 de groupe existants avec 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 VPNv2 du groupe, le trafic de données multicast ne peut pas être utilisé lorsque des membres VPNv1 et VPNv2 de groupe coexistent dans le réseau pour le même groupe.

Comprendre les serveurs et les membres VPNv1 du 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 aux groupes

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

  • Gère les SAs et les clés de groupe et les distribue aux membres du groupe

Les membres du groupe chiffrent le trafic en fonction des SAs et des clés du groupe fournis 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 nombre compris entre 1 et 65 535. L’identifiant du groupe relie le serveur et les membres du groupe. Il ne peut y avoir qu’un seul identifiant de groupe par groupe, et plusieurs groupes ne peuvent pas utiliser le même identifiant de groupe.

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

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

  2. Une fois l’authentification et l’enregistrement réussis, l’équipement membre récupère les SAs et les clés du groupe sur le serveur à l’aide d’un échange GDOI groupkey-pull .

  3. Le serveur ajoute le membre à l’appartenance du 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 de mise à jour des clés aux membres du groupe avec des messages de rekey (GDOI groupkey-push). Les messages de re-clé sont envoyés avant l’expiration des SAs ; cela garantit que des clés valides sont disponibles pour chiffrer le trafic entre les membres du groupe.

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

Comprendre la communication serveur-membre VPNv1 du groupe

Le VPNv1 de groupe 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 re-clé aux membres.

La communication serveur-membre est configurée pour le groupe à l’aide de server-member-communication l’instruction de configuration au niveau de 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 sur le serveur. Il n’y a pas d’algorithme par défaut.

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

  • Intervalle auquel le serveur envoie des messages de battements de cœur au membre du groupe. Cela permet au membre de déterminer si le serveur a redémarré, ce qui l’obligerait à 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 (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 re-clé aux membres, mais il peut y avoir des situations dans lesquelles ce comportement n’est pas souhaité. Par exemple, si les membres du groupe sont des pairs dynamiques (comme dans un bureau à domicile), les équipements ne sont pas toujours connectés et l’adresse IP d’un équipement peut être différente à chaque fois qu’il est allumé. La configuration de la communication serveur-membre pour un groupe de pairs dynamiques peut entraîner des transmissions inutiles par le serveur. Si vous souhaitez que la négociation sa de phase 1 d’IKE soit toujours effectuée pour protéger les négociations sur les GDOI, ne configurez pas la communication serveur-membre.

Si la communication serveur-membre d’un groupe n’est pas configurée, la liste d’appartenances affichée par la commande affiche les show security group-vpn server registered-members membres du groupe qui se sont inscrits sur le 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 bloquée. Si le type de communication est configuré en unicast, la commande affiche uniquement les show security group-vpn server registered-members membres actifs. Si le type de communication est configuré en tant que multicast, la commande affiche les show security group-vpn server registered-members membres qui se sont enregistrés auprès du serveur après la configuration ; la liste d’appartenances ne représente pas nécessairement les membres actifs, car les membres peuvent abandonner après l’inscription.

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. Le serveur télécharge deux types de clés de groupe pour les membres :

  • Clé de chiffrement (KEK) : utilisée pour chiffrer les messages de re-clé. 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 s’il existe une stratégie de portée correspondante configurée sur le membre. Une clé acceptée est installée pour le VPN de groupe, tandis qu’une clé rejetée est rejetée.

Messages de re-clé

Si le groupe est configuré pour les communications serveur-membre, le serveur envoie périodiquement des messages sa et de mise à jour des clés aux membres du groupe avec des messages de rekey (GDOI groupkey-push). Les messages de re-clé sont envoyés avant l’expiration des SAs ; cela garantit que des clés valides sont disponibles pour chiffrer le trafic entre les membres du groupe.

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

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

Il existe deux types de messages de re-clé :

  • Messages de rekey unicast : le serveur de groupe envoie une copie du message de re-clé à chaque membre du groupe. Dès réception du message de re-clé, les membres doivent envoyer un accusé de réception (ACK) au serveur. Si le serveur ne reçoit pas d’ACK d’un membre (y compris la retransmission de messages de re-clé), le serveur considère le membre inactif et le retire de la liste d’adhésion. Le serveur cesse d’envoyer des messages de re-clé au membre.

    Les number-of-retransmission déclarations et retransmission-period les instructions de configuration des communications serveur-membre contrôlent l’envoi de messages de re-clé par le serveur lorsqu’aucun ACK n’est reçu d’un membre.

  • Messages de rekey multicast : le serveur de groupe envoie une copie du message de 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 de re-clé multicast. La liste des membres enregistrés ne représente pas nécessairement les membres actifs, car les membres peuvent abandonner après leur 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 les équipements Juniper Networks, consultez le Guide de l’utilisateur des protocoles multicast .

L’intervalle auquel le serveur envoie des messages de re-clé est calculé en fonction des valeurs de la lifetime-seconds hiérarchie et activation-time-delay des déclarations de configuration au niveau de la hiérarchie [edit security group-vpn server group]. L’intervalle est calculé en tant que lifetime-seconds minus 4*(activation-time-delay).

Le lifetime-seconds kek est configuré dans le cadre des communications serveur-membre ; la valeur par défaut est de 3 600 secondes. Le lifetime-seconds tek est configuré pour la proposition IPsec ; la valeur par défaut est de 3 600 secondes. La activation-time-delay est configurée 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 re-clé est 3600 minus 4*15, 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, il doit se réinscrire auprès du serveur et obtenir des clés mises à jour avec un échange GDOI groupkey-pull . Dans ce cas, l’intervalle auquel le serveur envoie des messages de re-clé 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 re-clé est de 3600 moins 3*15, ou 3 555 secondes.

La réinscription des membres peut avoir lieu pour les raisons suivantes :

  • Le membre détecte un redémarrage du serveur par l’absence de battements de cœur reçus du serveur.

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

Activation de clé

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

Si la clé est reçue par le biais d’un message de re-clé 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 de la réinscription du 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 groupe 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 retirée du nombre de secondes spécifié par la activation-time-delay valeur après l’activation de la nouvelle clé.

L’instruction de activation-time-delay configuration par défaut est de 15 secondes. Le fait de définir cette période trop petite peut entraîner la perte d’un paquet au niveau d’un membre du groupe distant avant l’installation de la nouvelle clé. Prenez en compte la topologie du réseau et les retards 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 (TEKs) à un membre VPNv1 du groupe en réponse à une groupkey-pull demande. Les éléments suivants décrivent comment le membre VPNv1 du groupe gère les TEK existants et les TEKs qu’il reçoit du serveur :

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

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

Le membre du groupe VPNv1 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.

Messages de compréhension du groupe VPNv1 Heartbeat

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 battements de cœur permet aux membres de se réinscrire auprès du serveur si le nombre spécifié de battements de cœur n’est pas reçu. Par exemple, les membres ne recevront pas de messages de battements de cœur lors d’un redémarrage du serveur. Lorsque le serveur a redémarré, les membres se réenregistrent auprès du serveur.

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

Les messages de battement de cœur contiennent les informations suivantes :

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

  • Temps relatif, si l’antireplay est activé

En comparant les informations des battements de cœur, un membre peut détecter s’il a manqué des informations sur le serveur ou s’il a re-clé des messages. Le membre se réinscrit pour se synchroniser avec le serveur.

Les messages de battement de cœur peuvent augmenter la congestion du réseau et entraîner des réinscriptions inutiles des membres. Ainsi, la détection des battements cardiaques peut être désactivée sur le membre si nécessaire.

Comprendre le mode de colocation serveur-membre VPNv1 du groupe

Les fonctions du serveur de groupe et des membres du groupe sont distinctes et ne se chevauchent pas. Les fonctions serveur et membres peuvent coexister dans le même équipement physique, appelé 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 correctement distribués. En mode colocation, il ne peut y avoir qu’une seule adresse IP attribuée au serveur et une adresse IP attribuée au membre à travers les groupes.

Présentation de la configuration VPNv1 du groupe

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 de la phase 1 de l’IKE. Utilisez la hiérarchie [edit security group-vpn server ike] pour configurer la phase 1 SA de l’IKE. Voir comprendre la configuration de phase 1 de l’IKE pour vpnv2 de groupe .
  2. Phase 2 IPsec SA. Voir Comprendre la configuration IPsec SA pour le VPNv1 de groupe.
  3. Groupe VPN. Voir la présentation de la configuration VPNv1 du groupe.

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

  1. Négociation de la phase 1 de l’IKE. Utilisez la hiérarchie [edit security group-vpn member ike] pour configurer IKE Phase 1 SA. Voir comprendre la configuration de la phase 1 de l’IKE pour vpnv1 de groupe .

  2. Phase 2 IPsec SA. Voir Comprendre la configuration IPsec SA pour le VPNv1 de groupe.

  3. Stratégie d’étendue qui détermine les stratégies de groupe installées sur le membre. Voir Comprendre les stratégies dynamiques pour vpnv1 de groupe.

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 maximale d’unité de transmission (MTU) ne dépassant pas 1 400 octets. Utilisez l’énoncé set interface mtu de configuration pour définir la taille du 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 sur le groupe se composent des informations suivantes :

  • Identifiant de groupe : valeur comprise 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 la clé automatique IKE.

  • Membres du groupe, comme configuré avec l’instruction de ike-gateway configuration. Il peut y avoir plusieurs instances de cette déclaration de configuration, une pour chaque membre du groupe.

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

  • Stratégies de groupe : stratégies à télécharger sur les membres. Les stratégies de groupe décrivent le trafic auquel le SA et les clés s’appliquent. Voir Comprendre les stratégies dynamiques pour vpnv1 de groupe.

  • Communication serveur-membre : configuration facultative qui permet au serveur d’envoyer des messages de re-clé aux membres. Voir la présentation du VPNv1 du groupe.

  • Antireplay : configuration en option qui détecte l’interception et la relecture des paquets. Voir Comprendre l’antireplay pour le VPNv1 de groupe.

Comprendre la configuration de la phase 1 de l’IKE pour vpnv1 de groupe

Un SA de phase 1 IKE entre le serveur du groupe et un membre du groupe établit un canal sécurisé dans lequel négocier des ACCORDS IPsec partagés par un groupe. Pour les VPN IPsec standard sur les équipements de sécurité Juniper Networks, la configuration sa de phase 1 consiste à spécifier une proposition d’IKE, une stratégie et une passerelle. Pour les VPNv1 de groupe, la configuration SA de phase 1 de l’IKE est similaire à celle des VPN IPsec standard, mais elle est exécutée dans 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é à 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.

Le VPNv2 de groupe ne prenant en charge que des algorithmes forts, l’option sha-256 d’algorithme d’authentification est prise en charge pour les membres VPNv1 du groupe sur les équipements SRX100, SRX110, SRX210, SRX220, SRX240, SRX550 et SRX650. Lorsque les membres VPNv1 du groupe interagissent avec les serveurs VPNv2 du groupe, cette option doit être configurée sur les membres vpnv1 du groupe avec 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 pour les propositions IPsec.

Si une passerelle IKE sur un membre du groupe VPNv1 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 de phase 1 de l’IKE sur le serveur de groupe doit correspondre à la configuration de phase 1 de l’IKE sur les membres du groupe.

Comprendre la configuration IPsec SA pour vpnv1 de groupe

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

La configuration IPsec de phase 2 pour le groupe VPNv1 comprend les informations suivantes :

  • Proposition de protocole de sécurité, d’authentification et d’algorithme de chiffrement à utiliser pour le SA. La proposition SA IPsec est configurée sur le serveur de groupe avec proposal l’énoncé 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 le SA et les clés s’appliquent. La stratégie de groupe est configurée sur le serveur avec l’instruction de ipsec-sa configuration dans la hiérarchie [edit security group-vpn server group ] .

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

Comprendre les stratégies dynamiques pour VPNv1 de groupe

Le serveur de groupe distribue les SAs 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. Mais 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 chaque clé que le serveur pousse à un membre est associé à 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 adresses source, adresse de destination, port source, port de destination et 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 c’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 qui définit l’étendue de la stratégie de groupe téléchargée depuis le serveur. Une stratégie de groupe distribuée à partir du serveur est comparée aux stratégies de portée configurées sur le membre. Pour qu’une stratégie de groupe soit 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 situer dans la plage d’adresses spécifiée dans la stratégie de portée.

  • 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 est appelée stratégie dynamique.

Une stratégie d’étendue peut faire partie d’une liste ordonnée de stratégies de sécurité pour un contexte spécifique de la zone et de la zone à la zone. 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.

Selon la position de la stratégie de portée dans la liste ordonnée des stratégies de sécurité, il existe plusieurs possibilités de recherche dynamique des stratégies :

  • Si le paquet entrant correspond à une stratégie de sécurité avant qu’elle ne soit prise en compte, la recherche dynamique de stratégie n’a pas lieu.

  • Si une stratégie entrante correspond à une stratégie de portée, le processus de recherche se poursuit pour obtenir une stratégie dynamique correspondante. S’il existe une stratégie dynamique correspondante, cette action (autoriser) est effectuée. S’il n’y a pas de politique dynamique correspondante, le processus de recherche continue de rechercher les stratégies en-dessous de la stratégie de portée.

    Dans cette version, seule l’action tunnel est autorisée pour une stratégie de portée. 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 au niveau de la hiérarchie [edit security] . Utilisez l’instruction ipsec-group-vpn de configuration dans la règle de tunnel d’autorisation pour référencer le VPN de groupe, ce qui permet aux membres du groupe de partager un seul SA.

Comprendre l’antireplay pour vpnv1 de groupe

L’antireplay est une fonctionnalité IPsec capable de détecter lorsqu’un paquet est intercepté puis rejoué par les attaquants. 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’instruction de configuration.

Lorsque l’antireplay est activé, le serveur de groupe synchronise le temps 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 et des membres VPNv1 de groupe

Cet exemple montre comment configurer vpnv1 de groupe pour étendre l’architecture IPsec afin de prendre en charge les systèmes de sécurité partagés par un groupe d’équipements de sécurité. Le VPNv1 de groupe 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 équipements membres (membre1 et membre2) et d’un serveur de groupe (l’adresse IP de l’interface de bouclage sur le serveur est 20.0.0.1). L’identifiant du groupe est 1.

Figure 2 : Exemple de configuration serveur-membreExemple de configuration serveur-membre

Les SAs VPN de groupe de phase 2 doivent être protégés par un SA de phase 1. Par conséquent, la configuration VPN de groupe doit inclure la configuration des négociations de phase 1 IKE 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 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 sur 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 vers 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 : permet le trafic multicast à partir de 10.1.1.1/32

L’équipement membre1 est configuré avec des stratégies d’étendue qui autorisent tout le trafic unicast vers et depuis le sous-réseau 10.0.0/8. Aucune stratégie de portée n’est configurée sur le membre1 pour autoriser le trafic multicast ; par conséquent, la stratégie SA p3 n’est pas installée sur le membre1.

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

Configuration

Configuration du serveur de groupe

Configuration rapide cli

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

Procédure étape par étape

Dans l’exemple suivant, vous devez parcourir différents niveaux de la hiérarchie de configuration. Pour obtenir des instructions sur la façon d’y parvenir, consultez Utilisation de l’éditeur cli en mode de configuration.

Pour configurer le serveur de groupe :

  1. Configurez l’adresse de bouclage sur l’équipement.

  2. Configurez 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’identifiant 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 fini de configurer l’équipement, saisissez commit à partir du mode de configuration.

Configuration du membre1

Configuration rapide cli

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

Procédure étape par étape

Dans l’exemple suivant, vous devez parcourir différents niveaux de la hiérarchie de configuration. Pour obtenir des instructions sur la façon d’y parvenir, consultez Utilisation de l’éditeur cli en mode de configuration.

Pour configurer le membre1 :

  1. Configurez la phase 1 SA (cette configuration doit correspondre à la 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’identifiant de groupe, la passerelle IKE et l’interface pour le membre1.

    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 MTU ne dépassant pas 1 400 octets. Utilisez l’énoncé set interface mtu de configuration pour définir la taille du MTU.

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

  5. Configurez une stratégie de portée de la zone d’approbation à la zone de non confiance qui autorise le trafic unicast vers et depuis le sous-réseau 10.0.0/8.

  6. Configurez une stratégie de portée de la zone de non confiance à la zone de confiance qui autorise le trafic unicast vers et depuis le sous-réseau 10.0.0/8.

Résultats

À partir du mode de configuration, confirmez votre configuration en entrant les show security group-vpn member commandes 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 fini de configurer l’équipement, saisissez commit à partir du mode de configuration.

Configuration des membres2

Configuration rapide cli

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

Procédure étape par étape

Dans l’exemple suivant, vous devez parcourir différents niveaux de la hiérarchie de configuration. Pour obtenir des instructions sur la façon d’y parvenir, consultez Utilisation de l’éditeur cli en mode de configuration.

Pour configurer le membre2 :

  1. Configurez la phase 1 SA (cette configuration doit correspondre à la sa de phase 1 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 passerelle IKE et l’interface pour les membres2.

    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 MTU ne dépassant pas 1 400 octets. Utilisez l’énoncé set interface mtu de configuration pour définir la taille du MTU.

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

  5. Créez un autre carnet d’adresses et attachez-le à la zone de non confiance.

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

  7. Configurez une stratégie de portée de la zone de non confiance à 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 les show security group-vpn member commandes 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 fini de configurer l’équipement, saisissez commit à partir du mode de configuration.

Vérification

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

Vérification des stratégies dynamiques pour les membres1

But

Consultez les stratégies dynamiques installées sur le membre1.

Action

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

Sens

La stratégie multicast p3 du serveur n’est pas installée sur le membre1, car aucune stratégie de portée n’est configurée sur le membre1 qui autorise le trafic multicast.

Vérification des stratégies dynamiques pour les membres2

But

Consultez 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 vers le membre2, saisissez 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) à partir du serveur n’est pas installée sur le membre2, car elle correspond à la stratégie de sécurité refus2 configurée sur le membre2.

Exemple : Configuration de la communication VPNv1 serveur-membre du groupe pour les messages de rekey unicast

Cet exemple montre comment permettre au serveur d’envoyer des messages de re-clé unicast aux membres du groupe pour s’assurer que des clés valides sont disponibles pour chiffrer le trafic entre les membres du groupe. Le VPNv1 de groupe 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 de phase 1 de l’IKE.

  • Configurez le serveur et les membres du groupe 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 serveur-membre suivants pour le groupe g1:

  • Le serveur envoie des messages de rekey 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 battements de cœur du serveur, la durée de vie de KEK et les retransmissions.

Configuration

Procédure

Procédure étape par étape

Dans l’exemple suivant, vous devez parcourir différents niveaux de la hiérarchie de configuration. Pour obtenir des instructions sur la façon d’y parvenir, consultez Utilisation de l’éditeur cli en mode de configuration.

Pour configurer la communication serveur-membre :

  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 de la communication VPNv1 serveur-membre du groupe pour les messages de re-clé multicast

Cet exemple montre comment permettre au serveur d’envoyer des messages de re-clé multicast aux membres du groupe pour s’assurer que des clés valides sont disponibles pour chiffrer le trafic entre les membres du groupe. Le VPNv1 de groupe 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 de groupe g1suivante :

  • Le serveur envoie des messages de rekey 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 battements de cœur du serveur, la durée de vie de KEK et les retransmissions.

Configuration

Procédure

Configuration rapide cli

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

Procédure étape par étape

Dans l’exemple suivant, vous devez parcourir différents niveaux de la hiérarchie de configuration. Pour obtenir des instructions sur la façon d’y parvenir, consultez Utilisation de l’éditeur cli en mode de configuration.

Pour configurer la communication serveur-membre pour les messages de re-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 fini de configurer l’équipement, saisissez commit à partir du mode de configuration.

Vérification

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

Vérification de la communication serveur-membre pour les messages de re-clé multicast

But

Vérifiez que les paramètres de communication des membres du serveur pour le message de re-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

Depuis le mode opérationnel, saisissez la show security group-vpn server group g1 server-member-communication commande.

Exemple : Configuration du VPNv1 de groupe avec colocation serveur-membre

Cet exemple montre comment configurer un équipement pour le mode de colocation, ce qui permet aux fonctions serveur et membres de coexister sur le même équipement physique. Le VPNv1 de groupe 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 colocation est configuré, les fonctions du serveur de groupe et des membres du 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 correctement distribués.

Dans Figure 3, 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 bouclage est 20.0.0.1). Notez que le membre1 coexiste dans le même équipement que le serveur de groupe. Dans cet exemple, l’interface que le membre1 utilise pour se connecter au réseau MPLS (ge-0/1/0) reçoit 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 l’équipement serveur-membre1 du groupe pour le mode de colocation. Pour configurer le membre2, consultez l’exemple : Configuration du serveur et des membres VPNv1 de groupe.

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 MTU ne dépassant pas 1 400 octets. Utilisez l’énoncé set interface mtu de configuration pour définir la taille du MTU.

Configuration

Procédure

Configuration rapide cli

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

Procédure étape par étape

Dans l’exemple suivant, vous devez parcourir différents niveaux de la hiérarchie de configuration. Pour obtenir des instructions sur la façon d’y parvenir, consultez Utilisation de l’éditeur cli en mode de configuration.

Pour configurer un VPN de groupe avec la colocation serveur-membre :

  1. Configurez l’adresse de bouclage sur l’équipement.

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

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

  4. Configurez 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’identifiant de groupe, la passerelle IKE, le temps d’anti-diffusion et l’adresse du serveur sur le serveur.

  8. Configurez les communications du serveur aux membres.

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

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

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

  12. Configurez l’identifiant de groupe, la passerelle IKE et l’interface pour le membre1.

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

  14. Configurez une stratégie de portée de la zone d’approbation à la zone de non confiance qui autorise le trafic unicast vers et depuis le sous-réseau 10.0.0/8.

  15. Configurez une stratégie de portée de la zone de non confiance à la zone de confiance qui autorise le trafic unicast vers et depuis le sous-réseau 10.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 de portée sont répertoriées avant les stratégies par défaut.

Si vous avez fini de configurer l’équipement, saisissez commit à partir du mode de configuration.

Vérification

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

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

But

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

Action

Depuis le mode opérationnel, saisissez la show security group-vpn registered-members commande.

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

But

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

Action

Depuis le mode opérationnel, saisissez la show security group-vpn server ike security-associations commande.

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

But

Vérifiez les SLA du serveur VPN de groupe pour IPsec.

Action

Depuis le 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 IKE

But

Vérifiez les SAs des membres VPN du groupe pour IKE.

Action

Depuis le 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érifiez les SAs des membres VPN du groupe pour IPsec.

Action

Depuis le 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
À partir de la version 12.3X48-D30 de Junos OS, les membres VPNv1 du groupe peuvent interagir avec les serveurs VPNv2 du groupe.
12.3X48-D30
À partir de la version Junos OS 12.3X48-D30, les membres du groupe VPNv1 sur SRX100, SRX110, SRX210, SRX220, SRX240, SRX550 et les équipements SRX650 peuvent interagir avec les serveurs VPNv2 du groupe.