Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

VPN IPsec IPv6

Juniper Networks prend en charge les configurations manuelles et auto-IKE clés pré-partagées pour VPN IPv6 IPsec.

Prise en charge des fonctionnalités VPN pour les adresses IPv6

Un tunnel VPN de site à site basé sur le routeur, avec interface tunnel sécurisée point à point, peut fonctionner en modes tunnel IPv4-in-IPv4, IPv6-in-IPv6, IPv6-in-IPv4 ou IPv4-in-IPv6. Les adresses IPv6 peuvent se trouver dans l’en-tête IP extérieur, 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.

Tableau 1 : Prise en charge des adresses IPv6 dans les fonctionnalités VPN

Fonctionnalité

Soutenu

Exceptions

IKE et IPsec:

IKEv1 et IKEv2

Oui

Sauf indication spécifique, toutes les fonctionnalités prise en charge sont applicables aux normes 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 SRX Series dans les configurations de clusters de châssis. Les VPN basés sur des stratégies IPv6 sont uniquement pris en charge avec les tunnels IPv6-in-IPv6 sur les équipements SRX300, SRX320, SRX340, SRX345 et SRX550HM.

VPN de site à site

Oui

Seule une connexion VPN unique est prise en charge, site à site. La prise en charge d’un VPN de site à site (NHTB) de plusieurs à un n’est pas prise en charge. La configuration NHTB ne peut pas être engagée pour des modes de tunnel autres que les tunnels IPv4-in-IPv4.

VPN dynamique aux points d’extrémité

Oui

VPN d’appel

Oui

VPN automatique

Oui

Réseaux autoVPN qui utilisent des interfaces de tunnel sécurisées en mode point à point et prend en charge les adresses IPv6 pour les sélecteurs de trafic et les IKE pairs. Le trafic 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 hub-and-spoke pour les VPN de site à site

Oui

Interfaces de tunnel numérotés et non numérotés

Oui

Routage statique et dynamique unicast (RIP, OSPF, BGP)

Oui

PIM (Multicast Dynamic Routing)

Non

Routeur virtuel

Oui

Système logique

Non

Gestion automatique et manuelle des sa et des clés

Oui

Multiples spUs

Oui

Cluster de châssis

Oui

Le VPN IPsec en mode actif-actif est pris en charge uniquement sur les équipements SRX300, SRX320, SRX340, SRX345 et SRX550HM pour les tunnels IPv6 basés sur le routeur. Le VPN IPsec en mode actif-actif n’est pas pris en charge SRX5400, SRX5600 et SRX5800 périphériques mobiles.

Statistiques, journaux, débogage par tunnel

Oui

SNMP MIB

Oui

Sélection d’adresses locales

Oui

Lorsque plusieurs adresses d’une même famille d’adresses sont configurées sur une interface physique externe vers un pair VPN, il est recommandé de la configurer également au niveau local-addressedit security ike gateway gateway-name hiérarchique []

Arrêt de l’adresse de bouclage

Oui

Xauth ou modecfg sur IPv6

Non

Insérer SPC

Oui

ISSU

Oui

Nom DNS comme adresse IKE passerelle

Oui

Comme pour les tunnels IPv4, les changements d’adresse de passerelle pair dans le nom DNS ne sont pas pris en charge par les tunnels IPv6.

Authentification de certificat ou clé partagée

Oui

NAT-Traversal (NAT-T) pour les pairs IPv4 IKE pairs

Oui

NAT-T est prise en charge uniquement pour les modes tunnel IPv6-in-IPv4 et IPv4-in-IPv4 avec IKEv1. Les modes de tunnel IPv6-in-IPv6 et IPv4-in-IPv6 ne sont pas pris en charge. IKEv2 n’est pas pris en charge par NAT-T. NAT-T d’IPv6 à IPv4 ou d’IPv4 à IPv6 n’est pas prise en charge.

Détection des pairs morts (DPD) etover de passerelle DPD

Oui

Le failover de la passerelle DPD est uniquement pris en charge pour différentes adresses de passerelle au sein de la même famille. Le passage d’une adresse de passerelle IPv6 à une adresse de passerelle IPv4, ou vice versa, n’est pas pris en charge.

