Tunnels IPsec avec points de terminaison dynamiques

L’homologue distant (homologue dynamique) entame les négociations avec le routeur local (Juniper Networks). Le routeur local utilise les stratégies IKE et IPsec par défaut pour correspondre aux 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 homologues 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 fait correspondre l’adresse source de l’homologue avec 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é prépartagée globale pour l’authentification.

La phase 2 de l’authentification fait correspondre les identités proxy des hôtes et réseaux protégés envoyés par l’homologue avec 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 manuellement.

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

Après une 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 permet de 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 de proxy. La match-direction valeur correspond input aux 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 ; Elle s’effectue 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.

Les messages hello Response to Dead Peer Detection (DPD) s’effectuent de la même manière avec des homologues dynamiques qu’avec des homologues 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 pour les réseaux et les 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 distants.

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 correspondante après des négociations réussies des phases 1 et 2.

La préférence d’itinéraire pour chaque itinéraire 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 de protocole de routage (rpd).

Aucune route n’est ajoutée si l’adresse du 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 itinéraires dépend de l’emplacement inside-service-interface indiqué. 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 référencer 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 terminer la négociation IKE. Chaque protocole possède sa propre hiérarchie d’instructions dans l’instruction client pour configurer les paires attribut-valeur 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 périphériques de routage.

Les énoncés suivants constituent 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 tous deux 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 IKE phase 1. Cette clé est connue des deux extrémités grâce à un mécanisme de sécurité hors bande. Vous pouvez configurer la valeur dans hexadecimal ou ascii-text au format. Il s’agit d’une valeur obligatoire.

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

• interface-id: identificateur d’interface, attribut obligatoire utilisé pour dériver les informations de l’interface de services logiques de 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 référencer le profil d’accès IKE configuré au niveau de la [edit access] hiérarchie. Pour ce faire, incluez l’instruction au ike-access-profile 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é uniquement pour négocier les associations de sécurité IKE et IPsec avec des homologues dynamiques.

Toutes les interfaces référencées par l’instruction inside-service-interface au sein d’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 des 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 à cet effet. Pour configurer un identificateur d’interface, incluez l’instruction et l’instruction ipsec-interface-id dedicated or shared au niveau de la [edit interfaces interface-name unit logical-unit-number dial-options] hiérarchie :

La spécification de l’identificateur d’interface dans l’instruction dial-options fait de cette interface logique une 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 dans un 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 homologues 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 la version 16.2R1 de Junos OS, vous pouvez distribuer des tunnels IPsec avec des points de terminaison dynamiques entre plusieurs MS-MIC ou plusieurs PIC de service d’un MS-MPC. Pour configurer la distribution des tunnels, configurez 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) des MS-MIC 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 de tunnel en ajoutant simplement un autre ensemble de services, sans avoir à modifier la configuration des homologues IPsec.

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

• Configurez un ensemble de services IPsec de saut suivant pour chaque interface de services ou interface AMS utilisée par le tunnel IPsec du 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.

  • Avoir 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.

  • With dedicated pour toutes les interfaces, ou with shared pour toutes les interfaces.

  • Sous pas plus d’une 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.