Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Visão geral da VPN IPsec

Uma VPN é uma rede privada que usa uma rede pública para conectar dois ou mais sites remotos. Em vez de usar conexões dedicadas entre redes, as VPNs usam conexões virtuais roteadas (em túnel) por redes públicas. A VPN IPsec é um protocolo, consiste em um conjunto de padrões usados para estabelecer uma conexão VPN.

Uma VPN fornece um meio pelo qual computadores remotos se comunicam com segurança em uma WAN pública, como a Internet.

Uma conexão VPN pode vincular duas LANs (VPN de site para site) ou um usuário de discagem remota e uma LAN. O tráfego que flui entre esses dois pontos passa por recursos compartilhados, como roteadores, switches e outros equipamentos de rede que compõem a WAN pública. Para proteger a comunicação VPN enquanto passam pela WAN, os dois participantes criam um túnel de segurança IP (IPsec).

O termo túnel não denota o modo túnel (ver processamento de pacotes no modo túnel). Em vez disso, refere-se à conexão IPsec.

Topologias de VPN IPsec em dispositivos da Série SRX

A seguir, algumas das topologias de VPN IPsec que o sistema operacional Junos (OS) oferece:

  • VPNs de site para local — conecta dois sites em uma organização e permite comunicações seguras entre os sites.

  • VPNs hub-and-spoke — conecta escritórios de filiais ao escritório corporativo em uma rede empresarial. Você também pode usar essa topologia para conectar spokes juntos, enviando tráfego pelo hub.

  • VPNs de acesso remoto — permite que usuários que trabalham em casa ou viajem se conectem ao escritório corporativo e seus recursos. Esta topologia às vezes é referida como um end-to-site tunnel.

Comparando VPNs baseadas em políticas e baseadas em rotas

É importante entender as diferenças entre VPNs baseadas em políticas e rotas e por que uma pode ser preferível à outra.

Tabela 1 lista as diferenças entre VPNs baseadas em rota e VPNs baseadas em políticas.

Tabela 1: Diferenças entre VPNs baseadas em rota e VPNs baseadas em políticas

VPNs baseadas em rota

VPNs baseadas em políticas

Com VPNs baseadas em rota, uma política não faz referência especificamente a um túnel VPN.

Com túneis VPN baseados em políticas, um túnel é tratado como um objeto que, juntamente com fonte, destino, aplicativo e ação, constitui uma política de túnel que permite o tráfego vpn.

A política faz referência a um endereço de destino.

Em uma configuração de VPN baseada em políticas, uma política de túnel faz referência especificamente a um túnel VPN por nome.

O número de túneis VPN baseados em rota que você cria é limitado pelo número de entradas de rota ou pelo número de interfaces st0 que o dispositivo oferece suporte, qualquer número menor.

O número de túneis VPN baseados em políticas que você pode criar é limitado pelo número de políticas que o dispositivo oferece suporte.

A configuração de túnel VPN baseada em rota é uma boa opção quando você deseja conservar recursos de túnel ao mesmo tempo em que estabelece restrições granulares ao tráfego VPN.

Com uma VPN baseada em políticas, embora você possa criar várias políticas de túnel fazendo referência ao mesmo túnel VPN, cada par de políticas de túnel cria uma associação de segurança IPsec (SA) individual com o peer remoto. Cada SA conta como um túnel VPN individual.

Com uma abordagem baseada em rota para VPNs, a regulamentação do tráfego não está acoplada aos meios de sua entrega. Você pode configurar dezenas de políticas para regular o tráfego que flui por um único túnel VPN entre dois locais, e apenas um IPsec SA está funcionando. Além disso, uma configuração de VPN baseada em rota permite que você crie políticas referentes a um destino alcançado através de um túnel VPN no qual a ação é negada.

Em uma configuração de VPN baseada em políticas, a ação deve ser permissão e deve incluir um túnel.