Ensembles de chiffrement, algorithmes d’authentification et groupes DH pris Junos OS version 12.1X45-D10 version pour SRX Series périphériques mobiles.

Oui

Propositions et stratégies 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 en-têtes d’extension mutables et options n’est pas pris en charge.

Numéro de séquence étendu

Non

Paires d’ID de proxy unique

Oui

Plusieurs paires de sélecteur de trafic

Oui

Prise en charge avec IKEv1 uniquement.

Durée de vie IKE sa IPsec, en secondes

Oui

Durée de IKE SA, en kilo-octets

Oui

Surveillance VPN

Non

La configuration avec des tunnels IPv6 ne peut pas être engagée.

Bit DF

Oui

Pour les tunnels IPv6-IPv6, le bit DF n’est configuré que si le niveau hiérarchique [ ] est edit security ipsec vpn vpn-namedf-bit clear le niveau par défaut.

Double pile (tunnels IPv4 et IPv6 parallèles) sur une seule interface physique

Oui

Pour les VPN de site à site basés sur le routeur. Un seul tunnel IPv4 peut fonctionner en modes tunnel IPv4-in-IPv4 et IPv6-in-IPv4 et un tunnel IPv6 peut fonctionner à la fois en modes IPv4-in-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 IKE et les paquets IPsec sont acceptés mais ne sont pas traitées. Ah avec des EH et options mutables, et pas de prise en charge.

Fragmentation et réassemblation

Oui

Affinité vpn par session

Oui

Trafic multicast

Non

Services IP tunnel (écran, NAT, ALG, IPS, AppSecure)

Oui

Réordage de paquets pour les fragments IPv6 par 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 un routeur virtuel

Oui

Authentification par signature RSA (taille de clé de 512-, 1024-, 2048-ou 4096 bits)

Oui

Authentification des signatures DSA (taille de clé de 1 024, 2048 ou 4 096 bits)

Oui

Signatures ECDSA

Oui

Authentification de chaîne de certificats

Non

Inscription automatique ou manuelle sur IPv4

Oui

Révocation automatique ou manuelle sur IPv4

Oui

Inscription automatique ou manuelle sur IPv6

Non

Révocation automatique ou manuelle sur IPv6

Non

Adresses IPv6 dans les champs de certificat PKI

Non

Compréhension des processus de IKE IPv6 et du traitement des paquets IPsec

Cette rubrique comprend les sections suivantes :

Traitement IKE des paquets IPv6

Internet Key Exchange (IKE) fait partie de la suite de protocoles IPsec. Il permet automatiquement à deux points de terminaison de tunnel de mettre en place des associations de sécurité (SA) et de négocier les clés secrètes entre elles. Il n’est pas nécessaire de configurer manuellement les paramètres de sécurité. IKE fournit également l’authentification des pairs en communication.

IKE traitement des paquets 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 pairs IPv6 en communication. Deux types d’ID (ID_IPV6_ADDR et ID_IPV6_ADDR_SUBNET) sont activés pour IPv6. Le type d’ID indique le type d’identification à utiliser. Le ID_IPV6_ADDR type spécifie une seule adresse IPv6 à 16 octet. Ce type d’ID représente une adresse IPv6. Le ID_IPV6_ADDR_SUBNET type spécifie une gamme d’adresses IPv6 représentées par deux valeurs à 16 octet. Ce type d’ID représente un masque réseau IPv6. Tableau 2 répertorie les types d’ID et les valeurs 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 ID_IPV6_ADDR_RANGE type spécifie une gamme d’adresses IPv6 représentées par deux valeurs à 16 octet. La première valeur octet représente l’adresse IPv6 de départ et la seconde valeur d’octet représente l’adresse IPv6 finale de la plage. Toutes les adresses IPv6 se s étant trouver entre la première et la dernière adresses 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.

  • ID de proxy

    Un ID proxy est utilisé lors de la phase 2 IKE négociation. Il est généré avant qu’un tunnel IPsec ne soit établi. Un ID proxy identifie le SA à utiliser pour le VPN. Deux ID proxy sont générés: local et distant. L’ID de proxy local fait référence à l’adresse/réseau/réseau et au masque de sous-réseau IPv4 ou IPv6 local. L’ID de proxy distant fait référence à l’adresse/réseau/réseau et au masque de sous-réseau IPv4 ou IPv6 distant.

  • Association de sécurité

    Un sa est un accord entre les participants VPN afin de prendre en charge une communication sécurisée. Les SA sont différenciés en fonction de trois paramètres: l’index 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 à un SA pour aider à identifier un SA parmi plusieurs SA. Dans un paquet IPv6, le sa est identifié à partir de l’adresse de destination de l’en-tête IPv6 extérieur et le protocole de sécurité est identifié à partir de l’en-tête AH ou ESP.

