Tunnels VPN IPsec avec clusters de châssis
Les pare-feu SRX Series prennent en charge les tunnels VPN IPsec dans une configuration de cluster de châssis. Dans un cluster actif/passif en châssis, tous les tunnels VPN se terminent sur le même nœud. Dans un cluster de châssis actif/actif, les tunnels VPN peuvent se terminer sur l’un ou l’autre des nuds.
Comprendre les clusters de châssis VPN IPsec à double sauvegarde active
Dans un cluster actif/passif en châssis, tous les tunnels VPN se terminent sur le même nœud, comme illustré à Figure 1la .
Dans un cluster de châssis actif/actif, les tunnels VPN peuvent se terminer sur l’un ou l’autre des nuds. Les deux noeuds du cluster de châssis peuvent faire transiter activement le trafic via des tunnels VPN sur les deux noeuds en même temps, comme illustré à la .Figure 2 Ce déploiement est connu sous le nom de clusters à double châssis VPN IPsec à sauvegarde active.
Les fonctionnalités suivantes sont prises en charge avec deux clusters de châssis VPN IPsec à sauvegarde active :
VPN basés sur le routage uniquement. Les VPN basés sur des stratégies ne sont pas pris en charge.
IKEv1 et IKEv2.
Authentification par certificat numérique ou par clé pré-partagée.
IKE et interfaces de tunnel sécurisées (st0) dans les routeurs virtuels.
Traversée de traduction d’adresses réseau (NAT-T).
Surveillance VPN.
Détection des pairs morts.
Mise à niveau du logiciel en service (ISSU).
Insertion de cartes de traitement des services (SPC) sur un équipement de cluster de châssis sans interrompre le trafic sur les tunnels VPN existants. Reportez-vous à la section Prise en charge du VPN pour l’insertion de cartes de traitement des services.
Protocoles de routage dynamique.
Interfaces de tunnel sécurisées (st0) configurées en mode point à multipoint.
AutoVPN avec interfaces st0 en mode point à point avec sélecteurs de trafic.
Modes tunnel IPv4-en-IPv4, IPv6-en-IPv4, IPv6-en-IPv6 et IPv4-en-IPv6.
Trafic fragmenté.
L’interface de bouclage peut être configurée en tant qu’interface externe pour le VPN.
Il n’est pas possible de configurer deux clusters de châssis VPN IPsec à sauvegarde active avec des flux en mode Z. Les flux en mode Z se produisent lorsque le trafic entre dans une interface sur un nœud de cluster châssis, passe par la liaison de structure et sort par une interface sur l’autre nœud de cluster.
Voir également
Exemple : Configuration des groupes de redondance pour les interfaces de bouclage
Cet exemple montre comment configurer un groupe de redondance (RG) pour une interface de bouclage afin d’éviter toute défaillance VPN. Les groupes de redondance permettent de regrouper des interfaces dans un groupe à des fins de basculement dans une configuration de cluster de châssis.
Conditions préalables
Cet exemple utilise le matériel et les logiciels suivants :
Une paire de clusters de châssis pris en charge SRX Series pare-feu
Un appareil SSG140 ou équivalent
Deux commutateurs
Junos OS version 12.1x44-D10 ou ultérieure pour pare-feu SRX Series
Avant de commencer :
Comprendre les interfaces Ethernet redondantes des clusters de châssis. Reportez-vous au Guide de l’utilisateur du cluster de châssis pour les équipements SRX Series.
Présentation
Une passerelle Internet Key Exchange (IKE) a besoin d’une interface externe pour communiquer avec un appareil homologue. Dans une configuration de cluster de châssis, le nœud sur lequel l’interface externe est active sélectionne une unité de traitement des services (SPU) pour prendre en charge le tunnel VPN. Les paquets IKE et IPsec sont traités sur ce SPU. Par conséquent, l’interface externe active décide du SPU d’ancrage.
Dans une configuration de cluster de châssis, l’interface externe est une interface Ethernet redondante. Une interface Ethernet redondante peut tomber en panne lorsque ses interfaces physiques (enfants) sont hors service. Vous pouvez configurer une interface de bouclage en tant qu’interface physique alternative pour atteindre la passerelle homologue. Les interfaces de bouclage peuvent être configurées sur n’importe quel groupe de redondance. Cette configuration du groupe de redondance n’est vérifiée que pour les paquets VPN, car seuls les paquets VPN doivent trouver l’unité unique d’ancrage via l’interface active.
Vous devez configurer lo0.x dans un routeur virtuel personnalisé, car lo0.0 est dans le routeur virtuel par défaut et une seule interface de bouclage est autorisée dans un routeur virtuel.
Figure 3 présente un exemple de topologie VPN de cluster de châssis loopback. Dans cette topologie, le périphérique de cluster de châssis du pare-feu SRX Series se trouve à Sunnyvale, en Californie. Le périphérique de cluster châssis du pare-feu SRX Series fonctionne comme une passerelle unique dans cette configuration. L’équipement SSG Series (ou un équipement tiers) est situé à Chicago, Illinois. Cet équipement agit comme un appareil homologue du cluster SRX et facilite la création d’un tunnel VPN.
Configuration
Procédure
Configuration rapide de l’interface de ligne de commande
Pour configurer rapidement cette section de l’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 lo0 redundant-pseudo-interface-options redundancy-group 1 set interfaces lo0 unit 1 family inet address 10.3.3.3/30 set routing-instances vr1 instance-type virtual-router set routing-instances vr1 interface lo0.1 set routing-instances vr1 interface reth0.0 set routing-instances vr1 interface reth1.0 set routing-instances vr1 interface st0.0 set routing-instances vr1 routing-options static route 192.168.168.1/24 next-hop st0.0 set security ike policy ike-policy1 mode main set security ike policy ike-policy1 proposal-set standard set security ike policy ike-policy1 pre-shared-key ascii-text "$ABC123" set security ike gateway t-ike-gate ike-policy ike-policy1 set security ike gateway t-ike-gate address 10.2.2.2 set security ike gateway t-ike-gate external-interface lo0.1 set security ipsec proposal p2-std-p1 authentication-algorithm hmac-sha1-96 set security ipsec proposal p2-std-p1 encryption-algorithm 3des-cbc set security ipsec proposal p2-std-p1 lifetime-seconds 180 set security ipsec proposal p2-std-p2 authentication-algorithm hmac-sha1-96 set security ipsec proposal p2-std-p2 encryption-algorithm aes-128-cbc set security ipsec proposal p2-std-p2 lifetime-seconds 180 set security ipsec policy vpn-policy1 perfect-forward-secrecy keys group2 set security ipsec policy vpn-policy1 proposals p2-std-p1 set security ipsec policy vpn-policy1 proposals p2-std-p2 set security ipsec vpn t-ike-vpn bind-interface st0.0 set security ipsec vpn t-ike-vpn ike gateway t-ike-gate set security ipsec vpn t-ike-vpn ike proxy-identity local 10.10.10.1/24 set security ipsec vpn t-ike-vpn ike proxy-identity remote 192.168.168.1/24 set security ipsec vpn t-ike-vpn ike ipsec-policy vpn-policy1
Procédure étape par étape
Pour configurer un groupe de redondance pour une interface de bouclage :
Configurez l’interface de bouclage dans un groupe de redondance.
[edit interfaces] user@host# set lo0 redundant-pseudo-interface-options redundancy-group 1
Configurez l’adresse IP de l’interface de bouclage.
[edit interfaces] user@host# set lo0 unit 1 family inet address 10.3.3.3/30
Configurez les options de routage.
[edit routing-instances] user@host# set vr1 instance-type virtual-router user@host# set vr1 interface lo0.1 user@host# set vr1 interface reth0.0 user@host# set vr1 interface reth1.0 user@host# set vr1 interface st0.0 user@host# set vr1 routing-options static route 192.168.168.1/24 next-hop st0.0
Configurez l’interface de bouclage en tant qu’interface externe pour la passerelle IKE.
[edit security ike] user@host# set policy ike-policy1 mode main user@host# set policy ike-policy1 proposal-set standard user@host# set policy ike-policy1 pre-shared-key ascii-text "$ABC123" user@host# set gateway t-ike-gate ike-policy ike-policy1 user@host# set gateway t-ike-gate address 10.2.2.2 user@host# set gateway t-ike-gate external-interface lo0.1
Configurez une proposition IPsec.
[edit security ipsec] user@host# set proposal p2-std-p1 authentication-algorithm hmac-sha1-96 user@host# set proposal p2-std-p1 encryption-algorithm 3des-cbc user@host# set proposal p2-std-p1 lifetime-seconds 180 user@host# set proposal p2-std-p2 authentication-algorithm hmac-sha1-96 user@host# set proposal p2-std-p2 encryption-algorithm aes-128-cbc user@host# set proposal p2-std-p2 lifetime-seconds 180 user@host# set policy vpn-policy1 perfect-forward-secrecy keys group2 user@host# set policy vpn-policy1 proposals p2-std-p1 user@host# set policy vpn-policy1 proposals p2-std-p2 user@host# set vpn t-ike-vpn bind-interface st0.0 user@host# set vpn t-ike-vpn ike gateway t-ike-gate user@host# set vpn t-ike-vpn ike proxy-identity local 10.10.10.1/24 user@host# set vpn t-ike-vpn ike proxy-identity remote 192.168.168.1/24 user@host# set vpn t-ike-vpn ike ipsec-policy vpn-policy1
Résultats
À partir du mode de configuration, confirmez votre configuration en saisissant les commandes show interfaces lo0, show routing-instances, show security ikeet show security ipsec. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
[edit]
user@host# show interfaces lo0
unit 1 {
family inet {
address 10.3.3.3/30;
}
}
redundant-pseudo-interface-options {
redundancy-group 1;
}
[edit]
user@host# show routing-instances
vr1 {
instance-type virtual-router;
interface lo0.1;
interface reth0.0;
interface reth1.0;
interface st0.0;
routing-options {
static {
route 192.168.168.1/24 next-hop st0.0;
}
}
}
[edit]
user@host# show security ike
policy ike-policy1 {
mode main;
proposal-set standard;
pre-shared-key ascii-text "$ABC123";
}
gateway t-ike-gate {
ike-policy ike-policy1;
address 10.2.2.2;
external-interface lo0.1;
}
[edit]
user@host# show security ipsec
proposal p2-std-p1 {
authentication-algorithm hmac-sha1-96;
encryption-algorithm 3des-cbc;
lifetime-seconds 180;
}
proposal p2-std-p2 {
authentication-algorithm hmac-sha1-96;
encryption-algorithm aes-128-cbc;
lifetime-seconds 180;
}
policy vpn-policy1 {
perfect-forward-secrecy {
keys group2;
}
proposals [ p2-std-p1 p2-std-p2 ];
}
policy vpn-policy2 {
perfect-forward-secrecy {
keys group2;
}
proposals [ p2-std-p1 p2-std-p2 ];
}
vpn t-ike-vpn {
bind-interface st0.0;
ike {
gateway t-ike-gate;
proxy-identity {
local 10.10.10.1/24;
remote 192.168.168.1/24;
}
ipsec-policy vpn-policy1;
}
}
Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.
Vérification
Vérification de la configuration
But
Vérifiez que la configuration des groupes de redondance pour les interfaces de bouclage est correcte.
Action
À partir du mode opérationnel, entrez la show chassis cluster interfaces commande.
user@host> show chassis cluster interfaces
Control link status: Up
Control interfaces:
Index Interface Status
0 em0 Up
1 em1 Down
Fabric link status: Up
Fabric interfaces:
Name Child-interface Status
fab0 ge-0/0/7 Up / Up
fab0
fab1 ge-13/0/7 Up / Up
fab1
Redundant-ethernet Information:
Name Status Redundancy-group
reth0 Up 1
reth1 Up 1
reth2 Up 1
reth3 Down Not configured
reth4 Down Not configured
Redundant-pseudo-interface Information:
Name Status Redundancy-group
lo0 Up 1
Sens
La show chassis cluster interfaces commande affiche les informations sur les interfaces du cluster de châssis. Si l’état du champ Informations sur la pseudo-interface redondante indique que l’interface lo0 est Actif et que l’état du champ Informations redondantes Ethernet indique que les champs reth0, reth1 et reth2 sont Actif, alors votre configuration est correcte.