VPNs baseadas em rota oferecem suporte à troca de informações de roteamento dinâmico por túneis VPN. Você pode habilitar uma instância de um protocolo de roteamento dinâmico, como o OSPF, em uma interface st0 que está ligada a um túnel VPN.

A troca de informações de roteamento dinâmico não é suportada em VPNs baseadas em políticas.

As configurações baseadas em rota são usadas para topologias hub-and-spoke.

As VPNs baseadas em políticas não podem ser usadas para topologias hub-and-spoke.

Com VPNs baseadas em rota, uma política não faz referência especificamente a um túnel VPN.

Quando um túnel não conecta grandes redes que executam protocolos de roteamento dinâmico e você não precisa conservar túneis ou definir várias políticas para filtrar o tráfego através do túnel, um túnel baseado em políticas é a melhor escolha.

As VPNs baseadas em rota não oferecem suporte a configurações de VPN de acesso remoto (dial-up).

Os túneis VPN baseados em políticas são necessários para configurações de VPN de acesso remoto (dial-up).

VPNs baseadas em rota podem não funcionar corretamente com alguns fornecedores terceirizados.

VPNs baseadas em políticas podem ser necessárias se o terceiro precisar de SAs separados para cada sub-rede remota.

Quando o dispositivo de segurança faz uma pesquisa de rota para encontrar a interface pela qual deve enviar tráfego para chegar a um endereço, ele encontra uma rota por uma interface de túnel segura (st0) , que está ligada a um túnel VPN específico.

Com um túnel VPN baseado em rota, você pode considerar um túnel como um meio de entregar tráfego, e pode considerar a política como um método para permitir ou negar a entrega desse tráfego.

Com um túnel VPN baseado em políticas, você pode considerar um túnel como um elemento na construção de uma política.

VPNs baseadas em rota oferecem suporte a NAT para interfaces st0.

VPNs baseadas em políticas não podem ser usadas se o NAT for necessário para tráfego em túnel.

O Proxy ID é compatível com VPNs baseadas em rotas e políticas. Túneis baseados em rota também oferecem o uso de vários seletores de tráfego também conhecidos como ID multi-proxy. Um seletor de tráfego é um acordo entre os pares do IKE para permitir o tráfego através de um túnel, se o tráfego combinar com um par especificado de prefixo de endereço IP local e remoto, faixa de porta de origem, alcance da porta de destino e protocolo. Você define um seletor de tráfego dentro de uma VPN específica baseada em rota, o que pode resultar em vários SAs IPsec da Fase 2. Apenas o tráfego em conformidade com um seletor de tráfego é permitido por meio de um SA. O seletor de tráfego geralmente é necessário quando dispositivos de gateway remotos não são dispositivos da Juniper Networks.

As VPNs baseadas em políticas só têm suporte para dispositivos SRX5400, SRX5600 e SRX5800. O suporte à plataforma depende da versão do Junos OS em sua instalação.

Comparação de VPNs baseadas em políticas e VPNs baseadas em rotas

Tabela 2 resume as diferenças entre VPNs baseadas em políticas e VPNs baseadas em rotas.

Tabela 2: Comparação entre VPNs baseadas em políticas e VPNs baseadas em rotas

VPNs baseadas em políticas

VPNs baseadas em rota

Em VPNs baseadas em políticas, um túnel é tratado como um objeto que, juntamente com a origem, destino, aplicativo e ação, constitui uma política de túnel que permite o tráfego VPN.

Em VPNs baseadas em rota, uma política não faz referência especificamente a um túnel VPN.

Uma política de túnel faz referência especificamente a um túnel VPN por nome.

Uma rota determina qual tráfego é enviado pelo túnel com base em um endereço IP de destino.

O número de túneis VPN baseados em políticas que você pode criar é limitado pelo número de túneis que o dispositivo oferece suporte.

O número de túneis VPN baseados em rota que você cria é limitado pelo número de interfaces st0 (para VPNs ponto a ponto) ou pelo número de túneis que o dispositivo oferece suporte, o que for menor.