Traitement des paquets IPsec IPv6

Une fois les négociations IKE terminées et que les deux passerelles IKE ont mis en place des SA de phase 1 et 2, IPv6 IPsec utilise des technologies d’authentification et de chiffrement pour sécuriser les paquets IPv6. Parce que les adresses IPv6 sont de 128 bits par rapport aux adresses IPv4 de 32 bits, le traitement des paquets IPv6 IPsec nécessite plus de ressources.

Le réordage de paquets pour les fragments IPv6 sur un tunnel n’est pas pris en charge.

Les équipements avec adressan IPv6 n’exécutent pas la fragmentation. Les hôtes IPv6 doivent effectuer la détection MTU chemin ou envoyer des paquets de plus petite taille que la taille minimale MTU IPv6 de 1 280 octets.

Cette rubrique comprend les sections suivantes :

Protocole AH dans IPv6

Le protocole AH assure l’intégrité des données et l’authentification des données pour les paquets IPv6. IPsec IPv6 utilise des en-têtes d’extension (par exemple, options de routage et de saut par saut) qui doivent être différentes 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 extérieur à celui du mode tunnel AH IPv4. Les en-têtes d’extension sont placés après l’en-tête interne d’origine. Ainsi, en mode tunnel AH, l’ensemble du paquet est encapsulé en ajoutant un nouvel en-tête IPv6 extérieur, 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 illustré dans Figure 1 .

Figure 1 : IPv6 AH Tunnel ModeIPv6 AH Tunnel Mode

Contrairement à ESP, l’algorithme d’authentification AH couvre l’en-tête extérieur ainsi que tout nouvel en-tête et options d’extension.

Le mode tunnel AH sur SRX Series ne prend pas en charge les options mutables IPv4 ni les en-têtes d’extension mutables IPv6. Voir Tableau 3 .

Protocole ESP dans IPv6

Le protocole ESP fournit à la fois le chiffrement et l’authentification des paquets IPv6. IPsec utilise des en-têtes d’extension (par exemple, 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 IPv4 ESP est la position 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 extérieur à celui du mode tunnel ESP IPv4. Ainsi, en mode tunnel ESP, l’ensemble du paquet est encapsulé en ajoutant un nouvel en-tête IPv6 extérieur, 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 illustré dans Figure 2 .

Figure 2 : IPv6 ESP Tunnel ModeIPv6 ESP Tunnel Mode

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 la décapsulation sur SRX Series périphériques. affiche les options IPv4 ou les en-têtes d’extension IPv6 pris en charge avec l’ESP ou le protocole Tableau 3 AH SRX Series périphériques mobiles. Si un paquet IPsec non pris en compte est reçu, le calcul ICV échoue et le paquet est abandonné.

Tableau 3 : Prise en charge des options IPv4 ou des en-têtes d’extension IPv6

Options ou en-têtes d’extension

SRX300, SRX320, SRX340, SRX345 et SRX550HM

SRX5400, SRX5600 et de SRX5800 de sécurité

ESP avec options IPv4

Soutenu

Soutenu

ESP avec en-têtes d’extension IPv6

Soutenu

Soutenu

AH avec options indémutables IPv4

Soutenu

Soutenu

AH avec les en-têtes d’extension inmutables IPv6

Soutenu

Soutenu

AH avec options mutables IPv4

Non pris en charge

Non pris en charge

AH avec les en-têtes d’extensions mutables IPv6

Non pris en charge

Non pris en charge

Calcul de la valeur Integrity Check dans IPv6

Le protocole AH vérifie l’intégrité du paquet IPv6 en calculant la valeur de contrôle d’intégrité (ICV) sur le contenu du paquet. L’ICV repose généralement sur un algorithme d’authentification comme MD5 ou SHA-1. Les calculs ICV IPv6 diffèrent de ceux d’IPv4 en termes de deux champs d’en-tête: un en-tête mutable et un en-tête d’extension facultatif.

Vous pouvez calculer l’ICV AH sur les champs d’en-tête IPv6 qui sont en transit ou avec une valeur prévisible dès leur 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 inémutables en transit). Vous pouvez calculer l’ESP ICV sur l’ensemble du paquet IPv6, à l’exception du nouvel en-tête IPv6 extérieur et des en-têtes d’extension optionnels.

