Túneis IPsec com endpoints dinâmicos

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.

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.

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.

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

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.

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 mesmo 0::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 em hexadecimal ou ascii-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 valor any-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.

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] :

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.

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:

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.

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.

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.

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 para shared 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.