Túneis IPsec com endpoints dinâmicos
Configuração de endpoints dinâmicos para túneis IPsec
Os túneis IPsec também podem ser estabelecidos usando gateways dinâmicos de segurança por pares , nos quais as extremidades remotas dos túneis não têm um endereço IP atribuído estaticamente. Como o endereço remoto não é conhecido e pode ser retirado de um pool de endereços cada vez que o host remoto reinicializa, o estabelecimento do túnel depende do uso do modo IKE main
com chaves globais pré-compartilhadas ou certificados digitais que aceitam qualquer valor de identificação remota. Os túneis baseados em políticas e do tipo de enlace são suportados:
Os túneis baseados em políticas usavam o modo compartilhado.
Os túneis do tipo de enlace ou roteamento usam o modo dedicado. Cada túnel aloca uma interface de serviços a partir de um pool de interfaces configuradas para os pares dinâmicos. Os protocolos de roteamento podem ser configurados para serem executados nessas interfaces de serviços para aprender rotas pelo túnel IPsec que é usado como um link neste cenário.
Esta seção inclui os seguintes tópicos:
- Processo de autenticação
- Regras dinâmicas implícitas
- Inserção de rota reversa
- Configuração de um perfil de acesso IKE
- Fazendo referência ao perfil de acesso IKE em um conjunto de serviços
- Configurando o identificador de interface
- Propostas padrão de IKE e IPsec
- Distribuição de túneis IPsec de endpoint entre interfaces de serviços
Processo de autenticação
O peer remoto (dinâmico) inicia as negociações com o roteador local (Juniper Networks). O roteador local usa as políticas padrão de IKE e IPsec para combinar com as propostas enviadas pelo peer remoto para negociar os valores da associação de segurança (SA). As propostas implícitas contêm uma lista de todas as transformações apoiadas que o roteador local espera de todos os pares dinâmicos.
Se a autenticação de chave pré-compartilhada for usada, a chave pré-compartilhada é global para um conjunto de serviços. Ao buscar a chave pré-compartilhada para o peer, o roteador local corresponde ao endereço de origem do peer em relação a quaisquer chaves pré-compartilhadas explicitamente configuradas nesse conjunto de serviços. Se uma correspondência não for encontrada, o roteador local usa a chave global pré-compartilhada para autenticação.
A fase 2 da autenticação corresponde às identidades de proxy dos hosts e redes protegidos enviados pelo peer contra uma lista de identidades proxy configuradas. A identidade proxy aceita é usada para criar as regras dinâmicas para criptografar o tráfego. Você pode configurar identidades de proxy incluindo a allowed-proxy-pair
declaração no perfil de acesso IKE. Se não houver correspondência de entrada, a negociação é recusada.
Se você não configurar a allowed-proxy-pair
declaração, o valor ANY(0.0.0.0/0)-ANY
padrão será aplicado e o roteador local aceitará quaisquer identidades de proxy enviadas pelo peer. Ambos os endereços IPv4 e IPv6 são aceitos, mas você deve configurar todos os endereços IPv6 manualmente.
Assim que a negociação da fase 2 for concluída com sucesso, o roteador cria as regras dinâmicas e insere a rota inversa na tabela de roteamento usando a identidade proxy aceita.
Regras dinâmicas implícitas
Após uma negociação bem-sucedida com o peer dinâmico, o processo de gerenciamento chave (kmd) cria uma regra dinâmica para o proxy de fase 2 aceito e aplica-o no AS local ou pic multisserviços. Os endereços de origem e destino são especificados pelo proxy aceito. Essa regra é usada para criptografar o tráfego direcionado a um dos hosts finais na identidade de proxy da fase 2.
A regra dinâmica inclui um ipsec-inside-interface
valor, que é o nome de interface atribuído ao túnel dinâmico. Os source-address
valores e valores destination-address
são aceitos pela ID por proxy. O match-direction
valor é input
para conjuntos de serviços no estilo next-hop.
Você não configura essa regra; é criado pelo processo de gerenciamento chave (kmd).
A busca por túneis estáticos não é afetada pela presença de uma regra dinâmica; é executado na ordem configurada. Quando um pacote é recebido por um conjunto de serviços, as regras estáticas são sempre combinadas primeiro.
As regras dinâmicas são combinadas após a correspondência de regras para regras estáticas falhar.
A resposta a mensagens de olá de detecção de peer (DPD) mortas ocorre da mesma maneira com pares dinâmicos que com pares estáticos. O início das mensagens de olá de DPD de colegas dinâmicos não é suportado.
Inserção de rota reversa
As rotas estáticas são inseridas automaticamente na tabela de rota para essas redes e hospedam protegidas por um endpoint remoto de túnel. Esses hosts e redes protegidos são conhecidos como identidades de proxy remoto.
Cada rota é criada com base na rede de proxy remoto e na máscara enviada pelo peer e é inserida na tabela de rotas relevante após negociações bem-sucedidas da fase 1 e fase 2.
A preferência de rota por cada rota reversa estática é 1. Esse valor é necessário para evitar conflitos com rotas semelhantes que podem ser adicionadas pelo processo de protocolo de roteamento (rpd).
Não serão adicionadas rotas se o endereço proxy remoto aceito for o padrão (0.0.0.0/0
). Neste caso, você pode executar protocolos de roteamento pelo túnel IPsec para aprender rotas e adicionar rotas estáticas para o tráfego que você deseja estar protegido por este túnel.
Para conjuntos de serviços no estilo next-hop, as rotas inversas incluem próximos saltos apontando para os locais especificados pela inside-service-interface
declaração.
A tabela de rotas para inserir essas rotas depende de onde a inside-service-interface
localização está listada. Se essas interfaces estiverem presentes em uma instância de roteamento e encaminhamento VPN (VRF), então as rotas serão adicionadas à tabela VRF correspondente; caso contrário, as rotas são adicionadas.inet.0
A inserção de rota reversa ocorre apenas para túneis a pares dinâmicos. Essas rotas são adicionadas apenas para conjuntos de serviços no estilo next-hop.
Configuração de um perfil de acesso IKE
Você pode configurar apenas um perfil de túnel por conjunto de serviços para todos os pares dinâmicos. A chave pré-compartilhada configurada no perfil é usada para autenticação de IKE de todos os pares dinâmicos que terminam nesse conjunto de serviços. Alternativamente, você pode incluir a ike-policy
declaração para consultar uma política de IKE que você define com valores de identificação específicos ou um curinga (a opção any-remote-id
). Você configura a política de IKE no nível de [edit services ipsec-vpn ike]
hierarquia.
O perfil do túnel IKE especifica todas as informações necessárias para concluir a negociação da IKE. Cada protocolo tem sua própria hierarquia de declaração dentro da declaração do cliente para configurar pares de valor de atributo específicos do protocolo, mas apenas uma configuração de cliente é permitida para cada perfil. A seguir, a configuração no nível de [edit access]
hierarquia; para obter mais informações sobre perfis de acesso, consulte a Biblioteca de administração do Junos OS para dispositivos de roteamento.
[edit access] profile profile-name { client * { ike { allowed-proxy-pair { remote remote-proxy-address local local-proxy-address; } pre-shared-key (ascii-text key-string | hexadecimal key-string); ike-policy policy-name; interface-id <string-value>; ipsec-policy ipsec-policy; } } }
Para pares dinâmicos, o Junos OS oferece suporte ao modo principal IKE com o método chave de autenticação pré-compartilhado ou um perfil de acesso IKE que usa um certificado digital local.
No modo chave pré-compartilhado, o endereço IP é usado para identificar um peer de túnel para obter as informações chave pré-compartilhadas. O
client
valor*
(curinga) significa que a configuração dentro desse perfil é válida para todos os pares dinâmicos que terminam dentro do conjunto de serviços que acessam este perfil.No modo de certificado digital, a política de IKE define quais valores de identificação remota são permitidos.
As seguintes declarações compõem o perfil IKE:
allowed-proxy-pair
— Durante a negociação de IKE da fase 2, o peer remoto fornece seu endereço de rede (remote
) e o endereço de rede de seus pares (local
). Como vários túneis dinâmicos são autenticados pelo mesmo mecanismo, essa declaração deve incluir a lista de possíveis combinações. Se o peer dinâmico não apresentar uma combinação válida, a negociação de IKE da fase 2 falhará.Por padrão,
remote 0.0.0.0/0 local 0.0.0.0/0
é usado se nenhum valor estiver configurado. Os formatos de endereço IPv4 e IPv6 são suportados nesta configuração, mas não há endereços IPv6 padrão. Você deve especificar mesmo0::0/0
.pre-shared-key
— Chave usada para autenticar o peer dinâmico durante a negociação da fase 1 do IKE. Essa chave é conhecida por ambas as extremidades por meio de um mecanismo seguro fora de banda. Você pode configurar o valor emhexadecimal
ouascii-text
formato. É um valor obrigatório.ike-policy
— Política que define os valores de identificação remota correspondentes aos pares dinâmicos permitidos; pode conter um valorany-remote-id
curinga para uso apenas em configurações dinâmicas de endpoint.interface-id
— Identificador de interface, um atributo obrigatório usado para obter as informações de interface de serviços lógicos para a sessão.ipsec-policy
— Nome da política de IPsec que define as informações da política de IPsec para a sessão. Você define a política de IPsec no nível hierárquica[edit services ipsec-vpn ipsec policy policy-name]
. Se nenhuma política for definida, qualquer política proposta pelo peer dinâmico é aceita.
Fazendo referência ao perfil de acesso IKE em um conjunto de serviços
Para concluir a configuração, você precisa consultar o perfil de acesso IKE configurado no nível de [edit access]
hierarquia. Para fazer isso, inclua a ike-access-profile
declaração no nível hierárquica [edit services service-set name ipsec-vpn-options]
:
[edit services service-set name] ipsec-vpn-options { local-gateway address; ike-access-profile profile-name; } next-hop-service { inside-service-interface interface-name; outside-service-interface interface-name; }
A ike-access-profile
declaração deve fazer referência ao mesmo nome da profile
declaração configurada para acesso IKE no nível de [edit access]
hierarquia. Você pode consultar apenas um perfil de acesso em cada conjunto de serviços. Esse perfil é usado para negociar associações de segurança IKE e IPsec apenas com pares dinâmicos.
Todas as interfaces mencionadas pela inside-service-interface
declaração em um conjunto de serviços devem pertencer à mesma instância VRF.
Configurando o identificador de interface
Você pode configurar um identificador de interface para um grupo de pares dinâmicos, que especifica quais(s) interface lógica de serviços adaptativos participam na negociação dinâmica de IPsec. Ao atribuir o mesmo identificador de interface a várias interfaces lógicas, você pode criar um pool de interfaces para essa finalidade. Para configurar um identificador de interface, inclua a ipsec-interface-id
declaração e a dedicated
declaração shared
no nível de [edit interfaces interface-name unit logical-unit-number dial-options]
hierarquia:
[edit interfaces interface-name unit logical-unit-number dial-options] ipsec-interface-id identifier; (dedicated | shared);
Especificar o identificador de dial-options
interface na declaração torna essa interface lógica parte do pool identificada pela ipsec-interface-id
declaração.
Apenas um identificador de interface pode ser especificado de cada vez. Você pode incluir a ipsec-interface-id
declaração ou a l2tp-interface-id
declaração, mas não ambos.
Se você configurar shared
o modo, ele permite que uma interface lógica seja compartilhada em vários túneis. A dedicated
declaração especifica que a interface lógica é usada em um modo dedicado, o que é necessário quando você está configurando um túnel do tipo de link IPsec. Você deve incluir a dedicated
declaração quando especificar um ipsec-interface-id
valor.
Propostas padrão de IKE e IPsec
O software inclui propostas implícitos de IKE e IPsec para combinar com as propostas enviadas pelos pares dinâmicos. Os valores são mostrados na Tabela 1; se for mostrado mais de um valor, o primeiro valor é o padrão.
Os certificados RSA não são suportados com configuração dinâmica de endpoint.
Nome da declaração |
Valores |
---|---|
Proposta IKE implícita | |
|
|
|
|
|
|
|
|
|
|
Proposta IPsec implícita | |
|
|
|
|
|
|
|
|
Distribuição de túneis IPsec de endpoint entre interfaces de serviços
A partir do Junos OS Release 16.2R1, você pode distribuir túneis IPsec com endpoints dinâmicos entre vários MS-MICs ou entre vários PICs de serviço de um MS-MPC. Você configura a distribuição de túneis configurando um conjunto de serviços IPsec de próximo salto para a interface multisserviços (ms-) de cada serviço PIC. A partir do Junos OS Release 17.1R1, você também pode distribuir túneis IPsec com endpoints dinâmicos entre interfaces agregadas de multisserviços (AMS) de MS-MICs ou MS-MPCs configurando um conjunto de serviços IPsec de próximo salto para cada interface AMS.
Mais tarde, você pode adicionar hardware PIC de serviço ao roteador da Série MX e incluir o PIC de serviço na distribuição de túneis simplesmente adicionando outro conjunto de serviços, sem precisar alterar a configuração dos peers IPsec.
Para configurar a distribuição de túneis, execute as seguintes etapas ao configurar túneis IPsec dinâmicos de endpoint:
Configure um conjunto de serviços IPsec de próximo salto para cada interface de serviços ou interface AMS usada pelo túnel IPsec dinâmico de endpoint (veja referência ao perfil de acesso IKE em um conjunto de serviços). Todos os conjuntos de serviços devem:
Use o mesmo tipo de interface de serviços — interfaces multisserviços (ms-) ou interfaces AMS (ams-).
Tenha uma interface na
outside-service
declaração que está na mesma instância de roteamento e encaminhamento vpn (VRF) que as interfaces nos outros conjuntos de serviços.Tenha o mesmo
local-gateway
endereço IP.Tenha o mesmo
ike-access-profile
nome.
Ao configurar o identificador de interface (ver Configuração do identificador de interface), é
ipsec-interface-id identifier
necessário configurar:Somente em interfaces que aparecem nas
inside-service-set
declarações dos conjuntos de serviços.Com
dedicated
para todas as interfaces ou parashared
todas as interfaces.Sob não mais do que uma unidade compartilhada de uma interface.
Somente em interfaces configuradas com
service-domain inside
.Somente em interfaces que estão no mesmo VRF.
Exemplo: configuração de túneis baseados em políticas atribuídos dinamicamente
Este exemplo mostra como configurar túneis baseados em políticas atribuídos dinamicamente e contém as seguintes seções.
Requisitos
Este exemplo usa os seguintes componentes de hardware e software:
-
Três roteadores Série M, Série MX ou Série T.
-
Junos OS Release 9.4 ou posterior.
Visão geral e topologia
Uma política de IPsec para endpoints dinâmicos define uma combinação de parâmetros de segurança (propostas IPsec) usados durante a negociação de IPsec entre gateways dinâmicos de segurança por pares, nos quais as extremidades remotas dos túneis não têm um endereço IP atribuído estaticamente.
Uma VPN baseada em políticas é uma configuração com um túnel VPN específico mencionado em uma política que funciona como um túnel. Você usa uma VPN baseada em políticas se o dispositivo VPN remoto for um dispositivo não-Juniper e se você deve acessar apenas uma sub-rede ou uma rede no site remoto, em toda a VPN.
Este exemplo explica a topologia dinâmica de tunelamento de endpoint IPsec, conforme mostrado na Figura 1.
Antes de configurar túneis atribuídos dinamicamente, certifique-se de ter:
-
Uma rede local N-1 conectada a um gateway de segurança SG-1. Os pontos de saída devem ter um roteador Juniper Networks para encerrar os endpoints estáticos e dinâmicos de peer. O endereço de terminação de túnel no SG-1 é 10.1.1.1 e o endereço de rede local é 172.16.1.0/24.
-
Dois roteadores de peer remotos que obtêm endereços de um pool ISP e executam um IKE compatível com RFC. A rede remota N-2 tem o endereço 172.16.2.0/24 e está conectada ao gateway de segurança SG-2 com o endereço de terminação de túnel 10.2.2.2. A rede remota N-3 tem o endereço 172.16.3.0/24 e está conectada ao gateway de segurança SG-3 com o endereço de terminação de túnel 10.3.3.3.
Topologia
Configuração
Para configurar túneis baseados em políticas atribuídos dinamicamente, execute essas tarefas:
Os tipos de interface mostrados neste exemplo são apenas para finalidade indicativa. Por exemplo, você pode usar so-
interfaces em vez de ge-
sp-
ms-
.
Configuração rápida da CLI
Para configurar rapidamente este exemplo, copie os seguintes comandos, cole-os em um arquivo de texto, remova qualquer quebra de linha, altere os detalhes necessários para combinar com a configuração da sua rede e, em seguida, copie e cole os comandos no CLI, no nível de hierarquia [edit] do roteador SG1.
Configuração de interfaces
set interfaces ms-0/0/0 unit 0 family inet set interfaces ms-0/0/0 unit 1 family inet set interfaces ms-0/0/0 unit 1 service-domain inside set interfaces ms-0/0/0 unit 1 dial-options ipsec-interface-id demo-ipsec-interface-id set interfaces ms-0/0/0 unit 1 dial-options shared set interfaces ms-0/0/0 unit 2 family inet set interfaces ms-0/0/0 unit 2 service-domain outside
Configuração do perfil de acesso
set access profile demo-access-profile client * ike allowed-proxy-pair remote 172.16.2.0/24 local 172.16.1.0/24 set access profile demo-access-profile client * ike allowed-proxy-pair remote 172.16.3.0/24 local 172.16.1.0/24 set access profile demo-access-profile client * ike ascii-text keyfordynamicpeers set access profile demo-access-profile client * ike interface-id demo-ipsec-interface-id
Configuração do conjunto de serviços
set services service-set demo-service-set next-hop-service inside-service-interface ms-0/0/0.1 set services service-set demo-service-set next-hop-service outside-service-interface ms-0/0/0.2
Configuração de propriedades IPsec
set services ipsec-vpn ipsec proposal ipsec_proposal_demo1 protocol esp set services ipsec-vpn ipsec proposal ipsec_proposal_demo1 authentication-algorithm hmac-sha1-96 set services ipsec-vpn ipsec proposal ipsec_proposal_demo1 encryption-algorithm 3des-cbc set services ipsec-vpn ipsec policy demo2 perfect-forward-secrecy keys group2 set services ipsec-vpn ipsec policy demo2 proposals ipsec_proposal_demo1 set services ipsec-vpn ike proposal ike_proposal_demo1 authentication-method pre-shared-keys set services ipsec-vpn ike proposal ike_proposal_demo1 dh-group group2 set services ipsec-vpn ike policy ike_policy_demo1 version 2 set services ipsec-vpn ike policy ike_policy_demo1 proposals ike_proposal_demo1 set services ipsec-vpn ike policy ike_policy_demo1 pre-shared-key ascii-text keyfordemo1
Configuração de instâncias de roteamento
set routing-instances demo-vrf instance-type vrf set routing-instances demo-vrf ms-0/0/0.1 set routing-instances demo-vrf ms-0/0/0.2
Configurando um conjunto de serviços SG1 de próximo salto
Procedimento passo a passo
Procedimento passo a passo
O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração.
-
Configure as interfaces.
[edit interfaces] user@router1# set interfaces ms-0/0/0 unit 0 family inet user@router1# set interfaces ms-0/0/0 unit 1 family inet user@router1# set interfaces ms-0/0/0 unit 1 service-domain inside user@router1# set interfaces ms-0/0/0 unit 1 dial-options ipsec-interface-id demo-ipsec-interface-id user@router1# set interfaces ms-0/0/0 unit 1 dial-options mode shared user@router1# set interfaces ms-0/0/0 unit 2 family inet user@router1# set interfaces ms-0/0/0 unit 2 service-domain outside
-
Configure o perfil de acesso.
[edit access] user@router1# set profile demo-access-profile client * ike allowed-proxy-pair remote 172.16.2.0/24 local 172.16.1.0/24 user@router1# set profile demo-access-profile client * ike ascii-text keyfordynamicpeers user@router1# set profile demo-access-profile client * ike interface-id demo-ipsec-interface-id
-
Configure o conjunto de serviços.
[edit services] user@router1# set service-set demo-service-set next-hop-service inside-service-interface ms-0/0/0.1 user@router1# set service-set demo-service-set next-hop-service outside-service-interface ms-0/0/0.2
-
Configure as propriedades IPsec.
[edit services ipsec-vpn] user@router1#set ipsec proposal ipsec_proposal_demo1 protocol esp user@router1#set ipsec proposal ipsec_proposal_demo1 authentication-algorithm hmac-sha1-96 user@router1#set ipsec proposal ipsec_proposal_demo1 encryption-algorithm 3des-cbc user@router1#set ipsec policy demo2 perfect-forward-secrecy keys group2 user@router1#set ipsec policy demo2 proposals ipsec_proposal_demo1 user@router1#set ike proposal ike_proposal_demo1 authentication-method pre-shared-keys user@router1#set ike proposal ike_proposal_demo1 dh-group group2 user@router1#set ike policy ike_policy_demo1 version 2 user@router1#set ike policy ike_policy_demo1 proposals ike_proposal_demo1 user@router1#set ike policy ike_policy_demo1 pre-shared-key ascii-text keyfordemo1
-
Configure as instâncias de roteamento.
[edit routing-instances] user@router1# set demo-vrf instance-type vrf user@router1# set demo-vrf ms-0/0/0.1 user@router1# set demo-vrf ms-0/0/0.2
Resultados
A partir do modo de configuração do Roteador 1, confirme sua configuração entrando no show interfaces
, show access
e show services
comandos. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.
interfaces { ms-0/0/0 { unit 0 { family inet; } unit 1 { family inet; service-domain inside; dial-options { ipsec-interface-id demo-ipsec-interface-id; mode shared; } } unit 2 { family inet; service-domain outside; } } } access { profile demo-access-profile client * { ike { allowed-proxy-pair { remote 172.16.2.0/24 local 172.16.1.0/24; #Set for Network 2 connected to Network 1 remote 172.16.3.0/24 local 172.16.1.0/24; #Set for Network 3 connected to Network 1 } pre-shared-key { ascii-text keyfordynamicpeers; } interface-id demo-ipsec-interface-id; } } } services { service-set demo-service-set { next-hop-service { inside-service-interface ms-0/0/0.1; outside-service-interface ms-0/0/0.2; } ipsec-vpn-options { local-gateway 10.1.1.1; ike-access-profile demo-access-profile; } } ipsec-vpn { ipsec { proposal ipsec_proposal_demo1 { protocol esp; authentication-algorithm hmac-sha1-96; encryption-algorithm 3des-cbc; } policy demo2 { perfect-forward-secrecy { keys group2; } proposals ipsec_proposal_demo1; } } ike { proposal ike_proposal_demo1 { authentication-method pre-shared-keys; dh-group group2; } policy ike_policy_demo1 { version 2; proposals ike_proposal_demo1; pre-shared-key ascii-text "$ABC123"; ## SECRET-DATA } } } } routing-instances { demo-vrf { instance-type vrf; interface ms-0/0/0.1; interface ms-0/0/0.2; } }
Verificação
Verificando se o conjunto de serviços SG1 de próximo salto com túneis baseados em políticas é criado
Propósito
Verifique se o conjunto de serviços SG1 de próximo salto com túneis baseados em políticas foi criado.
Ação
A partir do modo operacional, entre no show route
comando.
user@router1> show route demo-vrf.inet.0: .... # Routing instance 172.11.0.0/24 *[Static/1].. > via ms-0/0/0.1 172.12.0.0/24 *[Static/1].. > via ms-0/0/0.1
A partir do modo operacional, entre no show services ipsec-vpn ipsec security-associations detail
user@router1>show services ipsec-vpn ipsec security-associations detail rule: junos-dynamic-rule-0 term: term-0 local-gateway-address : 10.1.1.1 #Tunnel termination address on SG-1 remote-gateway-address: 10.2.2.2 #Tunnel termination address on SG-2 source-address : 0.0.0.0/0 destination-address : 0.0.0.0/0 ipsec-inside-interface: ms-0/0/0.1 term: term-1 local-gateway-address : 10.1.1.1 #Tunnel termination address on SG-1 remote-gateway-address: 10.3.3.3 #Tunnel termination address on SG-3 source-address : 0.0.0.0/0 destination-address : 0.0.0.0/0 IPsec Properties ipsec-inside-interface: ms-0/0/0.1 match-direction: input
Significado
A show services ipsec-vpn ipsec security-associations detail
saída de comando mostra as propriedades que você configurou.
Tabela de histórico de mudanças
O suporte de recursos é determinado pela plataforma e versão que você está usando. Use o Feature Explorer para determinar se um recurso é suportado em sua plataforma.