VPN IPv6 IPsec
Juniper Networks prend en charge les configurations IKE manuelles et automatiques avec des clés prépartagées pour le VPN IPv6 IPsec.
Prise en charge de la fonctionnalité VPN pour les adresses IPv6
Un tunnel VPN de site à site basé sur le routage avec une interface de tunnel sécurisée point à point peut fonctionner en mode tunnel IPv4-en-IPv4, IPv6-en-IPv6, IPv6-en-IPv4 ou IPv4-en-IPv6. Les adresses IPv6 peuvent se trouver dans l’en-tête IP externe, qui représente le point de terminaison du tunnel, ou dans l’en-tête IP interne, qui représente les adresses source et de destination finales d’un paquet.
Tableau 1 définit la prise en charge des adresses IPv6 dans les fonctionnalités VPN.
Fonctionnalité |
Mise en place |
Exceptions |
|---|---|---|
Prise en charge d’IKE et d’IPsec : |
||
IKEv1 et IKEv2 |
Oui |
Sauf indication contraire, toutes les fonctionnalités prises en charge s’appliquent à IKEv1 et IKEv2. |
VPN basé sur le routage |
Oui |
– |
VPN basé sur les stratégies |
Oui |
Les VPN basés sur des stratégies IPv6 ne sont pas pris en charge sur les pare-feu SRX Series dans les configurations de cluster en châssis. Les VPN basés sur des stratégies IPv6 ne sont pris en charge qu’avec des tunnels IPv6 sur les équipements autonomes SRX300, SRX320, SRX340, SRX345 et SRX550HM. |
VPN de site à site |
Oui |
Seul le VPN un-à-un et de site à site est pris en charge. Le VPN de site à site plusieurs-à-un (NHTB) n’est pas pris en charge. La configuration NHTB ne peut pas être validée pour les modes de tunnel autres que les tunnels IPv4-dans-IPv4. |
VPN de point de terminaison dynamique |
Oui |
– |
VPN commuté par ligne commutée |
Oui |
– |
AutoVPN |
Oui |
Les réseaux AutoVPN qui utilisent des interfaces de tunnel sécurisées en mode point à point prennent en charge les adresses IPv6 pour les sélecteurs de trafic et pour les homologues IKE. AutoVPN en mode point à multipoint ne prend pas en charge le trafic IPv6. |
VPN de groupe |
Non |
– |
Interfaces de tunnel point à point |
Oui |
– |
Interfaces de tunnel point à multipoint |
Non |
– |
Scénario en étoile pour les VPN de site à site |
Oui |
– |
Interfaces de tunnel numérotées et non numérotées |
Oui |
– |
Routage statique et dynamique unicast (RIP, OSPF, BGP) |
Oui |
– |
Routage dynamique multicast (PIM) |
Non |
– |
Routeur virtuel |
Oui |
– |
Système logique |
Non |
– |
Gestion automatique et manuelle des SA et des clés |
Oui |
– |
Plusieurs SPU |
Oui |
– |
Cluster de châssis |
Oui |
Le VPN IPsec en mode actif-actif est uniquement pris en charge sur les appareils SRX300, SRX320, SRX340, SRX345 et SRX550HM pour les tunnels IPv6 basés sur le routage. Le VPN IPsec en mode actif-actif n’est pas pris en charge sur les appareils SRX5400, SRX5600 et SRX5800. |
Statistiques, journaux, débogage par tunnel |
Oui |
– |
SNMP MIB |
Oui |
– |
Sélection de l’adresse locale |
Oui |
Lorsque plusieurs adresses de la même famille d’adresses sont configurées sur une interface externe physique vers un homologue VPN, nous vous recommandons également de configurer |
Terminaison de l’adresse de bouclage |
Oui |
– |
Xauth ou modecfg sur IPv6 |
Non |
– |
Plaquette SPC |
Oui |
– |
ISSU |
Oui |
– |
Nom DNS en tant qu’adresse de passerelle IKE |
Oui |
Comme pour les tunnels IPv4, les modifications de l’adresse de la passerelle homologue dans le nom DNS ne sont pas prises en charge avec les tunnels IPv6. |
Authentification par clé ou certificat pré-partagée |
Oui |
– |
NAT-Traversal (NAT-T) pour les homologues IKE IPv4 |
Oui |
NAT-T est pris en charge uniquement pour les modes tunnel IPv6-en-IPv4 et IPv4-en-IPv4 avec IKEv1. Les modes tunnel IPv6-en-IPv6 et IPv4-en-IPv6 ne sont pas pris en charge. IKEv2 n’est pas pris en charge pour NAT-T. NAT-T d’IPv6 à IPv4 ou d’IPv4 à IPv6 n’est pas pris en charge. |
Dead Peer Detection (DPD) et basculement de passerelle DPD |
Oui |
Le basculement de passerelle DPD n’est pris en charge que pour différentes adresses de passerelles au sein d’une même famille. Le basculement d’une adresse de passerelle IPv6 vers une adresse de passerelle IPv4, ou vice versa, n’est pas pris en charge. |
Jeux de chiffrement, algorithmes d’authentification et groupes DH pris en charge dans la version 12.1X45-D10 de Junos OS pour les pare-feu SRX Series. |
Oui |
– |
Propositions et politiques génériques pour IPv6 et IPv4 |
Oui |
– |
ID IKE général |
Oui |
– |
Modes de transport ESP et AH |
Non |
Ces modes ne sont pas pris en charge pour IPv4. |
Modes tunnel ESP et AH |
Oui |
Le mode tunnel AH avec des en-têtes et des options d’extension modifiables n’est pas pris en charge. |
Numéro de séquence étendu |
Non |
– |
Paires d’ID de proxy uniques |
Oui |
– |
Plusieurs paires de sélecteurs de trafic |
Oui |
Pris en charge avec IKEv1 uniquement. |
Durée de vie d’IKE ou d’IPsec SA, en secondes |
Oui |
– |
Durée de vie d’IKE SA, en kilo-octets |
Oui |
– |
Surveillance VPN |
Non |
La configuration avec des tunnels IPv6 ne peut pas être validée. |
Embout DF |
Oui |
Pour les tunnels IPv6-en-IPv6, le bit DF n’est défini que s’il est configuré au niveau |
Double pile (tunnels IPv4 et IPv6 parallèles) sur une seule interface physique |
Oui |
Pour les VPN de site à site basés sur le routage. Un seul tunnel IPv4 peut fonctionner à la fois en mode tunnel IPv4-en-IPv4 et IPv6-en-IPv4, et un seul tunnel IPv6 peut fonctionner en mode tunnel IPv4-en-IPv6 et IPv6-in-IPv6. |
En-têtes d’extension IPv6 |
Oui |
Les en-têtes d’extension IPv6 et les options IPv4 pour les paquets IKE et IPsec sont acceptés mais ne sont pas traités. AH avec des EH et des options mutables n’est pas pris en charge. |
Fragmentation et réassemblage |
Oui |
– |
Affinité de session VPN |
Oui |
– |
Trafic multicast |
Non |
– |
Tunnel IP services (Screen, NAT, ALG, IPS, AppSecure) |
Oui |
– |
Réorganisation des paquets pour les fragments IPv6 sur le tunnel |
Non |
– |
BFD (Bidirectional Forwarding Detection) sur les routes OSPFv3 sur l’interface st0 |
Non |
– |
NDP (Neighbor Discovery Protocol) sur interfaces st0 |
Non |
– |
Prise en charge PKI : |
||
PKI dans le routeur virtuel |
Oui |
– |
Authentification de signature RSA (taille de clé 512, 1024, 2048 ou 4096 bits) |
Oui |
– |
Authentification de signature DSA (taille de clé de 1024, 2048 ou 4096 bits) |
Oui |
– |
Signatures de l’ECDSA |
Oui |
– |
Authentification de la chaîne de certificats |
Non |
– |
Enrôlement automatique ou manuel sur IPv4 |
Oui |
– |
Révocation automatique ou manuelle sur IPv4 |
Oui |
– |
Enrôlement automatique ou manuel sur IPv6 |
Non |
– |
Révocation automatique ou manuelle sur IPv6 |
Non |
– |
Adresses IPv6 dans les champs de certificat PKI |
Non |
– |
Voir également
Comprendre l’IKE IPv6 et le traitement IPsec des paquets
Cette rubrique comprend les sections suivantes :
Traitement des paquets IKE IPv6
Internet Key Exchange (IKE) fait partie de la suite de protocoles IPsec. Il permet automatiquement à deux points de terminaison de tunnel de configurer des associations de sécurité (SA) et de négocier des clés secrètes entre eux. Il n’est pas nécessaire de configurer manuellement les paramètres de sécurité. IKE fournit également une authentification pour les pairs communicants.
Le traitement des paquets IKE dans les réseaux IPv6 implique les éléments suivants :
Charge utile d’identification ISAKMP (Internet Security Association and Key Management Protocol)
La charge utile d’identification ISAKMP est utilisée pour identifier et authentifier les homologues IPv6 qui communiquent. Deux types d’ID (ID_IPV6_ADDR et ID_IPV6_ADDR_SUBNET) sont activés pour IPv6. Le type d’identification indique le type d’identification à utiliser. Le type ID_IPV6_ADDR spécifie une seule adresse IPv6 de 16 octets. Ce type d’ID représente une adresse IPv6. Le type ID_IPV6_ADDR_SUBNET spécifie une plage d’adresses IPv6 représentée par deux valeurs de 16 octets. Ce type d’ID représente un masque de réseau IPv6. Tableau 2 répertorie les types d’ID et les valeurs qui leur sont attribuées dans la charge utile d’identification.
Tableau 2 : Types d’ID ISAKMP et leurs valeurs Type d’ID
Valeur
RÉSERVÉS AU
0
ID_IPV4_ADDR
1
ID_FQDN
2
ID_USER_FQDN
3
ID_IPV4_ADDR_SUBNET
4
ID_IPV6_ADDR
5
ID_IPV6_ADDR_SUBNET
6
ID_IPV4_ADDR_RANGE
7
ID_IPV6_ADDR_RANGE
8
ID_DER_ASN1_DN
9
ID_DER_ASN1_GN
10
ID_KEY_ID
11
ID_LIST
12
Le type ID_IPV6_ADDR_RANGE spécifie une plage d’adresses IPv6 représentée par deux valeurs de 16 octets. La première valeur octet représente l’adresse IPv6 de départ et la deuxième valeur d’octet représente l’adresse IPv6 de fin dans la plage. Toutes les adresses IPv6 comprises entre la première et la dernière adresse IPv6 sont considérées comme faisant partie de la liste.
Deux types d’ID dans la charge utile d’identification ISAKMP (ID_IPV6_ADDR_RANGE et ID_IPV4_ADDR_RANGE) ne sont pas pris en charge dans cette version.
Proxy ID
Un ID de proxy est utilisé au cours de la phase 2 de la négociation IKE. Il est généré avant l’établissement d’un tunnel IPsec. Un ID de proxy identifie la SA à utiliser pour le VPN. Deux ID de proxy sont générés : local et distant. L’ID de proxy local fait référence à l’adresse/au réseau IPv4 ou IPv6 local et au masque de sous-réseau. L’ID de proxy distant fait référence à l’adresse/au réseau IPv4 ou IPv6 distant et au masque de sous-réseau.
Association de sécurité
Une SA est un accord entre les participants au VPN pour prendre en charge une communication sécurisée. Les SA sont différenciées en fonction de trois paramètres : l’indice des paramètres de sécurité (SPI), l’adresse IPv6 de destination et le protocole de sécurité (AH ou ESP). Le SPI est une valeur unique attribuée à une SA pour aider à identifier une SA parmi plusieurs SA. Dans un paquet IPv6, la SA est identifiée à partir de l’adresse de destination dans l’en-tête IPv6 externe et le protocole de sécurité est identifié à partir de l’en-tête AH ou ESP.
Traitement IPv6 IPsec des paquets
Une fois les négociations IKE terminées et les deux passerelles IKE ayant établi les SA de phase 1 et de phase 2, IPv6 IPsec utilise des technologies d’authentification et de chiffrement pour sécuriser les paquets IPv6. La longueur des adresses IPv6 est de 128 bits, alors que celle des adresses IPv4 est de 32 bits, le traitement des paquets IPv6 IPsec nécessite plus de ressources.
La réorganisation des paquets pour les fragments IPv6 sur un tunnel n’est pas prise en charge.
Les appareils dotés d’un adressage IPv6 n’effectuent pas de fragmentation. Les hôtes IPv6 doivent soit effectuer la découverte de MTU de chemin, soit envoyer des paquets inférieurs à la taille MTU minimale IPv6 de 1 280 octets.
Cette rubrique comprend les sections suivantes :
- Protocole AH en IPv6
- Protocole ESP en IPv6
- Options IPv4 et en-têtes d’extension IPv6 avec AH et ESP
- Calcul de la valeur de contrôle d’intégrité en IPv6
- Construction d’en-têtes en mode tunnel
Protocole AH en IPv6
Le protocole AH assure l’intégrité et l’authentification des données pour les paquets IPv6. IPv6 IPsec utilise des en-têtes d’extension (par exemple, saut par saut et options de routage) qui doivent être disposés d’une manière particulière dans le datagramme IPv6. En mode tunnel AH, l’en-tête AH suit immédiatement le nouvel en-tête IPv6 externe, similaire à celui du mode tunnel AH IPv4. Les en-têtes d’extension sont placés après l’en-tête intérieur d’origine. Par conséquent, en mode tunnel AH, l’ensemble du paquet est encapsulé en ajoutant un nouvel en-tête IPv6 externe, suivi d’un en-tête d’authentification, d’un en-tête interne, d’en-têtes d’extension et du reste du datagramme d’origine, comme indiqué à Figure 1la .
Contrairement à ESP, l’algorithme d’authentification AH couvre l’en-tête externe ainsi que tous les nouveaux en-têtes et options d’extension.
Le mode tunnel AH sur les pare-feu SRX Series ne prend pas en charge les options et les en-têtes d’extension compatibles IPv4. Reportez-vous à la section Tableau 3.
Protocole ESP en IPv6
Le protocole ESP assure à la fois le chiffrement et l’authentification des paquets IPv6. Étant donné qu’IPv6 IPsec utilise des en-têtes d’extension (par exemple, des options de routage et de saut par saut) dans le datagramme IPv6, la différence la plus importante entre le mode tunnel ESP IPv6 et le mode tunnel ESP IPv4 est le placement des en-têtes d’extension dans la disposition des paquets. En mode tunnel ESP, l’en-tête ESP suit immédiatement le nouvel en-tête IPv6 externe, similaire à celui du mode tunnel ESP IPv4. Par conséquent, en mode tunnel ESP, l’ensemble du paquet est encapsulé en ajoutant un nouvel en-tête IPv6 externe, suivi d’un en-tête ESP, d’un en-tête interne, d’en-têtes d’extension et du reste du datagramme d’origine, comme indiqué à la .Figure 2
Options IPv4 et en-têtes d’extension IPv6 avec AH et ESP
Les paquets IPsec avec options IPv4 ou en-têtes d’extension IPv6 peuvent être reçus pour décapsulation sur les pare-feu SRX Series. Tableau 3 affiche les options IPv4 ou les en-têtes d’extension IPv6 pris en charge avec le protocole ESP ou AH sur les pare-feu SRX Series. Si un paquet IPsec non pris en charge est reçu, le calcul ICV échoue et le paquet est abandonné.
Options ou en-têtes d’extension |
Appareils SRX300, SRX320, SRX340, SRX345 et SRX550HM |
Appareils SRX5400, SRX5600 et SRX5800 |
|---|---|---|
ESP avec options IPv4 |
Mise en place |
Mise en place |
ESP avec en-têtes d’extension IPv6 |
Mise en place |
Mise en place |
AH avec options immuables IPv4 |
Mise en place |
Mise en place |
AH avec en-têtes d’extension immuables IPv6 |
Mise en place |
Mise en place |
AH avec options mutables IPv4 |
Non pris en charge |
Non pris en charge |
AH avec en-têtes d’extension mutables IPv6 |
Non pris en charge |
Non pris en charge |
Calcul de la valeur de contrôle d’intégrité en IPv6
Le protocole AH vérifie l’intégrité du paquet IPv6 en calculant une valeur de contrôle d’intégrité (ICV) sur le contenu du paquet. ICV est généralement construit sur un algorithme d’authentification tel que MD5 ou SHA-1. Les calculs de l’ICV IPv6 diffèrent de ceux d’IPv4 en ce qui concerne deux champs d’en-tête : l’en-tête mutable et l’en-tête d’extension facultatif.
Vous pouvez calculer l’ICV AH sur les champs d’en-tête IPv6 qui sont soit immuables en transit, soit prévisibles en valeur à l’arrivée aux points de terminaison du tunnel. Vous pouvez également calculer l’ICV AH sur l’en-tête AH et les données de protocole de niveau supérieur (considérées comme immuables en transit). Vous pouvez calculer l’ICV ESP sur l’ensemble du paquet IPv6, à l’exclusion du nouvel en-tête IPv6 externe et des en-têtes d’extension facultatifs.
Contrairement à IPv4, IPv6 dispose d’une méthode pour marquer les options comme étant mutables en transit. Les en-têtes d’extension facultatifs IPv6 contiennent un indicateur qui indique la mutabilité. Cet indicateur détermine le traitement approprié.
Les options modifiables IPv4 et les en-têtes d’extension IPv6 ne sont pas pris en charge par le protocole AH.
Construction d’en-têtes en mode tunnel
En mode tunnel, les adresses source et de destination de l’en-tête IPv4 ou IPv6 externe représentent les points de terminaison du tunnel, tandis que les adresses source et de destination de l’en-tête interne IPv4 ou IPv6 représentent les adresses source et de destination finales. Tableau 4 résume la relation entre l’en-tête IPv6 externe et l’en-tête interne IPv6 ou IPv4 pour les modes tunnel IPv6-en-IPv6 ou IPv4-en-IPv6. Dans les champs d’en-tête externes, « Construit » signifie que la valeur du champ d’en-tête externe est construite indépendamment de la valeur du champ d’en-tête interne.
Champs d’en-tête |
En-tête externe au niveau de l’encapsulateur |
En-tête interne au niveau du décapsuleur |
|---|---|---|
Version |
6. |
Pas de changement. |
Champ DS |
Copié à partir de l’en-tête interne. |
Pas de changement. |
Champ ECN |
Copié à partir de l’en-tête interne. |
Construit. |
étiquette de flux |
0. |
Pas de changement. |
Longueur de la charge utile |
Construit. |
Pas de changement. |
En-tête suivant |
AH, ESP et en-tête de routage. |
Pas de changement. |
Limite de saut |
64. |
Decrement. |
Adresse SRC |
Construit. |
Pas de changement. |
Dest Adresse |
Construit. |
Pas de changement. |
En-têtes d’extension |
Jamais copié. |
Pas de changement. |
Tableau 5 résume la relation entre l’en-tête IPv4 externe et l’en-tête IPv6 ou IPv4 interne pour les modes tunnel IPv6-in-IPv4 ou IPv4-in-IPv4. Dans les champs d’en-tête externes, « Construit » signifie que la valeur du champ d’en-tête externe est construite indépendamment de la valeur du champ d’en-tête interne.
Champs d’en-tête |
En-tête externe |
En-tête interne |
|---|---|---|
Version |
4. |
Pas de changement. |
longueur de l’en-tête |
Construit. |
Pas de changement. |
Champ DS |
Copié à partir de l’en-tête interne. |
Pas de changement. |
Champ ECN |
Copié à partir de l’en-tête interne. |
Construit. |
Longueur totale |
Construit. |
Pas de changement. |
ID |
Construit. |
Pas de changement. |
drapeaux (DF, MF) |
Construit. |
Pas de changement. |
Décalage de fragment |
Construit. |
Pas de changement. |
TTL |
64. |
Decrement. |
Protocole |
AH, ESP |
Pas de changement. |
Checksum |
Construit. |
Construit. |
Adresse SRC |
Construit. |
Pas de changement. |
Dest Adresse |
Construit. |
Pas de changement. |
Options |
Jamais copié. |
Pas de changement. |
Pour le mode tunnel IPv6-en-IPv4, le bit Ne pas fragmenter (DF) est effacé par défaut. Si les df-bit set options ou df-bit copy sont configurées au niveau de la hiérarchie [edit security ipsec vpn vpn-name] pour le VPN IPv4 correspondant, le bit DF est défini dans l’en-tête IPv4 externe.
Pour le mode tunnel IPv4-en-IPv4, le bit DF dans l’en-tête IPv4 externe est basé sur l’option configurée pour l’en-tête df-bit IPv4 interne. S’il df-bit n’est pas configuré pour l’en-tête IPv4 interne, le bit DF est effacé dans l’en-tête IPv4 externe.
Voir également
Présentation de la configuration IPsec IPv6
Juniper Networks prend en charge les configurations IKE manuelles et automatiques avec des clés prépartagées pour le VPN IPv6 IPsec.
VPN IKE AutoKey : dans une configuration VPN IKE autoKey, les clés secrètes et les SA sont automatiquement créées à l’aide du mécanisme IKE autoKey. Pour configurer un VPN IKE IPv6 autoKey, deux phases de négociation sont nécessaires : la phase 1 et la phase 2.
Phase 1 : au cours de cette phase, les participants établissent un canal sécurisé pour négocier les SA IPsec.
Phase 2 : au cours de cette phase, les participants négocient les SA IPsec pour authentifier et chiffrer les paquets de données IPv6.
Pour plus d’informations sur les négociations de phase 1 et de phase 2, voir Internet Key Exchange
Voir également
Exemple : Configuration d’un VPN IPv6 manuel IPsec
Cet exemple montre comment configurer un VPN manuel IPv6 IPsec.
Conditions préalables
Avant de commencer :
Comprendre comment fonctionnent les VPN. Reportez-vous à la section Présentation d’IPsec.
Comprendre le traitement IPv6 et IPsec des paquets. Reportez-vous à la section Présentation de l’IKE IPv6 et du traitement IPsec des paquets.
Présentation
Dans une configuration VPN manuelle, les clés secrètes sont configurées manuellement sur les deux points de terminaison IPsec.
Dans cet exemple, vous :
Configurez les paramètres d’authentification d’un VPN nommé vpn-sunnyvale.
Configurez les paramètres de chiffrement pour vpn-sunnyvale.
Spécifiez l’interface sortante de la SA.
Spécifiez l’adresse IPv6 de l’homologue.
Définissez le protocole IPsec. Sélectionnez le protocole ESP, car la configuration inclut à la fois l’authentification et le chiffrement.
Configurez un index des paramètres de sécurité (SPI).
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.
set security ipsec vpn vpn-sunnyvale manual authentication algorithm hmac-md5–96 key ascii-text “$ABC123” set security ipsec vpn vpn-sunnyvale manual encryption algorithm 3des-cbc key ascii-text “$ABC123” set security ipsec vpn vpn-sunnyvale manual external-interface ge-0/0/14.0 set security ipsec vpn vpn-sunnyvale manual gateway 2001:db8:1212::1112 set security ipsec vpn vpn-sunnyvale manual protocol esp set security ipsec vpn vpn-sunnyvale manual spi 12435
Procédure étape par étape
L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur la façon de procéder, consultez Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur CLI.
Pour configurer les algorithmes de sécurité :
Configurez les paramètres d’authentification.
[edit security ipsec vpn vpn-sunnyvale manual] user@host# set authentication algorithm hmac-md5–96 key ascii-text “$ABC123”
Configurez les paramètres de chiffrement.
[edit security ipsec vpn vpn-sunnyvale manual] user@host# set encryption algorithm 3des-cbc key ascii-text “$ABC123”
Spécifiez l’interface sortante de la SA.
[edit security ipsec vpn vpn-sunnyvale manual] user@host# set external-interface ge-0/0/14.0
Spécifiez l’adresse IPv6 de l’homologue.
[edit security ipsec vpn vpn-sunnyvale manual] user@host# set gateway 2001:db8:1212::1112
Définissez le protocole IPsec.
[edit security ipsec vpn vpn-sunnyvale manual] user@host# set protocol esp
Configurez un SPI.
[edit security ipsec vpn vpn-sunnyvale manual] user@host# set spi 12435
Résultats
À partir du mode configuration, confirmez votre configuration en entrant la show security ipsec vpn vpn-sunnyvale commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration de cet exemple pour la corriger.
[edit]
[user@host]show security ipsec vpn vpn-sunnyvale
manual {
gateway 2001:db8:1212::1112 ;
external-interface ge-0/0/14.0 ;
protocol esp ;
spi 12435 ;
authentication {
algorithm hmac-md5-96 ;
key ascii-text $ABC123” ;## SECRET DATA
}
encryption {
algorithm 3des-cbc ;
key ascii-text $ABC123”; ## SECRET DATA
}
}
Vérification
Pour vérifier que la configuration fonctionne correctement, effectuez la tâche suivante :
Exemple : Configuration d’un VPN basé sur une stratégie IKE AutoKey IPv6
Cet exemple montre comment configurer un VPN IKE IPv6 AutoKey basé sur des stratégies pour autoriser le transfert sécurisé de données IPv6 entre la succursale et le siège social.
Les VPN basés sur des stratégies IPv6 sont uniquement pris en charge sur les équipements autonomes SRX300, SRX320, SRX340, SRX345 et SRX550HM.
Conditions préalables
Cet exemple utilise le matériel suivant :
-
Équipement SRX300
Avant de commencer :
-
Comprendre comment fonctionnent les VPN. Reportez-vous à la section Présentation d’IPsec.
-
Comprendre les protocoles IKE IPv6 et le traitement IPsec des paquets. Reportez-vous à la section Présentation de l’IKE IPv6 et du traitement IPsec des paquets.
Présentation
Dans cet exemple, vous allez configurer un VPN basé sur une stratégie IKE IPv6 pour une succursale à Chicago, dans l’Illinois, car vous n’avez pas besoin de conserver les ressources du tunnel ou de configurer de nombreuses stratégies de sécurité pour filtrer le trafic via le tunnel. Les utilisateurs du bureau de Chicago utiliseront le VPN pour se connecter à leur siège social à Sunnyvale, en Californie.
Figure 3 présente un exemple de topologie VPN basée sur une stratégie IKE IPv6. Dans cette topologie, un pare-feu SRX Series se trouve à Sunnyvale et un autre pare-feu SRX Series (il peut s’agir d’un deuxième pare-feu SRX Series ou d’un équipement tiers) est situé à Chicago.
Dans cet exemple, vous configurez des interfaces, une route IPv6 par défaut, des zones de sécurité et des carnets d’adresses. Ensuite, vous configurez la phase 1 d’IKE, la phase 2 d’IPsec, une stratégie de sécurité et des paramètres TCP-MSS. Voir Tableau 6 à travers Tableau 10.
|
Fonctionnalité |
Nom |
Paramètres de configuration |
|---|---|---|
|
Interfaces |
GE-0/0/14.0 |
2001 :db8 :3 ::1/96 |
|
GE-0/0/15.0 |
2001 :db8 :0 :2 ::1/96 |
|
|
Zones de sécurité |
Trouille |
|
|
Untrust |
|
|
|
Entrées du carnet d’adresses |
Sunnyvale |
|
|
Chicago |
|
|
Fonctionnalité |
Nom |
Paramètres de configuration |
|---|---|---|
|
Proposition |
Proposition ipv6-ike-phase1 |
|
|
Politique |
politique ipv6-ike-phase1 |
|
|
Passerelle |
gw-C hicago |
|
|
Fonctionnalité |
Nom |
Paramètres de configuration |
|---|---|---|
|
Proposition |
Proposition ipv6-ipsec-phase2 |
|
|
Politique |
ipv6-ipsec-phase2-policy |
|
|
VPN |
ipv6-ike-vpn-chicago |
|
|
But |
Nom |
Paramètres de configuration |
|---|---|---|
|
Cette stratégie de sécurité autorise le trafic de la zone de confiance vers la zone de méfiance. |
ipv6-vpn-tr-untr |
|
|
Cette stratégie de sécurité autorise le trafic de la zone de confiance vers la zone de confiance. |
ipv6-vpn-untr-tr |
|
|
Cette stratégie de sécurité autorise tout le trafic de la zone de confiance vers la zone de méfiance. Vous devez placer la politique ipv6-vpn-tr-untr avant la politique de sécurité allow-any. Junos OS effectue une recherche des stratégies de sécurité en commençant par le haut de la liste. Si la politique permit-any précède la politique ipv6-vpn-tr-untr, tout le trafic provenant de la zone de confiance correspondra à la politique permit-any et sera autorisé. Ainsi, aucun trafic ne correspondra jamais à la politique ipv6-vpn-tr-untr. |
permis-tout |
|
|
But |
Paramètres de configuration |
|---|---|
|
TCP-MSS est négocié dans le cadre de l’établissement de liaison TCP à trois voies et limite la taille maximale d’un segment TCP afin de mieux s’adapter aux limites MTU d’un réseau. Ceci est particulièrement important pour le trafic VPN, car la surcharge d’encapsulation IPsec, ainsi que l’IP et la surcharge de trames, peuvent entraîner un dépassement du MTU de l’interface physique par le paquet ESP résultant, provoquant ainsi une fragmentation. La fragmentation augmente l’utilisation de la bande passante et des ressources des appareils. Nous recommandons une valeur de 1350 comme point de départ pour la plupart des réseaux Ethernet avec une MTU de 1500 ou plus. Vous devrez peut-être tester différentes valeurs TCP-MSS pour obtenir des performances optimales. Par exemple, vous devrez peut-être modifier la valeur si un périphérique du chemin d’accès a une MTU inférieure ou s’il existe une surcharge supplémentaire telle que PPP ou Frame Relay. |
Valeur MSS : 1350 |
Configuration
- Configuration des informations de base sur le réseau, la zone de sécurité et le carnet d’adresses
- Configuration d’IKE
- Configuration d’IPsec
- Configuration des stratégies de sécurité
- Configuration de TCP-MSS
Configuration des informations de base sur le réseau, la zone de sécurité et le carnet d’adresses
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.
set interfaces ge-0/0/14 unit 0 family inet6 address 2001:db8:3::1/96 set interfaces ge-0/0/15 unit 0 family inet6 address 2001:db8:2::1/96 set routing-options static route 0.0.0.0/0 next-hop 10.1.1.1 set security zones security-zone Untrust interfaces ge-0/0/15.0 set security zones security-zone Untrust host-inbound-traffic system-services ike set security zones security-zone Trust interfaces ge-0/0/14.0 set security zones security-zone Trust host-inbound-traffic system-services all set security address-book book1 address Sunnyvale 2001:db8:3::2/96 set security address-book book1 attach zone Trust set security address-book book2 address Chicago 2001:db8:0::2/96 set security address-book book2 attach zone Untrust
Procédure étape par étape
L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur la façon de procéder, consultez Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur CLI.
Pour configurer les informations de base du réseau, de la zone de sécurité et du carnet d’adresses :
-
Configurez les informations de l’interface Ethernet.
[edit] user@host# set interfaces ge-0/0/14 unit 0 family inet6 address 2001:db8:3::1/96 user@host# set interfaces ge-0/0/15 unit 0 family inet6 address 2001:db8:2::1/96
-
Configurez les informations d’itinéraire statiques.
[edit] user@host# set routing-options static route 0.0.0.0/0 next-hop 10.1.1.1
-
Configurez la zone de sécurité Untrust .
[edit] user@host# edit security zones security-zone Untrust
-
Attribuez une interface à la zone de sécurité Untrust .
[edit security zones security-zone Untrust] user@host# set interfaces ge-0/0/15.0
-
Spécifiez les services système autorisés pour la zone de sécurité Untrust .
[edit security zones security-zone Untrust] user@host# set host-inbound-traffic system-services ike
-
Configurez la zone de sécurité Trust.
[edit] user@host# edit security zones security-zone Trust
-
Attribuez une interface à la zone de sécurité de confiance .
[edit security zones security-zone Trust] user@host# set interfaces ge-0/0/14.0
-
Spécifiez les services système autorisés pour la zone de sécurité de confiance .
[edit security zones security-zone Trust] user@host# set host-inbound-traffic system-services all
-
Créez un carnet d’adresses et attachez-y une zone.
[edit security address-book book1] user@host# set address Sunnyvale 2001:db8:3::2/96 user@host# set attach zone Trust
-
Créez un autre carnet d’adresses et attachez-y une zone.
[edit security address-book book2] user@host# set address Chicago 2001:db8:0::2/96 user@host# set attach zone Untrust
Résultats
À partir du mode de configuration, confirmez votre configuration en saisissant les commandes show interfaces, show routing-options, show security zoneset show security address-book. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration de cet exemple pour la corriger.
[edit]
user@host# show interfaces
ge-0/0/14 {
unit 0 {
family inet6 {
address 2001:db8:3::1/96;
}
}
}
ge-0/0/15 {
unit 0 {
family inet6 {
address 2001:db8:2::1/96;
}
}
}
[edit]
user@host# show routing-options
static {
route 0.0.0.0/0 next-hop 10.1.1.1;
}
[edit]
user@host# show security zones
security-zone Untrust {
host-inbound-traffic {
system-services {
ike;
}
}
interfaces {
ge-0/0/15.0;
}
}
security-zone Trust {
host-inbound-traffic {
system-services {
all;
}
}
interfaces {
ge-0/0/14.0;
}
}
[edit]
user@host# show security address-book
book1 {
address Sunnyvale 2001:db8:3::2/96;
attach {
zone Trust;
}
}
book2 {
address Chicago 2001:db8:0::2/96;
attach {
zone Untrust;
}
}
Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.
Configuration d’IKE
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.
set security ike proposal ipv6-ike-phase1-proposal authentication-method pre-shared-keys set security ike proposal ipv6-ike-phase1-proposal dh-group group2 set security ike proposal ipv6-ike-phase1-proposal authentication-algorithm sha1 set security ike proposal ipv6-ike-phase1-proposal encryption-algorithm aes-128-cbc set security ike policy ipv6-ike-phase1-policy mode aggressive set security ike policy ipv6-ike-phase1-policy proposals ipv6-ike-phase1-proposal set security ike policy ipv6-ike-phase1-policy pre-shared-key ascii-text 1111111111111111 set security ike gateway gw-chicago external-interface ge-0/0/15.0 set security ike gateway gw-chicago ike-policy ipv6-ike-phase1-policy set security ike gateway gw-chicago address 2001:db8:0:1::1/96
Procédure étape par étape
L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur la façon de procéder, consultez Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur CLI.
Pour configurer l’IKE :
-
Créez la proposition IKE Phase 1.
[edit security ike] user@host# set proposal ipv6-ike-phase1-proposal
-
Définissez la méthode d’authentification de la proposition IKE.
[edit security ike proposal ipv6-ike-phase1-proposal] user@host# set authentication-method pre-shared-keys
-
Définissez le groupe Diffie-Hellman de la proposition IKE.
[edit security ike proposal ipv6-ike-phase1-proposal] user@host# set dh-group group2
-
Définissez l’algorithme d’authentification de la proposition IKE.
[edit security ike proposal ipv6-ike-phase1-proposal] user@host# set authentication-algorithm sha1
-
Définissez l’algorithme de chiffrement de la proposition IKE.
[edit security ike proposal ipv6-ike-phase1-proposal] user@host# set encryption-algorithm aes-128-cbc
-
Créez une stratégie IKE Phase 1.
[edit security ike] user@host# set policy ipv6-ike-phase1-policy
-
Définissez le mode de stratégie IKE Phase 1.
[edit security ike policy ipv6-ike-phase1-policy] user@host# set mode aggressive
-
Spécifiez une référence à la proposition IKE.
[edit security ike policy ipv6-ike-phase1-policy] user@host# set proposals ipv6-ike-phase1-proposal
-
Définissez la méthode d’authentification de la stratégie IKE Phase 1.
[edit security ike policy ipv6-ike-phase1-policy] user@host# set pre-shared-key ascii-text 1111111111111111
-
Créez une passerelle IKE Phase 1 et définissez son interface externe.
[edit security ike] user@host# set gateway gw-chicago external-interface ge-0/0/15.0
-
Définissez la référence de stratégie IKE Phase 1.
[edit security ike gateway gw-chicago] user@host# set ike-policy ipv6-ike-phase1-policy
-
Attribuez une adresse IP à la passerelle IKE Phase 1.
[edit security ike gateway gw-chicago] user@host# set address 2001:db8:1::1
Résultats
À partir du mode configuration, confirmez votre configuration en entrant la show security ike commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration de cet exemple pour la corriger.
[edit]
user@host# show security ike
proposal ipv6-ike-phase1-proposal {
authentication-method pre-shared-keys;
dh-group group2;
authentication-algorithm sha1;
encryption-algorithm aes-128-cbc;
}
policy ipv6-ike-phase1-policy {
mode ;
proposals ipv6-ike-phase1-proposal;
pre-shared-key ascii-text "$ABC123"; ## SECRET-DATA
}
gateway gw-chicago {
ike-policy ipv6-ike-phase1-policy;
address 2001:db8:1::1;
external-interface ge-0/0/15.0;
}
Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.
Configuration d’IPsec
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.
set security ipsec proposal ipv6-ipsec-phase2-proposal protocol esp set security ipsec proposal ipv6-ipsec-phase2-proposal authentication-algorithm hmac-sha1-96 set security ipsec proposal ipv6-ipsec-phase2-proposal encryption-algorithm aes-128-cbc set security ipsec policy ipv6-ipsec-phase2-policy proposals ipv6-ipsec-phase2-proposal set security ipsec policy ipv6-ipsec-phase2-policy perfect-forward-secrecy keys group2 set security ipsec vpn ipv6-ike-vpn-chicago ike gateway gw-chicago set security ipsec vpn ipv6-ike-vpn-chicago ike ipv6-ipsec-policy ipsec-phase2-policy
Procédure étape par étape
L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur la façon de procéder, consultez Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur CLI.
Pour configurer IPsec :
-
Créez une proposition IPsec Phase 2.
[edit] user@host# set security ipsec proposal ipv6-ipsec-phase2-proposal
-
Spécifiez le protocole de proposition IPsec Phase 2.
[edit security ipsec proposal ipv6- ipsec-phase2-proposal] user@host# set protocol esp
-
Spécifiez l’algorithme d’authentification de proposition IPsec Phase 2.
[edit security ipsec proposal ipv6-ipsec-phase2-proposal] user@host# set authentication-algorithm hmac-sha1-96
-
Spécifiez l’algorithme de chiffrement de proposition IPsec Phase 2.
[edit security ipsec proposal ipv6-ipsec-phase2-proposal] user@host# set encryption-algorithm aes-128-cbc
-
Créez la stratégie IPsec Phase 2.
[edit security ipsec] user@host# set policy ipv6-ipsec-phase2-policy
-
Spécifiez la référence de proposition IPsec Phase 2.
[edit security ipsec policy ipv6-ipsec-phase2-policy] user@host# set proposals ipv6-ipsec-phase2-proposal
-
Spécifiez le PFS IPsec Phase 2 pour utiliser le groupe Diffie-Hellman 2.
[edit security ipsec policy ipv6-ipsec-phase2-policy] user@host# set perfect-forward-secrecy keys group2
-
Spécifiez la passerelle IKE.
[edit security ipsec] user@host# set vpn ipv6-ike-vpn-chicago ike gateway gw-chicago
-
Spécifiez la stratégie IPsec Phase 2.
[edit security ipsec] user@host# set vpn ipv6-ike-vpn-chicago ike ipsec-policy ipv6-ipsec-phase2-policy
Résultats
À partir du mode configuration, confirmez votre configuration en entrant la show security ipsec commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration de cet exemple pour la corriger.
[edit]
user@host# show security ipsec
proposal ipv6-ipsec-phase2-proposal {
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm aes-128-cbc;
}
policy ipv6-ipsec-phase2-policy {
perfect-forward-secrecy {
keys group2;
}
proposals ipv6-ipsec-phase2-proposal;
}
vpn ipv6-ike-vpn-chicago {
ike {
gateway gw-chicago;
ipsec-policy ipv6-ipsec-phase2-policy;
}
}
Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.
Configuration des stratégies de sécurité
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.
set security policies from-zone Trust to-zone Untrust policy ipv6-vpn-tr-untr match source-address Sunnyvale set security policies from-zone Trust to-zone Untrust policy ipv6-vpn-tr-untr match destination-address Chicago set security policies from-zone Trust to-zone Untrust policy ipv6-vpn-tr-untr match application any set security policies from-zone Trust to-zone Untrust policy ipv6-vpn-tr-untr then permit tunnel ipsec-vpn ipv6-ike-vpn-chicago set security policies from-zone Trust to-zone Untrust policy ipv6-vpn-tr-untr then permit tunnel pair-policy ipv6-vpn-untr-tr set security policies from-zone Untrust to-zone Trust policy ipv6-vpn-untr-tr match source-address Chicago set security policies from-zone Untrust to-zone Trust policy ipv6-vpn-untr-tr match destination-address Sunnyvale set security policies from-zone Untrust to-zone Trust policy ipv6-vpn-untr-tr match application any set security policies from-zone Untrust to-zone Trust policy ipv6-vpn-untr-tr then permit tunnel ipsec-vpn ipv6-ike-vpn-chicago set security policies from-zone Untrust to-zone Trust policy ipv6-vpn-untr-tr then permit tunnel pair-policy ipv6-vpn-tr-untr set security policies from-zone Trust to-zone Untrust policy permit-any match source-address any set security policies from-zone Trust to-zone Untrust policy permit-any match destination-address any set security policies from-zone Trust to-zone Untrust policy permit-any match application any set security policies from-zone Trust to-zone Untrust policy permit-any then permit insert security policies from-zone Trust to-zone Untrust policy ipv6-vpn-tr-untr before policy permit-any
Procédure étape par étape
L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur la façon de procéder, consultez Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur CLI.
Pour configurer les politiques de sécurité :
-
Créez la stratégie de sécurité pour autoriser le trafic de la zone de confiance vers la zone d’approbation.
[edit security policies from-zone Trust to-zone Untrust] user@host# set policy ipv6-vpn-tr-untr match source-address Sunnyvale user@host# set policy ipv6-vpn-tr-untr match destination-address Chicago user@host# set policy ipv6-vpn-tr-untr match application any user@host# set policy ipv6-vpn-tr-untr then permit tunnel ipsec-vpn ipv6-ike-vpn-chicago user@host# set policy ipv6-vpn-tr-untr then permit tunnel pair-policy ipv6-vpn-untr-tr
-
Créez la stratégie de sécurité pour autoriser le trafic de la zone de confiance vers la zone de confiance.
[edit security policies from-zone Untrust to-zone Trust] user@host# set policy ipv6-vpn-untr-tr match source-address Sunnyvale user@host# set policy ipv6-vpn-untr-tr match destination-address Chicago user@host# set policy ipv6-vpn-untr-tr match application any user@host# set policy ipv6-vpn-untr-tr then permit tunnel ipsec-vpn ipv6-ike-vpn-chicago user@host# set policy ipv6-vpn-untr-tr then permit tunnel pair-policy ipv6-vpn-tr-untr
-
Créez la stratégie de sécurité pour autoriser le trafic de la zone de confiance vers la zone d’approbation.
[edit security policies from-zone Trust to-zone Untrust] user@host# set policy permit-any match source-address any user@host# set policy permit-any match destination-address any user@host# set policy permit-any match application any user@host# set policy permit-any then permit
-
Réorganisez les stratégies de sécurité de manière à ce que la stratégie de sécurité vpn-tr-untr soit placée au-dessus de la politique de sécurité allow-any.
[edit security policies from-zone Trust to-zone Untrust] user@host# insert policy ipv6-vpn-tr-untr before policy permit-any
Résultats
À partir du mode configuration, confirmez votre configuration en entrant la show security policies commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration de cet exemple pour la corriger.
[edit]
user@host# show security policies
from-zone Trust to-zone Untrust {
policy ipv6-vpn-tr-untr {
match {
source-address Sunnyvale;
destination-address Chicago;
application any;
}
then {
permit {
tunnel {
ipsec-vpn ipv6-ike-vpn-chicago;
pair-policy ipv6-vpn-untr-tr;
}
}
}
}
policy permit-any {
match {
source-address any;
destination-address any;
application any;
}
then {
permit
}
}
}
from-zone Untrust to-zone Trust {
policy ipv6-vpn-untr-tr {
match {
source-address Chicago;
destination-address Sunnyvale;
application any;
}
then {
permit {
tunnel {
ipsec-vpn ipv6-ike-vpn-chicago;
pair-policy ipv6-vpn-tr-untr;
}
}
}
}
}
Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.
Configuration de TCP-MSS
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.
set security flow tcp-mss ipsec-vpn mss 1350
Procédure étape par étape
Pour configurer les informations TCP-MSS :
-
Configurez les informations TCP-MSS.
[edit] user@host# set security flow tcp-mss ipsec-vpn mss 1350
Résultats
À partir du mode configuration, confirmez votre configuration en entrant la show security flow commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration de cet exemple pour la corriger.
[edit]
user@host# show security flow
tcp-mss {
ipsec-vpn {
mss 1350;
}
}
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’état de la phase 1 de l’IKE
But
Vérifiez l’état de la phase 1 de l’IKE.
Action
Avant de commencer le processus de vérification, vous devez envoyer le trafic d’un hôte à Sunnyvale vers un hôte à Chicago. Pour les VPN basés sur des stratégies, un hôte distinct doit générer le trafic. le trafic initié à partir du pare-feu SRX Series ne correspondra pas à la stratégie VPN. Nous recommandons que le trafic de test provienne d’un périphérique séparé d’un côté du VPN vers un second périphérique de l’autre côté du VPN. Par exemple, lancez le ping de 2001 :db8 :3 ::2/96 à 2001 :db8 :0 ::2/96.
À partir du mode opérationnel, entrez la show security ike security-associations commande. Après avoir obtenu un numéro d’index à partir de la commande, utilisez la show security ike security-associations index index_number detail commande.
user@host> show security ike security-associations Index Remote Address State Initiator cookie Responder cookie Mode 5 2001:db8:1::1 UP e48efd6a444853cf 0d09c59aafb720be Aggressive
user@host> show security ike security-associations index 5 detail
IKE peer 2001:db8:1::1, Index 5,
Role: Initiator, State: UP
Initiator cookie: e48efd6a444853cf, Responder cookie: 0d09c59aafb720be
Exchange type: Aggressive, Authentication method: Pre-shared-keys
Local: 2001:db8:2::1:500, Remote: 2001:db8:1::1:500
Lifetime: Expires in 19518 seconds
Peer ike-id: not valid
Xauth assigned IP: 0.0.0.0
Algorithms:
Authentication : sha1
Encryption : aes-128-cbc
Pseudo random function: hmac-sha1
Traffic statistics:
Input bytes : 1568
Output bytes : 2748
Input packets: 6
Output packets: 23
Flags: Caller notification sent
IPSec security associations: 5 created, 0 deleted
Phase 2 negotiations in progress: 1
Negotiation type: Quick mode, Role: Initiator, Message ID: 2900338624
Local: 2001:db8:2::1:500, Remote: 2001:db8:1::1:500
Local identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
Remote identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
Flags: Caller notification sent, Waiting for doneSens
La show security ike security-associations commande répertorie toutes les associations de sécurité (SA) IKE actives de phase 1. Si aucune SA n’est répertoriée, il y a eu un problème avec l’établissement de la phase 1. Vérifiez les paramètres de stratégie IKE et les paramètres de l’interface externe dans votre configuration.
Si des SA sont répertoriées, vérifiez les informations suivantes :
-
Index : cette valeur est unique pour chaque IKE SA, que vous pouvez utiliser dans la commande pour obtenir plus d’informations sur la
show security ike security-associations index index_number detailSA. -
Remote Address (Adresse distante) : vérifiez que l’adresse IP distante est correcte.
-
État
-
UP : l’AS de phase 1 a été établie.
-
BAS : un problème est survenu lors de l’établissement de l’AS de phase 1.
-
-
Mode (Mode) : vérifiez que le mode approprié est utilisé.
Vérifiez que les éléments suivants sont corrects dans votre configuration :
-
Interfaces externes (l’interface doit être celle qui reçoit les paquets IKE)
-
Paramètres de stratégie IKE
-
Informations clés prépartagées
-
Paramètres de la proposition de la phase 1 (doivent correspondre sur les deux pairs)
La show security ike security-associations index 5 detail commande répertorie des informations supplémentaires sur l’association de sécurité avec un numéro d’index de 5 :
-
Algorithmes d’authentification et de chiffrement utilisés
-
Durée de vie de la phase 1
-
Statistiques de trafic (peuvent être utilisées pour vérifier que le trafic est fluide dans les deux sens)
-
Informations sur les rôles de l’initiateur et de l’intervenant
Le dépannage est mieux effectué sur l’homologue à l’aide du rôle de répondeur.
-
Nombre de SA IPsec créées
-
Nombre de négociations de phase 2 en cours
Vérification de l’état IPsec Phase 2
But
Vérifiez l’état IPsec Phase 2.
Action
À partir du mode opérationnel, entrez la show security ipsec security-associations commande. Après avoir obtenu un numéro d’index à partir de la commande, utilisez la show security ipsec security-associations index index_number detail commande.
user@host> show security ipsec security-associations total configured sa: 2 ID Algorithm SPI Life:sec/kb Mon vsys Port Gateway 2 ESP:aes-128/sha1 14caf1d9 3597/ unlim - root 500 2001:db8:1::1 2 ESP:aes-128/sha1 9a4db486 3597/ unlim - root 500 2001:db8:1::1
user@host> show security ipsec security-associations index 2 detail
Virtual-system: Root
Local Gateway: 2001:db8:2::1, Remote Gateway: 2001:db8:1::1
Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
DF-bit: clear
Direction: inbound, SPI: 14caf1d9, AUX-SPI: 0
, VPN Monitoring: -
Hard lifetime: Expires in 3440 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 2813 seconds
Mode: tunnel, Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (128 bits)
Anti-replay service: counter-based enabled, Replay window size: 64
Direction: outbound, SPI: 9a4db486, AUX-SPI: 0
, VPN Monitoring: -
Hard lifetime: Expires in 3440 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 2813 seconds
Mode: tunnel, Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (128 bits)
Anti-replay service: counter-based enabled, Replay window size: 64Sens
La sortie de la show security ipsec security-associations commande répertorie les informations suivantes :
-
Le numéro d’identification est 2. Utilisez cette valeur avec la
show security ipsec security-associations indexcommande pour obtenir plus d’informations sur cette SA particulière. -
Il existe une paire SA IPsec utilisant le port 500, ce qui indique qu’aucune traversée NAT n’est implémentée. (La traversée NAT utilise le port 4500 ou un autre port aléatoire à nombre élevé.)
-
Les SPI, la durée de vie (en secondes) et les limites d’utilisation (ou la durée de vie en Ko) sont indiqués dans les deux sens. La valeur 3597/unlim indique que la durée de vie de la phase 2 expire dans 3597 secondes et qu’aucune durée de vie n’a été spécifiée, ce qui indique que la durée de vie est illimitée. La durée de vie de la phase 2 peut différer de la durée de vie de la phase 1, car la phase 2 ne dépend pas de la phase 1 une fois le VPN activé.
-
La surveillance VPN n’est pas activée pour cette SA, comme l’indique un trait d’union dans la colonne Mon. Si la surveillance VPN est activée, U (haut) ou D (bas) est répertorié.
-
Le système virtuel (vsys) est le système racine, et il indique toujours 0.
La sortie de la show security ipsec security-associations index 2 detail commande répertorie les informations suivantes :
-
Les identités locale et distante constituent l’ID de proxy de la SA.
Une incompatibilité d’ID de proxy est l’une des raisons les plus courantes d’un échec de phase 2. Pour les VPN basés sur des stratégies, l’ID de proxy est dérivé de la stratégie de sécurité. Les adresses locale et distante sont dérivées des entrées du carnet d’adresses, et le service est dérivé de l’application configurée pour la stratégie. Si la phase 2 échoue en raison d’une incompatibilité d’ID de proxy, vous pouvez utiliser la stratégie pour confirmer les entrées du carnet d’adresses configurées. Vérifiez que les adresses correspondent aux informations envoyées. Vérifiez le service pour vous assurer que les ports correspondent aux informations envoyées.
Pour certains fournisseurs tiers, l’ID de proxy doit être saisi manuellement pour correspondre.