Com uma VPN baseada em políticas, embora você possa criar várias políticas de túnel fazendo referência ao mesmo túnel VPN, cada par de políticas de túnel cria um IPsec SA individual com o peer remoto. Cada SA conta como um túnel VPN individual.

Como a rota, não a política, determina qual tráfego passa pelo túnel, várias políticas podem ser suportadas com uma única SA ou VPN.

Em uma VPN baseada em políticas, a ação deve ser permissão e deve incluir um túnel.

Em uma VPN baseada em rotas, a regulamentação do tráfego não é acoplada aos meios de sua entrega.

A troca de informações de roteamento dinâmico não é suportada em VPNs baseadas em políticas.

VPNs baseadas em rota oferecem suporte à troca de informações de roteamento dinâmico por túneis VPN. Você pode habilitar uma instância de um protocolo de roteamento dinâmico, como o OSPF, em uma interface st0 que está ligada a um túnel VPN.

Se você precisar de mais granularidade do que uma rota pode fornecer para especificar o tráfego enviado para um túnel, usar uma VPN baseada em políticas com políticas de segurança é a melhor opção.

VPNs baseadas em rota usam rotas para especificar o tráfego enviado para um túnel; uma política não faz referência especificamente a um túnel VPN.

Com um túnel VPN baseado em políticas, você pode considerar um túnel como um elemento na construção de uma política.

Quando o dispositivo de segurança faz uma pesquisa de rota para encontrar a interface pela qual deve enviar tráfego para chegar a um endereço, ele encontra uma rota através de uma interface de túnel seguro (st0).

Com um túnel VPN baseado em rota, você pode considerar um túnel como um meio de entregar tráfego, e pode considerar a política como um método para permitir ou negar a entrega desse tráfego.

Entender o processamento de pacotes IKE e IPsec

Um túnel VPN IPsec consiste na configuração do túnel e segurança aplicada. Durante a configuração do túnel, os pares estabelecem associações de segurança (SAs), que definem os parâmetros para proteger o tráfego entre si. (Veja Visão geral do IPsec.) Após a criação do túnel, o IPsec protege o tráfego enviado entre os dois endpoints de túnel aplicando os parâmetros de segurança definidos pelos SAs durante a configuração do túnel. Dentro da implementação do Junos OS, o IPsec é aplicado em modo de túnel, que oferece suporte aos protocolos de payload de segurança (ESP) e cabeçalho de autenticação (AH).

Este tópico inclui as seguintes seções:

Processamento de pacotes no modo túnel

O IPsec opera em um dos dois modos: transporte ou túnel. Quando ambas as extremidades do túnel são hosts, você pode usar qualquer modo. Quando pelo menos um dos endpoints de um túnel é um gateway de segurança, como um roteador ou firewall Junos OS, você deve usar o modo de túnel. Os dispositivos da Juniper Networks operam sempre em modo de túnel para túneis IPsec.

No modo túnel, todo o pacote IP original — payload e cabeçalho — é encapsulado em outra carga de IP, e um novo cabeçalho é apensado a ele, como mostrado em Figura 1. Todo o pacote original pode ser criptografado, autenticado ou ambos. Com o protocolo cabeçalho de autenticação (AH), os cabeçalhos AH e novos cabeçalhos também são autenticados. Com o protocolo de payload de segurança (ESP) encapsulando, o cabeçalho ESP também pode ser autenticado.

Figura 1: Modo de túnelModo de túnel

Em uma VPN de site para site, os endereços de origem e destino usados no novo cabeçalho são os endereços IP da interface de saída. Veja Figura 2.

Figura 2: VPN de site para local no modo túnelVPN de site para local no modo túnel