Contrairement à IPv4, IPv6 dispose d’une méthode de balisage qui peut être mutable en transit. Les en-têtes d’extension optionnels IPv6 contiennent un indicateur qui indique la mutabilité. Cet indicateur détermine le traitement approprié.

Les options mutables IPv4 et les en-têtes d’extension IPv6 ne sont pas pris en charge par le protocole AH.

Construction d’en-tête dans les modes de 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 IPv4 interne ou IPv6 représentent les adresses finales de la source et de la destination. résume le lien entre l’en-tête IPv6 externe et l’en-tête IPv6 interne ou IPv4 pour les Tableau 4 modes de tunnel IPv6-in-IPv6 ou IPv4-in-IPv6. Dans les champs d’en-tête extérieurs, la construction « construite » signifie que la valeur du champ d’en-tête extérieur est construite indépendamment de la valeur du champ d’en-tête interne.

Tableau 4 : Construction d’en-têtes IPv6 pour les modes de tunnel IPv6-in-IPv6 et IPv4-in-IPv6

Champs d’en-tête

En-tête extérieur au niveau de l’encapsuleur

En-tête interne au Decapsulator

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.

durée de la charge utile

Construit.

Pas de changement.

en-tête suivant

AH, ESP et en-tête de routage.

Pas de changement.

limite du saut

64.

Decrement.

adresse src

Construit.

Pas de changement.

adresse dést

Construit.

Pas de changement.

En-têtes d’extension

Jamais copié.

Pas de changement.

Tableau 5 résume le lien entre l’en-tête IPv4 externe et l’en-tête IPv6 ou IPv4 interne pour les modes de tunnel IPv6-in-IPv4 ou IPv4-in-IPv4. Dans les champs d’en-tête extérieurs, la construction « construite » signifie que la valeur du champ d’en-tête extérieur est construite indépendamment de la valeur du champ d’en-tête interne.

Tableau 5 : Construction d’en-têtes IPv4 pour les modes de tunnel IPv6-in-IPv4 et IPv4-in-IPv4

Champs d’en-tête

En-tête extérieur

En-tête interne

Version

4.

Pas de changement.

longueur d’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.

(DF, MF)

Construit.

Pas de changement.

fragmentation de la mémoire

Construit.

Pas de changement.

Ttl

64.

Decrement.

Protocole

AH, ESP

Pas de changement.

Checksum

Construit.

Construit.

adresse src

Construit.

Pas de changement.

adresse dést

Construit.

Pas de changement.

Options

Jamais copié.

Pas de changement.

Pour le mode tunnel IPv6-in-IPv4, le bit Don’t Fragment (DF) est autorisé par défaut. Si les ou les options sont configurées au niveau [ ] de la hiérarchie pour le VPN IPv4 correspondant, le bit DF est configuré dans l’en-tête df-bit setdf-bit copy extérieur edit security ipsec vpn vpn-name IPv4.

Pour le mode tunnel IPv4-in-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 interne IPv4. Si elle n’est pas configurée pour l’en-tête IPv4 interne, le bit DF est autorisé dans l’en-tête df-bit extérieur IPv4.

Présentation de la configuration IPsec IPv6

