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 de 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 firewalls da Série SRX
A seguir, algumas das topologias de VPN IPsec que o sistema operacional (OS) Junos suporta:
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 — permitem que usuários que trabalham em casa ou viajem se conectem ao escritório corporativo e seus recursos. Essa topologia é às vezes referida como.end-to-site tunnel
Consulte também
Comparando VPNs baseadas em políticas e baseadas em rota
É importante entender as diferenças entre VPNs baseadas em políticas e baseadas em rota 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.
|
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 de 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 de 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, o que for menor. |
O número de túneis de 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 no tráfego de VPN. |
Com uma VPN baseada em políticas, embora você possa criar inúmeras políticas de túnel fazendo referência ao mesmo túnel VPN, cada par de política 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á associada aos meios de sua entrega. Você pode configurar dezenas de políticas para regular o fluxo de tráfego 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 que façam referência a um destino alcançado por um túnel VPN no qual a ação é negado. |
Em uma configuração de VPN baseada em políticas, a ação deve ser permissão e deve incluir um túnel. |
|
As VPNs baseadas em rota oferecem suporte à troca de informações dinâmicas de roteamento 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á vinculada 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). |
|
As VPNs baseadas em rota podem não funcionar corretamente com alguns fornecedores terceirizados. |
As VPNs baseadas em políticas podem ser necessárias se o terceiro exigir 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 através de uma interface de túnel segura () , que está vinculada a um túnel VPN específico. Com um túnel VPN baseado em rota, você pode considerar um túnel como um meio para 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. |
As VPNs baseadas em políticas não podem ser usadas se o NAT for necessário para tráfego em túnel. |
O ID proxy é suportado tanto para VPNs baseadas em rota quanto para VPNs baseadas em políticas. Os 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 de porta de destino e protocolo. Você define um seletor de tráfego em uma VPN baseada em rota específica, o que pode resultar em vários SAs IPsec da Fase 2. Somente o tráfego em conformidade com um seletor de tráfego é permitido por meio de um SA. O seletor de tráfego é comumente necessário quando dispositivos de gateway remotos não são dispositivos da Juniper Networks.
As VPNs baseadas em políticas só são suportadas em linhas de SRX5400, SRX5600 e SRX5800. O suporte da plataforma depende da versão do Junos OS em sua instalação.
Consulte também
Comparação de VPNs baseadas em políticas e VPNs baseadas em rota
Tabela 2 resume as diferenças entre VPNs baseadas em políticas e VPNs baseadas em rota.
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 fonte, destino, aplicativo e ação, constitui uma política de túnel que permite o tráfego de 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 de VPN baseados em políticas que você pode criar é limitado pelo número de túneis que o dispositivo suporta. |
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 suporta, o que for menor. |
Com uma VPN baseada em políticas, embora você possa criar inúmeras políticas de túnel fazendo referência ao mesmo túnel VPN, cada par de política 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 rota, a regulamentação do tráfego não está acoplada aos meios de sua entrega. |
A troca de informações de roteamento dinâmico não é suportada em VPNs baseadas em políticas. |
As VPNs baseadas em rota oferecem suporte à troca de informações dinâmicas de roteamento 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á vinculada a um túnel VPN. |
Se você precisar de mais granularidade do que uma rota pode fornecer para especificar o tráfego enviado a um túnel, usar uma VPN baseada em políticas com políticas de segurança é a melhor opção. |
As VPNs baseadas em rota usam rotas para especificar o tráfego enviado a 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 para 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 no modo túnel, que oferece suporte aos protocolos Encapsulating Security Payload (ESP) e Authentication Header (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 túnel. Os dispositivos da Juniper Networks sempre operam em modo de túnel para túneis IPsec.
No modo túnel, todo o pacote IP original — carga útil e cabeçalho — é encapsulado em outra carga de IP, e um novo cabeçalho é apensado a ele, conforme mostrado em .Figura 1 Todo o pacote original pode ser criptografado, autenticado ou ambos. Com o protocolo Authentication Header (AH), a AH e os novos cabeçalhos também são autenticados. Com o protocolo Encapsulating Security Payload (ESP), o cabeçalho ESP também pode ser autenticado.
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
Em uma VPN dial-up, não há gateway de túnel no disque-cliente VPN do fim do túnel; o túnel se estende diretamente até o próprio cliente (ver ).Figura 3 Neste 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: o computador do cliente.
Alguns clientes vpn, como 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. 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.
Consulte também
Distribuição de sessões de IKE e IPsec em SPUs
Nos dispositivos de SRX5400, SRX5600 e SRX5800, o IKE oferece gerenciamento de túneis para IPsec e autentica entidades finais. A IKE realiza uma troca de chaves de 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 de local a local, a SPU menos carregada é 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 de VPN manuais ancorados em uma SPU. Para túneis dinâmicos, os túneis dinâmicos recém-estabelecidos utilizam um algoritmo round-robin para selecionar a SPU.
No IPsec, a carga de trabalho é distribuída pelo mesmo algoritmo que distribui o IKE. A SA da Fase 2 para um determinado par de pontos de terminação de túnel VPN é exclusivamente propriedade de uma SPU específica, e todos os pacotes IPsec pertencentes a esta SA fase 2 são encaminhados à SPU de âncora dessa SA para processamento IPsec.
Várias sessões de IPsec (Fase 2 SA) podem operar em uma ou mais sessões de IKE. A SPU selecionada para ancorar a sessão de IPsec é baseada na SPU que está ancorando a sessão IKE subjacente. Portanto, todas as sessões de IPsec que são executadas por um único gateway IKE são executadas pela mesma SPU e não são balanceadas em várias SPUs.
Tabela 3 mostra um exemplo de uma linha de SRX5000 com três SPUs executando sete túneis IPsec em três gateways IKE.
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 poderiam ser selecionados para ancorar o gateway IKE e suas sessões IPsec.
Configurar e demolir túneis IPsec existentes não afeta a sessão de IKE subjacente ou os túneis IPsec existentes.
Use o comando a seguir para visualizar a contagem de túneis atual por SPU:show show security ike tunnel-map.
Use a opção do comando para visualizar os pontos âncora de cada gateway:summary show security ike tunnel-map summary.
Suporte para VPN para inserir placas de processamento de serviços
SRX5400, SRX5600 e dispositivos de 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 chassi SRX5400, SRX5600 ou SRX5800, você pode inserir novos SPCs nos dispositivos sem afetar ou interromper o tráfego nos túneis IKE ou VPN IPsec existentes. Ao inserir 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 SRX5000 cluster de chassi de linha, 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ó, 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ço (SPUs) nos novos SPCs. Uma nova SPU pode ancorar túneis dinâmicos e local a local recém-estabelecidos. No entanto, os túneis recém-configurados não estão garantidos em uma nova SPU.
Os túneis de 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 de número que cada SPU está usando. Os túneis pertencentes aos mesmos endereços IP de gateway local e remoto 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 o 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 de acordo com o tipo de SPU.
Fator de carga de túnel = Número de túneis ancorados na SPU / Número total de fios RT de fluxo usados pela SPU.
Túneis dinâmicos são ancorados em diferentes SPUs baseados em um algoritmo de robin redondo. Os túneis dinâmicos recém-configurados não garantem a ancoragem 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 em dispositivos SRX5400, SRX5600 e SRX5800 quando SRX5K-SPC-4-15-320 (SPC2) e placas SPC3 forem 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 comando.show security ipsec tunnel-distribution
Use o comando para visualizar o mapeamento do túnel em diferentes SPUs com apenas uma placa SPC2 inserida.show security ike tunnel-map O comando não é válido em um ambiente onde as placas SPC2 e SPC3 estão instaladas.show security ike tunnel-map
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 para o nó que tem 1 placa SPC3 não será 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 mais baixo.
-
Para que o SPC3 ISHU funcione, você deve inserir a nova placa SPC3 no número de slot mais alto.
-
Em SRX5800 cluster do chassi, você não deve inserir a placa SPC3 no slot mais alto (slot nº 11) devido ao limite de energia e distribuição de calor.
-
Não oferecemos suporte à remoção quente do SPC3.
resume a linha de SRX5000 com a placa SPC2 ou SPC3 que oferece suporte ou processo:Tabela 4kmdiked
|
Linha SRX5000 |
Suporte ou processo |
|---|---|
|
linha SRX5000 com apenas placa SPC2 instalada |
Suporte ao processo. |
|
SRX5000 linha com apenas a placa SPC3 instalada |
Suporte ao processo. |
|
linha SRX5000 com a placa SPC2 e SPC3 instalada |
Suporte ao processo. |
Consulte também
Suporte de aceleração criptográfica na placa SRX5K-SPC3, plataformas de médio alcance SRX e firewall virtual vSRX
SRX5000 linha com a placa SRX5K-SPC3 (Placa de processamento de serviços), plataformas de médio alcance SRX (SRX4100, SRX4200, SRX1500 e firewalls da Série SRX4600) e o firewall virtual vSRX requer o pacote como software do plano de controle para instalar e habilitar recursos de VPN IPsec.junos-ike
-
Em SRX5000 linha com o RE3, por padrão, o pacote é instalado nas versões Junos OS 20.1R2, 20.2R2, 20.3R2, 20.4R1 e posteriores.
junos-ikeComo resultado, e o processo é executado no mecanismo de roteamento por padrão, em vez de daemon de gerenciamento de chave IPsec (kmd).ikedikemd A linha SRX5000 com SRX5K-SPC3 descarrega as operações criptográficas para o mecanismo criptográfico de hardware. -
As plataformas de médio alcance SRX que cobrem firewalls da série SRX1500, SRX4100, SRX4200 e série SRX4600 descarregam as operações criptográficas dh, RSA e ECDSA para o mecanismo criptográfico de hardware com dispositivos em execução de software.
junos-ikeEsse recurso está disponível no Junos OS Release 23.2R1 com dispositivos com pacotes instalados.junos-ikeOs dispositivos que continuam a executar software legado (processo kmd) não oferecem suporte a esse recurso.iked -
No firewall virtual vSRX, a linha de CPU do plano de dados descarrega as operações de DH, RSA e ECDSA. A aceleração do hardware não está disponível nesses dispositivos. Esse recurso está disponível no Junos OS Release 23.2R1 com pacote instalado no dispositivo.
junos-ike
Descreve o suporte de aceleração de hardware para várias cifras:Tabela 5
| Cifras | SRX1500 | SRX4100/SRX4200 | SRX4600 | SRX5K - SPC3 | vSRX3.0 | ||||
|---|---|---|---|---|---|---|---|---|---|
| KMD | IKED | KMD | IKED | KMD | IKED | IKED | KMD | IKED | |
| DH (Grupos 1, 2, 5, 14) | Sim | Sim | Sim | Sim | Sim | Sim | Sim | Sim | Sim |
| DH (Grupos 19, 20) | Não | Sim | Não | Sim | Não | Sim | Sim | Sim | Sim |
| DH (Grupos 15, 16) | Não | Sim | Não | Sim | Não | Sim | Sim | Sim | Sim |
| Grupo DH 21 | Não | Sim | Não | Sim | Não | Sim | Sim | Sim | Sim |
| Grupo DH 24 | Sim | Sim | Sim | Sim | Sim | Sim | Não | Não | Não |
| RSA | Sim | Sim | Sim | Sim | Sim | Sim | Sim | Sim | Sim |
| ECDSA (256, 384, 521) | Não | Sim | Não | Sim | Não | Sim | Sim | Sim | Sim |
Para instalar o pacote Junos IKE em seu firewall da Série SRX, use o seguinte comando:
user@host> request system software add optional://junos-ike.tgz Verified junos-ike signed by PackageProductionECP256_2022 method ECDSA256+SHA256 Rebuilding schema and Activating configuration... mgd: commit complete Restarting MGD ... WARNING: cli has been replaced by an updated version: CLI release 20220208.163814_builder.r1239105 built by builder on 2022-02-08 17:07:55 UTC Restart cli using the new version ? [yes,no] (yes)
Para usar o processo para habilitar recursos de VPN IPsec em SRX5000 linha sem uma placa SPC3, você deve executar o comando.kmdrequest system software delete junos-ike Depois de executar o comando, reinicialize o dispositivo.
Para verificar o pacote instalado , use o seguinte comando:junos-ike
user@host> show version | grep ike
JUNOS ike [20190617.180318_builder_junos_182_x41]
JUNOS ike [20190617.180318_builder_junos_182_x41]
{primary:node0}
Consulte também
Suporte a recursos de VPN IPsec com novo pacote
Os dois processos e suporte a recursos de VPN IPsec em firewalls da Série SRX.ikedikemd Uma única instância e executada no mecanismo de roteamento de cada vez.ikedikemd
Por padrão, o pacote é instalado no Junos OS Release 19.4R1 e posterior para SRX5K-SPC3 com RE3.junos-ike Tanto os processos em execução no Mecanismo de Roteamento estão disponíveis com este pacote.ikedikemd No SRX5K-SPC3 com RE2, este é um pacote opcional e precisa ser instalado explicitamente.
Para reiniciar o processo no Mecanismo de Rotina, use o comando.ikemdrestart ike-config-management
Para reiniciar o processo no mecanismo de roteamento, use o comando.ikedrestart ike-key-management
mostra os detalhes das versões do Junos OS onde o pacote é introduzido.Tabela 6junos-ike
|
Plataforma |
Versão do Junos OS com pacote |
|---|---|
|
SRX5K-SPC3 com RE3 |
19.4R1 e posterior como pacote padrão |
|
SRX5K-SPC3 com RE2 |
18.2R1 e posterior como pacote opcional |
|
Firewall virtual vSRX |
20.3R1 e posterior como pacote opcional |
|
SRX1500 |
22.3R1 e posterior como pacote opcional |
|
SRX4100, SRX4200, SRX4600 |
22.3R1 e posterior como pacote opcional |
|
SRX1600, SRX2300 |
23.4R1 e posterior como pacote padrão |
Ignorar as versões especificadas de versão do Junos OS ao instalar o pacote pode resultar em recursos não suportados que não funcionem como esperado.junos-ike
Para operar recursos de VPN IPsec usando o processo legado em SRX5000 linha sem uma placa SRX5K-SPC3, você deve executar o comando e reiniciar o dispositivo.kmdrequest system software delete junos-ike
Recursos de VPN IPsec não suportados
Esta seção oferece um resumo dos recursos e configurações de VPN IPsec que não têm suporte de SRX5000 linha com SRX5K-SPC3 e em instâncias de firewall virtual vSRX.
Para determinar se um recurso é suportado por uma plataforma específica ou versão do Junos OS, consulte o Feature Explorer.https://pathfinder.juniper.net/feature-explorer/
Tabela 7 resume os recursos de VPN IPsec não suportados em firewalls da Série SRX e no firewall virtual vSRX em execução:
|
Recursos |
Suporte em SRX5000 linha com instâncias de firewall virtual SRX5K-SPC3 e vSRX |
|---|---|
|
Modo multicast independente de protocolo autoVPN (PIM). |
Não |
|
Configuração da classe de encaminhamento em VPNs IPsec. |
Não |
|
VPN em grupo. |
Não |
|
Configuração do tamanho do pacote para verificação de datapath IPsec. |
Não |
|
VPN IPsec baseada em políticas. |
Não |
Suporte a protocolos de roteamento em túneis de VPN IPsec
Oferecemos suporte a protocolos de roteamento como, OSPF, BGP, PIM, RIP e BFD para serem executados em túneis IPsec em firewalls da Série SRX e roteadores da kmdSérie MX em execução ou ikedprocesso. 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 8 resume o suporte ao protocolo OSPF em firewalls da Série SRX e roteadores MX.
| 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 |
| Firewall virtual vSRX 3.0 | Sim | Não | Sim | Não |
| MX-SPC3 | Sim | Não | Não | Não |
Tabela 9 resume o suporte ao protocolo OSPFv3 em firewalls da Série SRX e roteadores MX.
| 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 |
| Firewall virtual vSRX 3.0 | Não | Sim | Não | Sim |
| MX-SPC3 | Não | Sim | Não | Não |
Tabela 10 resume o suporte ao protocolo BGP em firewalls da Série SRX e roteadores MX.
| 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 |
| Firewall virtual vSRX 3.0 | Sim | Sim | Sim | Sim |
| MX-SPC3 | Sim | Sim | Não | Não |
Tabela 11 resume o suporte ao protocolo PIM em firewalls da Série SRX e roteadores MX.
| 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 |
| Firewall virtual vSRX | Sim | Não | Sim Nota:
A multi-leitura não é suportada. |
Não |
| MX-SPC3 | Sim | Não | Não | Não |
Tabela 12 resume o suporte ao protocolo RIP em firewalls da Série SRX e roteadores MX.
| 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 |
| Firewall virtual vSRX 3.0 | Sim | Sim | Não | Não |
| MX-SPC3 | Sim | Sim | Não | Não |
Tabela 13 resume o suporte ao protocolo BFP em firewalls da Série SRX e roteadores MX.
| 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 |
| Firewall virtual vSRX 3.0 | Sim | Sim | Sim | Sim |
| MX-SPC3 | Sim | Sim | Não | Não |
Janela anti-replay
Nos firewalls da Série SRX, é habilitado por padrão com um valor de tamanho de janela de 64.anti-replay-window
Na linha SRX Série 5000 com placas SPC3 instaladas, você pode configurar o tamanho na faixa de 64 a 8192 (potência de 2).anti-replay-window Para configurar o tamanho da janela, use a nova opção.anti-replay-window-size Um pacote de entrada é validado para ataque de repetição com base no que está configurado.anti-replay-window-size
Você pode configurar em dois níveis diferentes:replay-window-size
-
— Configurada no nível [] de hierarquia.Global level
edit security ipsecPor exemplo:
[edit security ipsec] user@host# set anti-replay-window-size <64..8192>;
-
— Configurada no nível [] de hierarquia.VPN object
edit security ipsec vpn vpn-name ikePor exemplo:
[edit security ipsec vpn vpn-name ike] user@host# set anti-replay-window-size <64..8192>;
Se o anti-replay estiver configurado em ambos os níveis, o tamanho da janela configurado para um nível de objeto VPN prevalece 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 comando no nível [] de hierarquia.set no-anti-replayedit security ipsec vpn vpn-name ike Você não pode desabilitar o anti-replay em nível global.
Você não pode configurar ambos e em um objeto VPN.anti-replay-window-sizeno-anti-replay
Consulte também
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 firewalls da Série SRX oferecem suporte apenas ao recurso hub-and-spoke baseado em rota.
Consulte também
Tabela de histórico de alterações
A compatibillidadde com o recurso dependerá da platadorma e versão utilizada. Use o Feature Explorer para saber se o recurso é compatível com sua plataforma.
junos-ike Como resultado , e o processo é executado no mecanismo de roteamento por padrão, em vez de daemon de gerenciamento de chave IPsec (kmd).ikedikemd