Em uma VPN dial-up, não há gateway de túnel na extremidade do cliente dial-up VPN do túnel; o túnel se estende diretamente até o próprio cliente (ver Figura 3). Nesse caso, em pacotes enviados do cliente dial-up, tanto o novo cabeçalho quanto o cabeçalho original encapsulado têm o mesmo endereço IP: a do computador do cliente.

Alguns clientes vpn, como o cliente VPN dinâmico e o Netscreen-Remote, usam um endereço IP interno virtual (também chamado de "endereço pegajoso"). O Netscreen-Remote permite que você defina o endereço IP virtual. O cliente VPN dinâmico usa o endereço IP virtual atribuído durante a troca de configurações do XAuth. Nesses casos, o endereço IP interno virtual é o endereço IP de origem no cabeçalho de pacote original do tráfego originário do cliente, e o endereço IP que o ISP atribui dinamicamente ao cliente dial-up é o endereço IP de origem no cabeçalho externo. A partir do Junos OS, a VPN dinâmica 21.4R1 não tem suporte para dispositivos SRX300, SRX320, SRX340, SRX345, SRX380 e SRX550 HM.

Figura 3: VPN dial-up no modo túnelVPN dial-up no modo túnel

Distribuição de sessões de IKE e IPsec em SPUs

Nos dispositivos SRX5400, SRX5600 e SRX5800, o IKE fornece gerenciamento de túneis para IPsec e autentica entidades finais. A IKE realiza uma troca de chaves Diffie-Hellman (DH) para gerar um túnel IPsec entre dispositivos de rede. Os túneis IPsec gerados pelo IKE são usados para criptografar, descriptografar e autenticar o tráfego de usuários entre os dispositivos de rede na camada IP.

A VPN é criada distribuindo a carga de trabalho IKE e IPsec entre as várias Unidades de Processamento de Serviços (SPUs) da plataforma. Para túneis local a local, a SPU menos carregado é escolhida como a SPU âncora. Se várias SPUs tiverem a mesma menor carga, qualquer uma delas pode ser escolhida como uma SPU âncora. Aqui, a carga corresponde ao número de gateways de site para local ou túneis VPN manuais ancorados em uma SPU. Para túneis dinâmicos, os túneis dinâmicos recém-estabelecidos empregam um algoritmo round-robin para selecionar a SPU.

No IPsec, a carga de trabalho é distribuída pelo mesmo algoritmo que distribui o IKE. O SA da Fase 2 para um determinado par de pontos de encerramento de túnel VPN pertence exclusivamente a uma SPU específica, e todos os pacotes IPsec pertencentes a esta SA fase 2 são encaminhados à SPU de ancoragem dessa SA para processamento IPsec.

Várias sessões IPsec (Fase 2 SA) podem operar em uma ou mais sessões de IKE. A SPU selecionada para ancorar a sessão IPsec baseia-se na SPU que ancora a sessão IKE subjacente. Portanto, todas as sessões IPsec que são executadas por um único gateway IKE são executadas pela mesma SPU e não são balanceadas por carga em várias SPUs.

Tabela 3 mostra um exemplo de um dispositivo de linha SRX5000 com três SPUs executando sete túneis IPsec em três gateways IKE.

Tabela 3: Distribuição de sessões de IKE e IPsec em SPUs

SPU

IKE Gateway

Túnel IPsec

SPU0

IKE-1

IPsec-1

IPsec-2

IPsec-3

SPU1

IKE-2

IPsec-4

IPsec-5

IPsec-6

SPU2

IKE-3

IPsec-7

As três SPUs têm uma carga igual de um gateway IKE cada. Se um novo gateway IKE for criado, SPU0, SPU1 ou SPU2 podem ser selecionados para ancorar o gateway IKE e suas sessões IPsec.

Configurar e derrubar túneis IPsec existentes não afeta a sessão IKE subjacente ou os túneis IPsec existentes.

Use o seguinte show comando para visualizar a contagem de túneis atual por SPU: show security ike tunnel-map.

