Présentation du VPN IPsec

Voici quelques-unes des topologies VPN IPsec prises en charge par le système d’exploitation Junos :

• VPN de site à site : connecte deux sites d’une organisation et permet des communications sécurisées entre les sites.

• VPN en étoile : connectent les filiales au siège social au sein d’un réseau d’entreprise. Vous pouvez également utiliser cette topologie pour connecter des rayons entre eux en envoyant du trafic via le hub.

• VPN d’accès à distance : permet aux utilisateurs travaillant à domicile ou en déplacement de se connecter au siège de l’entreprise et à ses ressources. Cette topologie est parfois appelée end-to-site tunnel.

Tableau 2 résume les différences entre les VPN basés sur les stratégies et les VPN basés sur le routage.

Un tunnel VPN IPsec se compose de la configuration du tunnel et de la sécurité appliquée. Lors de la configuration du tunnel, les homologues établissent des associations de sécurité (SA), qui définissent les paramètres de sécurisation du trafic entre eux. (Reportez-vous à la section Présentation d’IPsec.) Une fois le tunnel établi, IPsec protège le trafic envoyé entre les deux points de terminaison du tunnel en appliquant les paramètres de sécurité définis par les SA lors de l’installation du tunnel. Dans l’implémentation de Junos OS, IPsec est appliqué en mode tunnel, qui prend en charge les protocoles ESP (Encapsulating Security Payload) et AH (Authentication Header).

Cette rubrique comprend les sections suivantes :

Traitement des paquets en mode tunnel

IPsec fonctionne selon l’un des deux modes suivants : transport ou tunnel. Lorsque les deux extrémités du tunnel sont des hôtes, vous pouvez utiliser l’un ou l’autre mode. Lorsqu’au moins un des points de terminaison d’un tunnel est une passerelle de sécurité, comme un routeur ou un pare-feu Junos OS, vous devez utiliser le mode tunnel. Les équipements Juniper Networks fonctionnent toujours en mode tunnel pour les tunnels IPsec.

En mode tunnel, l’intégralité du paquet IP d’origine (charge utile et en-tête) est encapsulée dans une autre charge utile IP, et un nouvel en-tête lui est ajouté, comme illustré à Figure 1la . L’intégralité du paquet d’origine peut être chiffrée, authentifiée ou les deux. Avec le protocole d’en-tête d’authentification (AH), l’AH et les nouveaux en-têtes sont également authentifiés. Avec le protocole ESP (Encapsulating Security Payload), l’en-tête ESP peut également être authentifié.

Figure 1 : Tunnel Mode

Dans un VPN de site à site, les adresses source et de destination utilisées dans le nouvel en-tête sont les adresses IP de l’interface sortante. Reportez-vous à la section Figure 2.

Figure 2 : VPN de site à site en mode tunnel

Dans un VPN commuté, il n’y a pas de passerelle de tunnel à l’extrémité du client d’accès à distance VPN du tunnel ; Le tunnel s’étend directement jusqu’au client lui-même (reportez-vous à la section Figure 3). Dans ce cas, sur les paquets envoyés par le client d’accès à distance, le nouvel en-tête et l’en-tête d’origine encapsulé ont la même adresse IP : celui de l’ordinateur du client.

Certains clients VPN, tels que Netscreen-Remote , utilisent une adresse IP interne virtuelle (également appelée « adresse collante »). Netscreen-Remote vous permet de définir l’adresse IP virtuelle. Dans ce cas, l’adresse IP interne virtuelle est l’adresse IP source dans l’en-tête du paquet d’origine du trafic provenant du client, et l’adresse IP que le FAI attribue dynamiquement au client d’accès à distance est l’adresse IP source dans l’en-tête externe.

Figure 3 : VPN commuté en mode tunnel

Dans les appareils SRX5400, SRX5600 et SRX5800, IKE assure la gestion des tunnels pour IPsec et authentifie les entités finales. IKE effectue un échange de clés Diffie-Hellman (DH) pour générer un tunnel IPsec entre les périphériques réseau. Les tunnels IPsec générés par IKE sont utilisés pour chiffrer, déchiffrer et authentifier le trafic utilisateur entre les périphériques réseau au niveau de la couche IP.

