Tunnels IPsec avec points de terminaison dynamiques

Le pair distant (dynamique) initie les négociations avec le routeur local (Juniper Networks). Le routeur local utilise les stratégies IKE et IPsec par défaut pour faire correspondre les propositions envoyées par l’homologue distant pour négocier les valeurs d’association de sécurité (SA). Les propositions implicites contiennent une liste de toutes les transformations prises en charge que le routeur local attend de tous les pairs dynamiques.

Si l’authentification par clé prépartagée est utilisée, la clé prépartagée est globale pour un ensemble de services. Lors de la recherche de la clé prépartagée pour l’homologue, le routeur local compare l’adresse source de l’homologue à toutes les clés prépartagées explicitement configurées dans cet ensemble de services. Si aucune correspondance n’est trouvée, le routeur local utilise la clé globale prépartagée pour l’authentification.

La phase 2 de l’authentification compare les identités proxy des hôtes et des réseaux protégés envoyées par l’homologue à une liste d’identités proxy configurées. L’identité de proxy acceptée est utilisée pour créer les règles dynamiques de chiffrement du trafic. Vous pouvez configurer les identités de proxy en incluant l’instruction allowed-proxy-pair dans le profil d’accès IKE. Si aucune entrée ne correspond, la négociation est rejetée.

Si vous ne configurez pas l’instruction allowed-proxy-pair , la valeur ANY(0.0.0.0/0)-ANY par défaut est appliquée et le routeur local accepte toutes les identités de proxy envoyées par l’homologue. Les adresses IPv4 et IPv6 sont acceptées, mais vous devez les configurer toutes manuellement.

Une fois la négociation de phase 2 terminée, le routeur crée les règles dynamiques et insère la route inverse dans la table de routage à l’aide de l’identité de proxy acceptée.

Une fois la négociation réussie avec l’homologue dynamique, le processus de gestion des clés (KMD) crée une règle dynamique pour le proxy de phase 2 accepté et l’applique au PIC AS ou multiservices local. Les adresses source et de destination sont spécifiées par le proxy accepté. Cette règle est utilisée pour chiffrer le trafic dirigé vers l’un des hôtes finaux dans l’identité de proxy de phase 2.

La règle dynamique inclut une ipsec-inside-interface valeur, qui est le nom d’interface affecté au tunnel dynamique. Les source-address valeurs et destination-address sont acceptées à partir de l’ID proxy. La match-direction valeur est input pour les ensembles de services de type saut suivant.

La recherche de règles pour les tunnels statiques n’est pas affectée par la présence d’une règle dynamique ; il est effectué dans l’ordre configuré. Lorsqu’un paquet est reçu pour un ensemble de services, les règles statiques sont toujours mises en correspondance en premier.

Les règles dynamiques sont mises en correspondance après l’échec de la correspondance des règles statiques.

Réponse aux messages DPD (Dead Peer Detection) Hello se déroule de la même manière avec des pairs dynamiques qu’avec des pairs statiques. Il n’est pas possible d’initier des messages DPD Hello à partir d’homologues dynamiques.

Les routes statiques sont automatiquement insérées dans la table de routage des réseaux et des hôtes protégés par un point de terminaison de tunnel distant. Ces hôtes et réseaux protégés sont connus sous le nom d’identités de proxy distant.

Chaque route est créée en fonction du réseau proxy distant et du masque envoyés par l’homologue et est insérée dans la table de routage appropriée après des négociations réussies de phase 1 et de phase 2.

La préférence de route pour chaque route inverse statique est 1. Cette valeur est nécessaire pour éviter tout conflit avec des routes similaires qui pourraient être ajoutées par le processus rpd (Routing Protocol Process).

Aucune route n’est ajoutée si l’adresse de proxy distant acceptée est la valeur par défaut (0.0.0.0/0). Dans ce cas, vous pouvez exécuter des protocoles de routage sur le tunnel IPsec pour apprendre les routes et ajouter des routes statiques pour le trafic que vous souhaitez protéger sur ce tunnel.