Use a opção summary do comando para visualizar os pontos âncora de cada gateway: show security ike tunnel-map summary.

Suporte de VPN para inserir placas de processamento de serviços

Os dispositivos SRX5400, SRX5600 e SRX5800 têm uma arquitetura de processador distribuída baseada em chassi. O poder de processamento de fluxo é compartilhado e é baseado no número de placas de processamento de serviços (SPCs). Você pode dimensionar o poder de processamento do dispositivo instalando novos SPCs.

Em um cluster de chassis SRX5400, SRX5600 ou SRX5800, você pode inserir novos SPCs nos dispositivos sem afetar ou interromper o tráfego nos túneis VPN IKE ou IPsec existentes. Quando você insere um novo SPC em cada chassi do cluster, os túneis existentes não são afetados e o tráfego continua a fluir sem interrupções.

A partir do Junos OS Release 19.4R1, em todos os clusters de chassi de dispositivos da Série SRX500, você pode inserir uma nova placa SRX5K-SPC3 (SPC3) ou SRX5K-SPC-4-15-320 (SPC2) em um chassi existente contendo placa SPC3. Você só pode inserir as placas em um slot mais alto do que a placa SPC3 existente no chassi. Você deve reiniciar o nó após a inserção do SPC3 para ativar a placa. Após a reinicialização do nó ser concluída, os túneis IPsec são distribuídos para as placas.

No entanto, os túneis existentes não podem usar o poder de processamento das Unidades de Processamento de Serviços (SPUs) nos novos SPCs. Uma nova SPU pode ancorar túneis dinâmicos e local para local recém-estabelecidos. No entanto, os túneis recém-configurados não são garantidos em uma nova SPU.

Os túneis local a local estão ancorados em diferentes SPUs com base em um algoritmo de balanceamento de carga. O algoritmo de balanceamento de carga depende de threads de fluxo numéricas que cada SPU está usando. Os túneis pertencentes aos mesmos endereços IP locais e remotos de gateway estão ancorados na mesma SPU em diferentes threads RT de fluxo usados pela SPU. A SPU com a menor carga é escolhida como a SPU âncora. Cada SPU mantém um número de threads RT de fluxo hospedados nessa SPU em particular. O número de threads RT de fluxo hospedados em cada SPU varia com base no tipo de SPU.

Fator de carga de túnel = Número de túneis ancorados na SPU/ Número total de threads RT de fluxo usados pela SPU.

Os túneis dinâmicos são ancorados em diferentes SPUs com base em um algoritmo round-robin. Os túneis dinâmicos recém-configurados não têm garantia de serem ancorados no novo SPC.

A partir do Junos OS Release 18.2R2 e 18.4R1, todos os recursos de VPN IPsec existentes que atualmente são suportados no SRX5K-SPC3 (SPC3) só serão suportados no SRX5400, SRX5600 e SRX5800 quando as placas SRX5K-SPC-4-15-320 (SPC2) e SPC3 estão instaladas e operando no dispositivo em um modo de cluster de chassi ou em um modo autônomo.

Quando as placas SPC2 e SPC3 são instaladas, você pode verificar o mapeamento do túnel em diferentes SPUs usando o show security ipsec tunnel-distribution comando.

Use o comando show security ike tunnel-map para visualizar o mapeamento do túnel em diferentes SPUs com apenas uma placa SPC2 inserida. O comando show security ike tunnel-map não é válido em um ambiente onde as placas SPC2 e SPC3 estão instaladas.

Insira a placa SPC3: Diretrizes e limitações:

  • Em um cluster de chassi, se um dos nós tiver 1 placa SPC3 e o outro nó tiver 2 placas SPC3, o failover ao nó que tem 1 placa SPC3 não é suportado.

  • Você deve inserir o SPC3 ou SPC2 em um chassi existente em um slot mais alto do que um SPC3 atual presente em um slot inferior.

  • Para que o SPC3 ISHU funcione, você deve inserir a nova placa SPC3 no número de slots mais alto.

  • No cluster do chassi SRX5800, você não deve inserir a placa SPC3 no slot mais alto (slot nº 11) devido ao limite de alimentação e distribuição de calor.

  • Não oferecemos suporte à remoção de hot removal do SPC3.

