Túneis vpn IPsec com clusters de chassi
O firewall da Série SRX oferece suporte a túneis de VPN IPsec em uma configuração de cluster de chassi. Em um cluster de chassi ativo/passivo, todos os túneis de VPN terminam no mesmo nó. Em um cluster ativo/ativo do chassi, os túneis VPN podem terminar em ambos os nós.
Entendendo clusters de chassi de VPN IPsec com backup ativo duplo
Em um cluster de chassi ativo/passivo, todos os túneis VPN terminam no mesmo nó, conforme mostrado em Figura 1.
Em um cluster ativo/ativo do chassi, os túneis VPN podem terminar em ambos os nós. Ambos os nós no cluster do chassi podem passar ativamente pelo tráfego através de túneis VPN em ambos os nós ao mesmo tempo, como mostrado em Figura 2. Essa implantação é conhecida como clusters de chassi de VPN IPsec de backup ativo duplo.
Os recursos a seguir são suportados com clusters de chassi de VPN IPsec de backup ativo duplo:
Apenas VPNs baseadas em rota. As VPNs baseadas em políticas não são suportadas.
IKEv1 e IKEv2.
Certificado digital ou autenticação de chave pré-compartilhada.
IKE e interfaces de túnel seguro (st0) em roteadores virtuais.
Transversal de endereço de rede (NAT-T).
Monitoramento de VPN.
Detecção de peer inativo.
Upgrade de software em serviço (ISSU).
Inserção de placas de processamento de serviços (SPCs) em um dispositivo de cluster de chassi sem perturbar o tráfego nos túneis VPN existentes. Consulte o suporte de VPN para inserir placas de processamento de serviços.
Protocolos dinâmicos de roteamento.
Interfaces de túnel seguras (st0) configuradas no modo ponto a multiponto.
AutoVPN com interfaces st0 no modo ponto a ponto com seletores de tráfego.
Modos de túnel IPv4-in-IPv4, IPv6-in-IPv4, IPv6-in-IPv6 e IPv4-in-IPv6.
Tráfego fragmentado.
A interface de loopback pode ser configurada como a interface externa para a VPN.
Os clusters de chassi de VPN IPsec de backup ativo duplo não podem ser configurados com fluxos de modo Z. Os fluxos do modo Z ocorrem quando o tráfego entra em uma interface em um nó de cluster do chassi, passa pelo enlace da malha e sai por uma interface no outro nó de cluster.
Consulte também
Exemplo: Configuração de grupos de redundância para interfaces de loopback
Este exemplo mostra como configurar um grupo de redundância (RG) para uma interface de loopback, a fim de evitar falhas de VPN. Grupos de redundância são usados para agrupar interfaces em um grupo para fins de failover em uma configuração de cluster de chassi.
Requisitos
Este exemplo usa o seguinte hardware e software:
Um par de firewalls da Série SRX de cluster de chassi suportado
Um dispositivo SSG140 ou equivalente
Dois switches
Junos OS Versão 12.1x44-D10 ou posterior para firewall da Série SRX
Antes de começar:
Entenda as interfaces Ethernet redundantes de cluster de chassi. Consulte o guia de usuário do cluster de chassis para dispositivos da Série SRX.
Visão geral
Um gateway de troca de chaves da Internet (IKE) precisa de uma interface externa para se comunicar com um dispositivo peer. Em uma configuração de cluster de chassi, o nó no qual a interface externa está ativa seleciona uma unidade de processamento de serviços (SPU) para oferecer suporte ao túnel VPN. Os pacotes IKE e IPsec são processados nessa SPU. Portanto, a interface externa ativa decide a SPU âncora.
Em uma configuração de cluster de chassi, a interface externa é uma interface Ethernet redundante. Uma interface Ethernet redundante pode diminuir quando suas interfaces físicas (infantis) estão paradas. Você pode configurar uma interface de loopback como uma interface física alternativa para chegar ao gateway peer. As interfaces de loopback podem ser configuradas em qualquer grupo de redundância. Essa configuração de grupo de redundância só é verificada para pacotes VPN, pois apenas os pacotes de VPN devem encontrar a SPU âncora através da interface ativa.
Você deve configurar lo0.x em um roteador virtual personalizado, já que lo0.0 está no roteador virtual padrão e apenas uma interface de loopback é permitida em um roteador virtual.
Figura 3 mostra um exemplo de uma topologia vpn de cluster de chassi de loopback. Nesta topologia, o dispositivo de cluster de chassi de firewall da Série SRX está localizado em Sunnyvale, Califórnia. O dispositivo de cluster de chassi de firewall da Série SRX funciona como um único gateway nesta configuração. O dispositivo da Série SSG (ou um dispositivo de terceiros) está localizado em Chicago, Illinois. Este dispositivo atua como um dispositivo peer para o cluster de chassi SRX e ajuda a construir um túnel VPN.
Configuração
Procedimento
Configuração rápida da CLI
Para configurar rapidamente esta seção do exemplo, copie os seguintes comandos, cole-os em um arquivo de texto, remova quaisquer quebras de linha, altere quaisquer detalhes necessários para combinar com a configuração da sua rede, copiar e colar os comandos no CLI no nível de hierarquia e, em seguida, entrar no [edit]
commit modo de configuração.
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
Procedimento passo a passo
Para configurar um grupo de redundância para uma interface de loopback:
Configure a interface de loopback em um grupo de redundância.
[edit interfaces] user@host# set lo0 redundant-pseudo-interface-options redundancy-group 1
Configure o endereço IP para a interface de loopback.
[edit interfaces] user@host# set lo0 unit 1 family inet address 10.3.3.3/30
Configure opções de roteamento.
[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
Configure a interface de loopback como uma interface externa para o gateway 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
Configure uma proposta de 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
Resultados
A partir do modo de configuração, confirme sua configuração entrando noshow interfaces lo0
, show routing-instances
show security ike
e show security ipsec
comandos. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.
[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; } }
Se você terminar de configurar o dispositivo, entre no commit
modo de configuração.
Verificação
Verificando a configuração
Propósito
Verifique se a configuração para grupos de redundância para interfaces de loopback está correta.
Ação
A partir do modo operacional, entre no show chassis cluster interfaces comando.
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
Significado
O show chassis cluster interfaces comando exibe as informações das interfaces de cluster do chassi. Se o status do campo de informações redundante-pseudo-interface mostrar a interface lo0 como Up e o status do campo de informações redundantes-ethernet mostrar campos reth0, reth1 e reth2 como Up, então sua configuração está correta.