Juniper Networks prend en charge les configurations manuelles et auto-IKE clés pré-partagées pour VPN IPv6 IPsec.

  • VPN manuel: dans une configuration VPN manuelle, les clés secrètes et les associations de sécurité (SA) sont manuellement configurées sur les points de terminaison du tunnel à l’aide du mécanisme de clé manuel. Pour créer un VPN IPv6 manuel IPsec, consultez l’exemple: Configuration d’un VPN IPsec IPv6 manuel .

  • Sécurité IKE VPN automatique: dans une configuration VPN IKE automatique, les clés secrètes et les SA sont automatiquement créés à l’aide du mécanisme d’IKE automatique. Pour mettre en place un réseau VPN virtuel IPv6 IKE, deux phases de négociation sont requises: les phases 1 et 2.

    • Phase 1: à cette étape, les participants établissent un canal sécurisé pour négocier les accords de sécurité IPsec.

    • Phase 2: à cette étape, 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 2, consultez Internet Key Exchange

Exemple: Configuration d’un VPN manuel IPv6 IPsec

Cet exemple montre comment configurer un VPN IPv6 IPsec manuel.

Conditions préalables

Avant de commencer:

Présentation

Dans une configuration VPN manuelle, les clés secrètes sont manuellement configurées sur les deux points d’extrémité IPsec.

Dans cet exemple, vous pouvez:

  • Configurez les paramètres d’authentification d’un VPN vpn-sunnyvale nommé.

  • Configurez les paramètres de chiffrement pour VPN-sunnyvale.

  • Indiquez l’interface sortante pour le sa.

  • Indiquez l’adresse IPv6 de l’pair.

  • Définir le protocole IPsec. Sélectionnez le protocole ESP parce que la configuration inclut à la fois l’authentification et le chiffrement.

  • Configurez un index de paramètres de sécurité (SPI).

Configuration

Procédure

CLI configuration rapide

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

Procédure étape par étape

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

Pour configurer des algorithmes de sécurité:

  1. Configurez les paramètres d’authentification.

  2. Configurez les paramètres de chiffrement.

  3. Indiquez l’interface sortante pour le sa.

  4. Indiquez l’adresse IPv6 de l’pair.

  5. Définir le protocole IPsec.

  6. Configurez une SPI.

Résultats

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

Vérification

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

Vérification des algorithmes de sécurité

But

Déterminez si des algorithmes de sécurité sont appliqués ou non.

Action

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

Exemple: Configuration d’un VPN IPv6 auto-IKE basé sur des stratégies

Cet exemple montre comment configurer un VPN IKE automatique IPv6 basé sur des stratégies afin de permettre le transfert sécurisé de données IPv6 entre les filiales et les bureaux de l’entreprise.

Les VPN basés sur des stratégies IPv6 sont pris en charge uniquement sur les équipements de SRX300, SRX320, SRX340, SRX345 et SRX550HM autonomes.

Conditions préalables

Cet exemple utilise le matériel suivant:

  • SRX300 de sécurité

Avant de commencer:

Présentation

Dans cet exemple, vous configurez un VPN IKE IPv6 basé sur des stratégies pour une filiale de Chicago, Illinois, car vous n’avez pas besoin d’économiser des ressources de tunnel ou de configurer de nombreuses stratégies de sécurité pour filtrer le trafic à travers le tunnel. Les utilisateurs des bureaux de Chicago utiliseront le VPN pour se connecter à leur siège social de Sunnyvale, Californie.

Figure 3 montre un exemple de topologie VPN basée IKE IPv6. Dans cette topologie, un SRX Series est situé à Sunnyvale et un autre équipement SRX Series (il peut s’agit d’un deuxième équipement SRX Series ou d’un équipement tiers) à Chicago.

Figure 3 : Topologie IKE VPN basée sur les stratégies IPv6Topologie IKE VPN basée sur les stratégies IPv6

Dans cet exemple, vous configurez des interfaces, un routeur par défaut IPv6, des zones de sécurité et des carnets d’adresses. Vous configurez ensuite IKE phase 1, IPsec phase 2, une stratégie de sécurité et les paramètres TCP-MSS. Voir Tableau 6Tableau 10 .

Tableau 6 : Informations sur l’interface, la zone de sécurité et le carnet d’adresses

Fonctionnalité

Nom

Paramètres de configuration

Interfaces

ge-0/0/14.0

2001:db8:1:1::/64

 

ge-0/0/15.0

2001:db8:0:4::/64

Zones de sécurité

Confiance

  • Tous les services système sont autorisés.

  • L’interface ge-0/0/14.0 est liée à cette zone.

 

Untrust

  • IKE système est le seul service système autorisé.

  • L’interface ge-0/0/15.0 est liée à cette zone.