Le VPN est créé en répartissant la charge de travail IKE et IPsec entre les différentes unités de traitement des services (SPU) de la plate-forme. Pour les tunnels de site à site, l’unité SPU la moins chargée est choisie comme SPU d’ancrage. Si plusieurs SPU ont la même plus petite charge, n’importe lequel d’entre eux peut être choisi comme SPU d’ancrage. Ici, la charge correspond au nombre de passerelles de site à site ou de tunnels VPN manuels ancrés sur un SPU. Pour les tunnels dynamiques, les tunnels dynamiques nouvellement établis utilisent un algorithme de tourniquet circulaire pour sélectionner le SPU.

Dans IPsec, la charge de travail est distribuée par le même algorithme que celui qui distribue l’IKE. La SA de phase 2 d’une paire de points de terminaison de tunnel VPN donnée est la propriété exclusive d’un SPU particulier, et tous les paquets IPsec appartenant à cette SA de phase 2 sont transférés à l’USP d’ancrage de cette SA pour le traitement IPsec.

Plusieurs sessions IPsec (Phase 2 SA) peuvent fonctionner sur une ou plusieurs sessions IKE. Le SPU sélectionné pour l’ancrage de la session IPsec est basé sur le SPU qui ancre la session IKE sous-jacente. Par conséquent, toutes les sessions IPsec qui s’exécutent sur une seule passerelle IKE sont gérées par le même SPU et ne sont pas équilibrées en charge sur plusieurs SPU.

Tableau 3 montre un exemple de gamme SRX5000 avec trois SPU exécutant sept tunnels IPsec sur trois passerelles IKE.

Les trois SPU ont une charge égale d’une passerelle IKE chacun. Si une nouvelle passerelle IKE est créée, SPU0, SPU1 ou SPU2 peut être sélectionné pour ancrer la passerelle IKE et ses sessions IPsec.

La configuration et le démantèlement de tunnels IPsec existants n’affectent pas la session IKE sous-jacente ni les tunnels IPsec existants.

Utilisez la commande suivante show pour afficher le nombre actuel de tunnels par SPU : show security ike tunnel-map.

Utilisez l’option summary de la commande pour afficher les points d’ancrage de chaque passerelle : show security ike tunnel-map summary.

Dans un cluster à châssis SRX5400, SRX5600 ou SRX5800, vous pouvez insérer de nouveaux SPC sur les équipements sans affecter ni perturber le trafic sur les tunnels VPN IKE ou IPsec existants. Lorsque vous insérez un nouveau SPC dans chaque châssis du cluster, les tunnels existants ne sont pas affectés et le trafic continue de circuler sans interruption.

À partir de Junos OS version 19.4R1, sur tous les clusters de châssis de la gamme SRX5000, vous pouvez insérer une nouvelle carte SRX5K-SPC3 (SPC3) ou SRX5K-SPC-4-15-320 (SPC2) dans un châssis existant contenant une carte SPC3. Vous ne pouvez insérer les cartes que dans un emplacement plus haut que la carte SPC3 existante sur le châssis. Vous devez redémarrer le noeud après l’insertion de SPC3 pour activer la carte. Une fois le redémarrage du nud terminé, les tunnels IPsec sont distribués sur les cartes.

Toutefois, les tunnels existants ne peuvent pas utiliser la puissance de traitement des unités de traitement de services (SPU) dans les nouveaux SPC. Une nouvelle SPU peut ancrer de nouveaux tunnels dynamiques et de site à site. Il n’est toutefois pas garanti que les tunnels nouvellement configurés soient ancrés sur un nouveau SPU.

Les tunnels de site à site sont ancrés sur différents SPU selon un algorithme d’équilibrage de charge. L’algorithme d’équilibrage de charge dépend des threads de flux numériques utilisés par chaque USP. Les tunnels appartenant aux mêmes adresses IP de passerelle locale et distante sont ancrés sur le même SPU sur des threads RT de flux différents utilisés par le SPU. L’USP avec la plus petite charge est choisie comme SPU d’ancrage. Chaque SPU gère le nombre de threads RT de flux hébergés dans ce SPU particulier. Le nombre de threads RT de flux hébergés sur chaque SPU varie en fonction du type de SPU.