Tabela 4 resume a linha SRX5000 de dispositivos com placa SPC2 ou SPC3 que oferece kmd suporte ou iked processo:

Tabela 4: kmd/iked Suporte de processo na linha de dispositivos SRX5000

Linha de dispositivos SRX5000

Suporte para kmd ou iked processo

Linha de dispositivos SRX5000 com apenas placa SPC2 instalada

Suporte ao kmd processo.

Linha de dispositivos SRX5000 com apenas placa SPC3 instalada

Suporte ao iked processo.

Linha de dispositivos SRX5000 com placa SPC2 e SPC3 instalada

Suporte ao iked processo.

Ativação do conjunto de recursos de VPN IPsec na placa de processamento de serviços SRX5K-SPC3

A linha de dispositivos SRX5000 com placa SRX5K-SPC3 requer pacote para junos-ike instalar e habilitar qualquer um dos recursos de VPN IPsec. Por padrão, o junos-ike pacote é instalado nos lançamentos do Junos OS 20.1R2, 20.2R2, 20.3R2, 20.4R1 e posterior para a linha SRX5000 de dispositivos com RE3. Como resultado, iked o ikemd processo é executado no mecanismo de roteamento por padrão, em vez de daemon de gerenciamento de chave IPsec (kmd).

Se você quiser usar kmd o processo para habilitar recursos de VPN IPsec na linha SRX5000 de dispositivos sem uma placa SPC3, você deve executar o request system software delete junos-ike comando. Depois de executar o comando, você deve reinicializar o dispositivo.

Para verificar o pacote instalado junos-ike , use o seguinte comando:

Suporte a recursos de VPN IPsec na linha SRX5000 de dispositivos com instâncias SRX5K-SPC3 e vSRX com novo pacote

Este tópico oferece um resumo dos recursos e configurações de VPN IPsec que não são compatíveis com a linha SRX5000 de dispositivos com SPC3 e em instâncias vSRX.

O recurso VPN IPsec é suportado por dois processos iked e ikemd em instâncias SRX5K-SPC3 e vSRX. Uma única instância iked e ikemd será executada no mecanismo de roteamento de cada vez.

Por padrão, o Junos-ike pacote é instalado no Junos OS Releases 20.1R2, 20.2R2, 20.3R2, 20.4R1 e posterior para a linha SRX5000 de dispositivos com RE3, e tanto o iked processo é ikemd executado no mecanismo de roteamento.

Para reiniciar ikemd o processo no Mecanismo de Rotina, use o restart ike-config-management comando.

Para reiniciar iked o processo no mecanismo de roteamento, use o restart ike-key-management comando.

Se você quiser usar kmd o processo para habilitar recursos de VPN IPsec na linha SRX5000 de dispositivos sem uma placa SPC3, você deve executar o request system software delete junos-ike comando. Depois de executar o comando, você deve reinicializar o dispositivo.

Recursos de VPN IPsec não suportados

Para determinar se um recurso é compatível com uma plataforma específica ou o lançamento do Junos OS, consulte o Feature Explorer.

Tabela 5 resume os recursos de VPN IPsec não suportados em dispositivos da Série SRX e o processo vSRX em execução iked:

Tabela 5: Recursos de VPN IPsec não suportados em dispositivos da Série SRX e instâncias vSRX

Recursos

Suporte em dispositivos da linha SRX5000 com instâncias SRX5K-SPC3 e vSRX

VPN auto discovery (ADVPN).

Não

Modo multiponto independente de protocolo autoVPN (PIM).

Não

Configurando a aula de encaminhamento em VPNs IPsec.

Não