Entrées du livre d’adresses

Sunnyvale

  • Cette adresse est celle du carnet d’adresses de la zone de confiance.

  • L’adresse d’entrée de ce carnet d’adresses est 2001:db8:1:2::/64.

 

Chicago

  • Cette adresse est celle du carnet d’adresses de la zone non protégée.

  • L’adresse de cette entrée du carnet d’adresses est 2001:db8:0:1::/64.

Tableau 7 : Paramètres de IKE de phase 1 pour IPv6

Fonctionnalité

Nom

Paramètres de configuration

Proposition

ipv6-ike-phase1-proposal

  • Méthode d’authentification: clés pré-partagées

  • Groupe Diffie-Hellman: group2

  • Algorithme d’authentification: sha1

  • Algorithme de chiffrement: aes-128-cbc

Politique

ipv6-ike-phase1-policy

  • Mode: Agressif

  • Référence de proposition: ipv6-ike-phase1-proposal

  • IKE authentification de la stratégie de phase 1: pré-shared-key ascii-text

Passerelle

gw-chicago

  • IKE une politique de sécurité: ipv6-ike-phase1-policy

  • Interface externe: ge-0/0/15.0

  • Adresse de la passerelle: 2001:db8:0:3::/64

Tableau 8 : Paramètres de configuration IPsec de phase 2 IPv6

Fonctionnalité

Nom

Paramètres de configuration

Proposition

ipv6-ipsec-phase2-proposal

  • Protocole: Esp

  • Algorithme d’authentification: hmac-sha1-96

  • Algorithme de chiffrement: aes-128-cbc

Politique

ipv6-ipsec-phase2-policy

  • Référence de proposition: ipv6-ipsec-phase2-proposal

  • Pfs: Diffie-Hellman group2

VPN

ipv6-ike-vpn-chicago

  • IKE de référence: gw-chicago

  • Référence de stratégie IPsec: ipv6-ipsec-phase2-policy

Tableau 9 : Paramètres de configuration de la stratégie de sécurité

But

Nom

Paramètres de configuration

Cette stratégie de sécurité autorise le trafic depuis la zone de confiance vers la zone non protégée.

ipv6-vpn-tr-untr

  • Critères de correspondance:

    • adresse source sunnyvale

    • adresse de destination chicago

    • application any

  • Action en cas d’autorisation: tunnel ipsec-vpn ipv6-ike-vpn-chicago

  • Action en cas d’autorisation: tunnel pair-policy ipv6-vpn-untr-tr

Cette stratégie de sécurité autorise le trafic entre la zone non protégée et la zone de confiance.

ipv6-vpn-untr-tr

  • Critères de correspondance:

    • adresse source chicago

    • destination sunnyvale

    • application any

  • Action en cas d’autorisation: tunnel ipsec-vpn ipv6-ike-vpn-chicago

  • Action en cas d’autorisation: tunnel pair-policy ipv6-vpn-tr-untr

Cette stratégie de sécurité autorise tout trafic de la zone de confiance à la zone non protégée.

Vous devez mettre la stratégie ipv6-vpn-tr-untr avant la politique de sécurité autoriser-any. Junos OS effectue une recherche de stratégie de sécurité en haut de la liste. Si la politique « permit-any » intervient avant la politique ipv6-vpn-tr-untr, l’ensemble du trafic en provenance de la zone de confiance sera en correspondance avec la politique « permit-any » et sera autorisé. Ainsi, aucun trafic ne sera jamais en correspondance avec la politique ipv6-vpn-tr-untr.

licence-any

  • Critères de correspondance:

    • adresse source tout

    • source-destination any

    • application any

  • Action: Permis

Tableau 10 : Paramètres de configuration TCP-MSS

But

Paramètres de configuration

TCP-MSS est négocié dans le cadre de la négociation à trois voies TCP et limite la taille maximale d’un segment TCP afin de mieux s’adapter aux MTU limites d’un réseau. Cette caractéristique est particulièrement importante pour le trafic VPN, car les coûts d’encapsulation IPsec, ainsi que les coûts d’ip et de trame, peuvent faire en mesure de dépasser les MTU de l’interface physique, générant ainsi la fragmentation. La fragmentation augmente l’utilisation de la bande passante et des ressources des équipements.