Facteur de charge du tunnel = Nombre de tunnels ancrés sur le SPU / Nombre total de threads RT de flux utilisés par le SPU.

Les tunnels dynamiques sont ancrés sur différents SPU selon un algorithme de tourniquet (round-robin). Il n’est pas garanti que les tunnels dynamiques nouvellement configurés soient ancrés sur le nouveau SPC.

À compter des versions 18.2R2 et 18.4R1 de Junos OS, toutes les fonctionnalités VPN IPsec existantes actuellement prises en charge sur SRX5K-SPC3 (SPC3) uniquement seront prises en charge sur les équipements SRX5400, SRX5600 et SRX5800 lorsque les cartes SRX5K-SPC-4-15-320 (SPC2) et SPC3 sont installées et fonctionnent sur l’équipement en mode cluster de châssis ou en mode autonome.

Lorsque les cartes SPC2 et SPC3 sont installées, vous pouvez vérifier le mappage de tunnel sur différents SPU à l’aide de la show security ipsec tunnel-distribution commande.

Utilisez la commande show security ike tunnel-map pour afficher le mappage de tunnel sur différents SPU avec uniquement une carte SPC2 insérée. La commande show security ike tunnel-map n’est pas valide dans un environnement où des cartes SPC2 et SPC3 sont installées.

Insertion de la carte SPC3 : Lignes directrices et limites :

• Dans un cluster de châssis, si l’un des noeuds a 1 carte SPC3 et l’autre noeud a 2 cartes SPC3, le basculement vers le noeud qui a 1 carte SPC3 n’est pas pris en charge.

• Vous devez insérer le SPC3 ou le SPC2 dans un châssis existant dans un emplacement plus haut qu’un SPC3 actuel présent dans un emplacement inférieur.

• Pour que SPC3 ISHU fonctionne, vous devez insérer la nouvelle carte SPC3 dans le numéro d’emplacement supérieur.

• Sur SRX5800 groupe de châssis, vous ne devez pas insérer la carte SPC3 dans l’emplacement le plus élevé (emplacement n° 11) en raison de la limite d’alimentation et de répartition de la chaleur.

• Nous ne prenons pas en charge l’élimination à chaud SPC3.

Tableau 4 résume la gamme SRX5000 avec carte SPC2 ou SPC3 qui prend en charge kmd ou iked traite :

Gamme SRX5000 avec la carte SRX5K-SPC3 (carte de traitement des services), les plates-formes de milieu de gamme SRX (pare-feu SRX4100, SRX4200, SRX1500 et SRX4600 Series) et nécessite Pare-feu virtuel vSRX junos-ike package en tant que logiciel de plan de contrôle pour installer et activer les fonctionnalités VPN IPsec.

• Sur la gamme SRX5000 avec RE3, par défaut, le package est installé dans Junos OS versions 20.1R2, 20.2R2, 20.3R2, junos-ike 20.4R1 et ultérieures. Par conséquent, iked le ikemd processus s’exécute par défaut sur le moteur de routage au lieu du démon de gestion de clé IPsec (kmd). La gamme SRX5000 avec SRX5K-SPC3 décharge les opérations cryptographiques sur le moteur cryptographique matériel.

• Les plates-formes de milieu de gamme SRX, qui couvrent les pare-feu SRX1500, SRX4100, SRX4200 et SRX4600 Series, déchargent les opérations cryptographiques DH, RSA et ECDSA sur le moteur cryptographique matériel avec des équipements exécutant junos-ike des logiciels. Cette fonctionnalité est disponible à partir de Junos OS version 23.2R1 sur les équipements sur lesquels junos-ike le package est installé. Les périphériques qui continuent d’exécuter le logiciel hérité iked (processus kmd) ne prennent pas en charge cette fonctionnalité.