Pour les ensembles de services de type saut suivant, les itinéraires inverses incluent les sauts suivants pointant vers les emplacements spécifiés par l’instruction inside-service-interface .

La table de routage dans laquelle insérer ces routes dépend de l’emplacement inside-service-interface répertorié. Si ces interfaces sont présentes dans une instance VRF (VPN Routing and Forwarding), les routes sont ajoutées à la table VRF correspondante ; Sinon, les routes sont ajoutées à inet.0.

Vous ne pouvez configurer qu’un seul profil de tunnel par ensemble de services pour tous les homologues dynamiques. La clé prépartagée configurée dans le profil est utilisée pour l’authentification IKE de tous les homologues dynamiques se terminant dans cet ensemble de services. Vous pouvez également inclure l’instruction ike-policy pour faire référence à une stratégie IKE que vous définissez avec des valeurs d’identification spécifiques ou un caractère générique (l’option any-remote-id ). Vous configurez la stratégie IKE au niveau de la [edit services ipsec-vpn ike] hiérarchie.

Le profil de tunnel IKE spécifie toutes les informations nécessaires pour mener à bien la négociation IKE. Chaque protocole possède sa propre hiérarchie d’instructions dans l’instruction client pour configurer les paires de valeurs d’attributs spécifiques au protocole, mais une seule configuration client est autorisée pour chaque profil. Voici la configuration au niveau de la [edit access] hiérarchie ; Pour plus d’informations sur les profils d’accès, reportez-vous à la bibliothèque d’administration de Junos OS pour les équipements de routage.

Les déclarations suivantes composent le profil IKE :

• allowed-proxy-pair: au cours de la phase 2 de la négociation IKE, l’homologue distant fournit son adresse réseau (remote) et l’adresse réseau de son homologue (local). Étant donné que plusieurs tunnels dynamiques sont authentifiés via le même mécanisme, cette instruction doit inclure la liste des combinaisons possibles. Si l’homologue dynamique ne présente pas de combinaison valide, la négociation IKE de phase 2 échoue.

  Par défaut, remote 0.0.0.0/0 local 0.0.0.0/0 est utilisé si aucune valeur n’est configurée. Les formats d’adresse IPv4 et IPv6 sont pris en charge dans cette configuration, mais il n’existe pas d’adresses IPv6 par défaut. Vous devez spécifier même 0::0/0.

• pre-shared-key: clé utilisée pour authentifier l’homologue dynamique lors de la négociation de la phase 1 d’IKE. Cette clé est connue des deux extrémités grâce à un mécanisme sécurisé hors bande. Vous pouvez configurer la valeur au format ou ascii-text au hexadecimal format . C’est une valeur obligatoire.

• ike-policy—Stratégie qui définit les valeurs d’identification à distance correspondant aux homologues dynamiques autorisés ; Peut contenir une valeur any-remote-id générique à utiliser uniquement dans les configurations dynamiques de point de terminaison.

• interface-id: identificateur d’interface, attribut obligatoire utilisé pour dériver les informations d’interface des services logiques pour la session.

• ipsec-policy: nom de la stratégie IPsec qui définit les informations de stratégie IPsec pour la session. Vous définissez la stratégie IPsec au niveau de la [edit services ipsec-vpn ipsec policy policy-name] hiérarchie. Si aucune stratégie n’est définie, toute stratégie proposée par l’homologue dynamique est acceptée.

Pour terminer la configuration, vous devez vous référer au profil d’accès IKE configuré au niveau de la [edit access] hiérarchie. Pour ce faire, incluez l’instruction ike-access-profile au niveau de la [edit services service-set name ipsec-vpn-options] hiérarchie :