Nous recommandons une valeur de 1 350 comme point de départ pour la plupart des réseaux Ethernet avec MTU de 1 500 ou plus. Pour obtenir des performances optimales, vous devrez peut-être expérimenter avec différentes valeurs TCP-MSS. Par exemple, vous devrez peut-être modifier la valeur si l’un des équipements du chemin présente un niveau de MTU inférieur, ou s’il y a des frais supplémentaires tels que PPP ou relais de trames.

Valeur du MSS: 1350

Configuration

Configuration des informations basiques sur le réseau, la zone de sécurité et le carnet d’adresses

CLI configuration rapide

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

Procédure étape par étape

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

Pour configurer les informations de base du réseau, de la zone de sécurité et du carnet d’adresses:

  1. Configurer les informations de l’interface Ethernet.

  2. Configurez les informations de route statiques.

  3. Configurez la zone de sécurité non protégée.

  4. Attribuez une interface à la zone de sécurité non protégée.

  5. Indiquez les services système autorisés pour la zone de sécurité non protégée.

  6. Configurez la zone de sécurité de confiance.

  7. Attribuez une interface à la zone de sécurité de confiance.

  8. Indiquez les services système autorisés pour la zone de sécurité de confiance.

  9. Créez un carnet d’adresses et y ajoutez une zone.

  10. Créez un autre carnet d’adresses et y ajoutez une zone.

Résultats

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

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

Configuration des IKE

CLI configuration rapide

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

Procédure étape par étape

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

Pour configurer IKE:

  1. Créez la IKE phase 1.

  2. Définissez la méthode IKE d’authentification de proposition de sécurité.

  3. Définir la IKE groupe Diffie-Hellman.

  4. Définissez l’algorithme IKE d’authentification de proposition de sécurité.

  5. Définissez l’algorithme IKE de chiffrement de proposition.

  6. Créez une stratégie IKE phase 1.

  7. Définissez le IKE de la phase 1.

  8. Indiquez une référence à la IKE proposition d’accès.

  9. Définir la méthode IKE d’authentification de la stratégie de phase 1.

  10. Créez une IKE de phase 1 et définissez son interface externe.

  11. Définir la référence IKE de la phase 1.

  12. Attribuez une adresse IP à la passerelle IKE phase 1.

Résultats

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

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

Configuration d’IPsec

CLI configuration rapide

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

Procédure étape par étape

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

Pour configurer IPsec:

  1. Créez une proposition de phase 2 IPsec.

  2. Indiquez le protocole de proposition de phase 2 IPsec.

  3. Indiquez l’algorithme d’authentification de phase 2 IPsec.

  4. Indiquez l’algorithme de chiffrement de proposition de phase 2 IPsec.

  5. Créez la stratégie de phase 2 IPsec.

  6. Indiquez la référence de proposition de phase 2 IPsec.

  7. Indiquez le PFS de phase 2 IPsec pour utiliser le groupe Diffie-Hellman 2.

  8. Indiquez la IKE de l’accès.

  9. Indiquez la stratégie de phase 2 IPsec.

Résultats

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

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

Configuration des stratégies de sécurité

CLI configuration rapide

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

Procédure étape par étape

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

Pour configurer les stratégies de sécurité:

  1. Créez une stratégie de sécurité pour autoriser le trafic entre la zone de confiance et la zone non protégée.

  2. Créez une stratégie de sécurité pour autoriser le trafic entre la zone non protégée et la zone de confiance.

  3. Créez une stratégie de sécurité pour autoriser le trafic entre la zone de confiance et la zone non protégée.

  4. Réordez les stratégies de sécurité de sorte que la stratégie de sécurité vpn-tr-untr soit placée au-dessus de la politique de sécurité autoriser-any.

Résultats

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

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

Configuration TCP-MSS

CLI configuration rapide

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

Procédure étape par étape

Pour configurer les informations TCP-MSS:

  1. Configurer les informations TCP-MSS.

Résultats

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

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

Vérification

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

Vérification du statut de IKE phase 1

But

Vérifiez le statut IKE phase 1.

Action