• Sur le pare-feu virtuel vSRX, le thread CPU du plan de données décharge les opérations DH, RSA et ECDSA. L’accélération matérielle n’est pas disponible sur ces appareils. Cette fonctionnalité est disponible à partir de Junos OS version 23.2R1 avec junos-ike le package installé sur le périphérique.

Le Tableau 5 décrit la prise en charge de l’accélération matérielle pour divers chiffrements :

Pour installer le package IKE Junos sur votre pare-feu SRX Series, utilisez la commande suivante :

Pour utiliser kmd process afin d’activer les fonctionnalités VPN IPsec sur la gamme SRX5000 sans carte SPC3, vous devez exécuter la request system software delete junos-ike commande. Après avoir exécuté la commande, redémarrez l’appareil.

Pour vérifier le package installé junos-ike , utilisez la commande suivante :

Les deux processus iked et ikemd prennent en charge les fonctionnalités VPN IPsec sur les pare-feu SRX Series. Une seule instance de et ikemd exécuter sur le moteur de iked routage à la fois.

Par défaut, junos-ike le package est installé dans Junos OS version 19.4R1 et ultérieures pour SRX5K-SPC3 avec RE3. Les processus et ikemd s’exécutant iked sur le moteur de routage sont disponibles avec ce package. Sur le SRX5K-SPC3 avec RE2, il s’agit d’un package optionnel qui doit être installé explicitement.

Pour redémarrer ikemd le processus dans le moteur de routine, utilisez la restart ike-config-management commande.

Pour redémarrer iked le processus dans le moteur de routage, utilisez la restart ike-key-management commande.

Tableau 6 affiche les détails des versions de Junos OS où junos-ike le package est introduit.

Pour utiliser les fonctionnalités VPN IPsec à l’aide de l’ancien kmd processus sur la gamme SRX5000 sans carte SRX5K-SPC3, vous devez exécuter la request system software delete junos-ike commande et redémarrer l’équipement.

Sur les pare-feu SRX Series, anti-replay-window est activé par défaut avec une valeur de taille de fenêtre de 64.

Sur la gamme SRX Series 5000 avec cartes SPC3 installées, vous pouvez configurer la taille dans la anti-replay-window plage de 64 à 8192 (puissance de 2). Pour configurer la taille de la fenêtre, utilisez la nouvelle anti-replay-window-size option. Un paquet entrant est validé pour une attaque par rejeu en fonction de ce anti-replay-window-size qui est configuré.

Vous pouvez configurer replay-window-size à deux niveaux différents :

• Global level: configuré au niveau de la hiérarchie [edit security ipsec].

  Par exemple :

• VPN object: configuré au niveau de la hiérarchie [edit security ipsec vpn vpn-name ike].

  Par exemple :

Si l’anti-relecture est configurée aux deux niveaux, la taille de la fenêtre configurée pour un niveau d’objet VPN est prioritaire sur la taille de la fenêtre configurée au niveau global. Si l’anti-relecture n’est pas configurée, la taille de la fenêtre est de 64 par défaut.

Pour désactiver l’option de fenêtre anti-relecture sur un objet VPN, utilisez la commande au niveau de la set no-anti-replay hiérarchie [edit security ipsec vpn vpn-name ike]. Vous ne pouvez pas désactiver l’anti-rejeu au niveau global.

Vous ne pouvez pas configurer à la fois anti-replay-window-size et no-anti-replay sur un objet VPN.

Si vous créez deux tunnels VPN qui se terminent au niveau d’un périphérique, vous pouvez configurer une paire de routes afin que le périphérique dirige le trafic sortant d’un tunnel vers l’autre tunnel. Vous devez également créer une stratégie pour autoriser le trafic à passer d’un tunnel à l’autre. Un tel arrangement est connu sous le nom de VPN en étoile. (Reportez-vous à la section Figure 4.)

Vous pouvez également configurer plusieurs VPN et acheminer le trafic entre deux tunnels.

Les pare-feu SRX Series prennent uniquement en charge la fonctionnalité de réseau en étoile basée sur le routage.

Figure 4 : Plusieurs tunnels dans une configuration VPN en étoile