Falha no gateway de detecção de peer (DPD).

O failover do gateway DPD não é compatível com o vSRX.

VPN em grupo.

Não

Vida útil da IKE SA, em kilobytes.

Não

Configuração do tamanho do pacote para verificação de datapath IPsec.

Não

VPN IPsec baseada em políticas.

Não

Monitoramento de VPN.

Não

Suporte a protocolos de roteamento em túneis IPsec VPN

Oferecemos suporte a protocolos de roteamento como OSPF, BGP, PIM, RIP e BFD para serem executados em túneis IPsec em dispositivos da Série SRX e roteadores da Série MX em execução kmd ou iked processo. O suporte ao protocolo varia de acordo com o esquema de endereçamento IP ou o tipo de interface st0, ponto a ponto (P2P) ou ponto a multiponto (P2MP).

Tabela 6 resume o suporte ao protocolo OSPF em dispositivos da Série SRX e roteadores MX.

Tabela 6: Suporte ao protocolo OSPF em túneis IPsec VPN
OSPF
Dispositivos P2P P2MP
IPv4 IPv6 IPv4 IPv6
SRX100, SRX110, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345, SRX380, SRX550, SRX550 HM, SRX650, SRX1400, SRX1500, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600 e SRX5K-SPC2 Sim Não Sim Não
SRX5K-SPC3 Sim Não Sim Não
SRX5K no modo misto (SPC3 + SPC2) Sim Não Sim Não
vSRX 3.0 Sim Não Sim Não
MX-SPC3 Sim Não Não Não

Tabela 7 resume o suporte ao protocolo OSPFv3 em dispositivos da Série SRX e roteadores MX.

Tabela 7: Suporte ao protocolo OSPFv3 em túneis IPsec VPN
OSPFv3
Dispositivos P2P P2MP
IPv4 IPv6 IPv4 IPv6
SRX100, SRX110, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345, SRX380, SRX550, SRX550 HM, SRX650, SRX1400, SRX1500, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600 e SRX5K-SPC2 Não Sim Não Sim
SRX5K-SPC3 Não Sim Não Sim
SRX5K no modo misto (SPC3 + SPC2) Não Sim Não Sim
vSRX 3.0 Não Sim Não Sim
MX-SPC3 Não Sim Não Não

Tabela 8 resume o suporte ao protocolo BGP em dispositivos da Série SRX e roteadores MX.

Tabela 8: Suporte ao protocolo BGP em túneis IPsec VPN
BGP
Dispositivos P2P P2MP
IPv4 IPv6 IPv4 IPv6
SRX100, SRX110, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345, SRX380, SRX550, SRX550 HM, SRX650, SRX1400, SRX1500, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600 e SRX5K-SPC2 Sim Sim Sim Sim
SRX5K-SPC3 Sim Sim Sim Sim
SRX5K no modo misto (SPC3 + SPC2) Sim Sim Sim Sim
vSRX 3.0 Sim Sim Sim Sim
MX-SPC3 Sim Sim Não Não

Tabela 9 resume o suporte ao protocolo PIM em dispositivos da Série SRX e roteadores MX.

Tabela 9: Suporte ao protocolo PIM em túneis IPsec VPN
PIM
Dispositivos P2P P2MP
IPv4 IPv6 IPv4 IPv6
SRX100, SRX110, SRX210, SRX220, SRX240, SRX550, SRX550 HM, SRX650, SRX1400, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600 e SRX5K-SPC2 Sim Não Não Não
SRX300, SRX320, SRX340, SRX345, SRX380 e SRX1500 Sim Não Sim Não
SRX5K-SPC3 Sim Não Não Não
SRX5K no modo misto (SPC3 + SPC2) Sim Não Não Não
vSRX 3.0 Sim Não Sim
Nota:

A multithread não tem suporte.

Não
MX-SPC3 Sim Não Não Não