Avant de commencer le processus de vérification, vous devez envoyer du trafic depuis un hôte de Sunnyvale à un hôte de Chicago. Pour les VPN basés sur des stratégies, un hôte distinct doit générer le trafic ; le trafic provenant de l’SRX Series ne correspond pas à la stratégie VPN. Il est recommandé d’utiliser le trafic test depuis un équipement distinct d’un côté du VPN et un autre de l’autre côté du VPN. Par exemple, lancer un ping à partir de 2001:db8:1:2::/64 à 2001:db8:0:1:/64.

À partir du mode opérationnel, saisissez 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.

Sens

La show security ike security-associations commande répertorie toutes les associations de IKE de phase 1 actives. Si aucun SA n’est répertorié, la mise en place de la phase 1 a été problématique. Vérifiez les paramètres IKE de stratégie et les paramètres de l’interface externe dans votre configuration.

Si les SA sont répertoriés, examinez les informations suivantes:

  • Index: cette valeur est unique pour chaque IKE SA, que vous pouvez utiliser dans la commande pour obtenir plus d’informations show security ike security-associations index index_number detail sur le SA.

  • Adresse distante: vérifiez que l’adresse IP distante est correcte.

  • État

    • UP— La phase SA 1 a été établie.

    • DOWN — Il y avait un problème pour établir la phase SA.

  • Mode: vérifiez que le mode correct est utilisé.

Vérifiez que la configuration de votre réseau est correcte:

  • Interfaces externes (l’interface doit être celle qui reçoit IKE paquets)

  • IKE stratégies de sécurité

  • Informations clés partagées

  • Paramètres de proposition de phase 1 (doivent correspondre aux deux pairs)

La show security ike security-associations index 5 detail commande répertorie les informations supplémentaires sur l’association de sécurité avec un index de 5:

  • Algorithmes d’authentification et de chiffrement utilisés

  • Durée de vie de la phase 1

  • Statistiques du trafic (peuvent être utilisées pour vérifier que le trafic circule correctement dans les deux directions)

  • Informations sur les rôles de l’initiateur et du répondant

    Le dépannage est le plus performant sur les pairs en utilisant le rôle de réponse.

  • Nombre de SA IPsec créés

  • Nombre de négociations de phase 2 en cours

Vérification du statut de phase 2 IPsec

But

Vérifier le statut de phase 2 IPsec.

Action

À partir du mode opérationnel, saisissez 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.

Sens

Le résultat de la commande show security ipsec security-associations répertorie les informations suivantes:

  • Le numéro d’ID est 2. Utilisez cette valeur avec la show security ipsec security-associations index commande pour obtenir plus d’informations sur ce sa particulier.

  • Une paire SA IPsec utilisant le port 500 indique qu’aucun NAT-traversal n’est implémenté. (NAT-traversal 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 lifesize in KB) sont affichées dans les deux directions. La valeur de 3 597/unlim indique que la durée de vie de la phase 2 expire en 3 597 secondes et qu’aucune lifesize n’a été spécifiée, ce qui signifie que sa durée de vie est illimitée. La durée de vie de la phase 2 peut varier par rapport à la phase 1, car la phase 2 ne dépend pas de la phase 1 après la mise en service du VPN.

  • La surveillance VPN n’est pas activée pour ce SA, comme indiqué par un trait d’union dans la colonne Mon. Si la surveillance VPN est activée, U (up) ou D (down) est répertorié.

  • Le système virtuel (vsys) est le système racine et il répertorie toujours 0.

Le résultat de la commande show security ipsec security-associations index 2 detail répertorie les informations suivantes:

  • Les identités locales et distantes font l’ID proxy du SA.

    Une insmatérialisation de l’ID proxy est l’une des raisons les plus courantes d’une défaillance de phase 2. Pour les VPN basés sur des stratégies, l’ID proxy est dérivée de la stratégie de sécurité. Les adresses locales et distantes sont dérivées des entrées du carnet d’adresses, et le service est dérivés de l’application configurée pour la stratégie. En cas d’échec de la phase 2 en raison d’une inmatérialisation 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 sont en correspondance avec les informations envoyées. Vérifiez le service pour vous assurer que les ports sont en correspondance avec les informations envoyées.

    Pour certains fournisseurs tiers, l’ID de proxy doit être saisi manuellement pour s’assortir.