L’instruction ike-access-profile doit faire référence au même nom que l’instruction que vous avez configurée pour l’accès profile IKE au niveau de la [edit access] hiérarchie. Vous ne pouvez référencer qu’un seul profil d’accès dans chaque ensemble de services. Ce profil est utilisé pour négocier des associations de sécurité IKE et IPsec avec des pairs dynamiques uniquement.

Toutes les interfaces référencées par l’instruction inside-service-interface dans un ensemble de services doivent appartenir à la même instance VRF.

Vous pouvez configurer un identificateur d’interface pour un groupe d’homologues dynamiques, qui spécifie la ou les interfaces logiques de services adaptatifs qui participent à la négociation IPsec dynamique. En affectant le même identificateur d’interface à plusieurs interfaces logiques, vous pouvez créer un pool d’interfaces à cette fin. Pour configurer un identificateur d’interface, incluez l’instruction ipsec-interface-id et l’instruction dedicated ou shared au niveau de la [edit interfaces interface-name unit logical-unit-number dial-options] hiérarchie :

Si vous spécifiez l’identificateur d’interface dans l’instruction dial-options , cette interface logique fait partie du pool identifié par l’instruction ipsec-interface-id .

Si vous configurez shared le mode, il permet de partager une interface logique entre plusieurs tunnels. L’instruction dedicated spécifie que l’interface logique est utilisée en mode dédié, ce qui est nécessaire lorsque vous configurez un tunnel de type lien IPsec. Vous devez inclure l’instruction dedicated lorsque vous spécifiez une ipsec-interface-id valeur.

Le logiciel inclut des propositions IKE et IPsec implicites par défaut pour correspondre aux propositions envoyées par les pairs dynamiques. Les valeurs sont indiquées dans le tableau 1 ; Si plusieurs valeurs sont affichées, la première valeur est la valeur par défaut.

À partir de Junos OS version 16.2R1, vous pouvez distribuer des tunnels IPsec avec des points de terminaison dynamiques entre plusieurs MS-MIC ou entre plusieurs PIC de service d’un MS-MPC. Vous configurez la distribution du tunnel en configurant un ensemble de services IPsec de saut suivant pour l’interface multiservices (ms-) de chaque PIC de service. À partir de Junos OS version 17.1R1, vous pouvez également distribuer des tunnels IPsec avec des points de terminaison dynamiques entre les interfaces multiservices agrégées (AMS) de MS-MICs ou MS-MPC en configurant un ensemble de services IPsec de saut suivant pour chaque interface AMS.

Vous pouvez ajouter ultérieurement du matériel PIC de service au routeur MX Series et inclure le PIC de service dans la distribution du tunnel en ajoutant simplement un autre ensemble de services, sans avoir à modifier la configuration des homologues IPsec.

Pour configurer tunnel distribution, procédez comme suit lors de la configuration des tunnels IPsec de point de terminaison dynamiques :

• Configurez un ensemble de services IPsec de saut suivant pour chaque interface de services ou interface AMS utilisée par le tunnel IPsec de point de terminaison dynamique (voir Référencement du profil d’accès IKE dans un ensemble de services). Tous les ensembles de services doivent :

  • Utilisez le même type d’interface de services, soit des interfaces multiservices (ms-), soit des interfaces AMS (ams-).

  • Avoir une interface dans l’instruction outside-service qui se trouve dans la même instance VRF (VPN Routing and Forwarding) que les interfaces des autres ensembles de services.

  • Avoir la même local-gateway adresse IP.

  • Portent le même ike-access-profile nom.

• Lors de la configuration de l’identificateur d’interface (voir Configuration de l’identificateur d’interface), le ipsec-interface-id identifier doit être configuré :

  • Uniquement sous les interfaces qui apparaissent dans les inside-service-set instructions des ensembles de services.

  • Avec dedicated pour toutes les interfaces, ou avec shared pour toutes les interfaces.

  • Sous une seule unité partagée d’une interface.

  • Uniquement sous les interfaces configurées avec service-domain inside.

  • Uniquement sous les interfaces qui se trouvent dans le même VRF.