Tabela 10 resume o suporte ao protocolo RIP em dispositivos da Série SRX e roteadores MX.

Tabela 10: Suporte ao protocolo RIP em túneis IPsec VPN
RIP
Dispositivos P2P P2MP
IPv4 IPv6 IPv4 IPv6
SRX100, SRX110, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345, SRX380, SRX550, SRX550 HM, SRX650, SRX1400, SRX1500, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600 e SRX5K-SPC2 Sim Sim Não Não
SRX5K-SPC3 Sim Sim Não Não
SRX5K no modo misto (SPC3 + SPC2) Sim Sim Não Não
vSRX 3.0 Sim Sim Não Não
MX-SPC3 Sim Sim Não Não

Tabela 11 resume o suporte ao protocolo BFP em dispositivos da Série SRX e roteadores MX.

Tabela 11: Suporte ao protocolo BFD em túneis IPsec VPN
BFD
Dispositivos P2P P2MP
IPv4 IPv6 IPv4 IPv6
SRX100, SRX110, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345, SRX380, SRX550, SRX550 HM, SRX650, SRX1400, SRX1500, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600 e SRX5K-SPC2 Sim Sim Sim Sim
SRX5K-SPC3 Sim Sim Sim Sim
SRX5K no modo misto (SPC3 + SPC2) Sim Sim Sim Sim
vSRX 3.0 Sim Sim Sim Sim
MX-SPC3 Sim Sim Não Não

Janela anti-replay

Nos dispositivos da Série SRX, anti-replay-window é habilitado por padrão com um valor de tamanho de janela de 64.

Na linha de dispositivos da Série SRX 5000 com placas SPC3 instaladas, você pode configurar o anti-replay-window tamanho na faixa de 64 a 8192 (potência de 2). Para configurar o tamanho da janela, use a nova anti-replay-window-size opção. Um pacote recebido é validado para ataque de repetição com base no anti-replay-window-size configurado.

Você pode configurar replay-window-size em dois níveis diferentes:

  • Global level— Configurado no nível [edit security ipsec] de hierarquia.

    Por exemplo:

  • VPN object— Configurado no nível [edit security ipsec vpn vpn-name ike] de hierarquia.

    Por exemplo:

Se o anti-replay for configurado em ambos os níveis, o tamanho da janela configurado para um nível de objeto VPN tem precedência sobre o tamanho da janela configurado em nível global. Se o anti-replay não estiver configurado, o tamanho da janela será de 64 por padrão.

Para desativar a opção de janela anti-replay em um objeto VPN, use o set no-anti-replay comando no nível [edit security ipsec vpn vpn-name ike] de hierarquia. Você não pode desabilitar o anti-replay em nível global.

Você não pode configurar tanto anti-replay-window-sizeno-anti-replay em um objeto VPN.

Entendendo as VPNs hub-and-spoke

Se você criar dois túneis VPN que terminam em um dispositivo, você pode configurar um par de rotas para que o dispositivo direcione o tráfego saindo de um túnel para o outro túnel. Você também precisa criar uma política para permitir que o tráfego passe de um túnel para o outro. Tal arranjo é conhecido como VPN hub-and-spoke. (Veja Figura 4.)

Você também pode configurar várias VPNs e rotear o tráfego entre dois túneis.

Os dispositivos da Série SRX oferecem suporte apenas ao recurso hub-and-spoke baseado em rota.

Figura 4: Vários túneis em uma configuração vpn hub-and-spokeVários túneis em uma configuração vpn hub-and-spoke
Tabela de histórico de liberação
Versão
Descrição
20.1R2
Por padrão, o junos-ike pacote é instalado nos lançamentos do Junos OS 20.1R2, 20.2R2, 20.3R2, 20.4R1 e posterior para a linha SRX5000 de dispositivos com RE3. Como resultado, iked o ikemd processo é executado no mecanismo de roteamento por padrão, em vez de daemon de gerenciamento de chave IPsec (kmd).