Túneis IPsec com endpoints dinâmicos

O remoto (peer 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 corresponder às 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 suportadas 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 será global para um conjunto de serviços. Ao buscar a chave pré-compartilhada para o peer, o roteador local compara o endereço de origem do peer com quaisquer chaves pré-compartilhadas configuradas explicitamente nesse conjunto de serviços. Se uma correspondência não for encontrada, o roteador local usará a chave global pré-compartilhada para autenticação.

A fase 2 da autenticação compara as identidades de proxy dos hosts e redes protegidos enviadas pelo peer com uma lista de identidades de proxy configuradas. A identidade de 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 nenhuma entrada corresponder, a negociação será rejeitada.

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á todas as 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.

Quando a negociação da fase 2 é concluída com sucesso, o roteador cria as regras dinâmicas e insere a rota reversa na tabela de roteamento usando a identidade de proxy aceita.

Após a negociação bem-sucedida com o peer dinâmico, o processo de gerenciamento de chaves (kmd) cria uma regra dinâmica para o proxy de fase 2 aceito e a aplica no AS local ou no 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 da interface atribuído ao túnel dinâmico. Os source-address valores e destination-address são aceitos a partir do ID do proxy. O match-direction valor é input para conjuntos de serviços no estilo next-hop.

A pesquisa de regras para túneis estáticos não é afetada pela presença de uma regra dinâmica; É executado na ordem configurada. Quando um pacote é recebido para um conjunto de serviços, as regras estáticas são sempre correspondidas primeiro.

As regras dinâmicas são correspondidas após a falha da correspondência de regra para regras estáticas.

A resposta às mensagens de saudação de detecção de peer inativo (DPD) ocorre da mesma maneira com peers dinâmicos e com peers estáticos. Não há suporte para iniciar mensagens de saudação DPD de pares dinâmicos.

As rotas estáticas são inseridas automaticamente na tabela de rotas para essas redes e hosts protegidos por um endpoint de túnel remoto. Esses hosts e redes protegidos são conhecidos como identidades proxy remotas.

Cada rota é criada com base na rede proxy remota e na máscara enviada pelo peer e é inserida na tabela de rotas relevante após negociações bem-sucedidas da fase 1 e da fase 2.

A preferência de rota para 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).

Nenhuma rota será adicionada se o endereço de proxy remoto aceito for o padrão (0.0.0.0/0). Nesse caso, você pode executar protocolos de roteamento no túnel IPsec para aprender rotas e adicionar rotas estáticas para o tráfego que deseja proteger nesse túnel.

Para conjuntos de serviços no estilo next-hop, as rotas reversas incluem próximos hops apontando para os locais especificados pela inside-service-interface instrução.

A tabela de rotas na qual inserir essas rotas depende de onde o inside-service-interface local está listado. Se essas interfaces estiverem presentes em uma instância de roteamento e encaminhamento (VRF) de VPN, as rotas serão adicionadas à tabela VRF correspondente; caso contrário, as rotas serão adicionadas ao 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. Como alternativa, você pode incluir a ike-policy instrução para fazer referência a uma política de IKE definida com valores de identificação específicos ou um curinga (a any-remote-id opção). Você configura a política de IKE no nível de [edit services ipsec-vpn ike] hierarquia.

O perfil de túnel IKE especifica todas as informações necessárias para concluir a negociação de IKE. Cada protocolo tem sua própria hierarquia de instrução dentro da instrução do cliente para configurar pares de valores de atributo específicos do protocolo, mas apenas uma configuração de cliente é permitida para cada perfil. A seguir está 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 instruções compõem o perfil IKE:

• allowed-proxy-pair— Durante a negociação do IKE da fase 2, o peer remoto fornece seu endereço de rede (remote) e o endereço de rede de seu peer (local). Como vários túneis dinâmicos são autenticados por meio do mesmo mecanismo, essa instrução deve incluir a lista de combinações possíveis. Se o peer dinâmico não apresentar uma combinação válida, a negociação do 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 nessa configuração, mas não há endereços IPv6 padrão. Você deve especificar até 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 formatar. É 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 somente em configurações de endpoint dinâmico.

• interface-id— Identificador de interface, um atributo obrigatório usado para derivar as informações da interface de serviços lógicos para a sessão.

• ipsec-policy— Nome da política IPsec que define as informações da política IPsec para a sessão. Você define a diretiva IPsec no nível da [edit services ipsec-vpn ipsec policy policy-name] hierarquia. Se nenhuma política for definida, qualquer política proposta pelo peer dinâmico será aceita.

Para concluir a configuração, você precisa fazer referência ao perfil de acesso IKE configurado no nível da [edit access] hierarquia. Para fazer isso, inclua a ike-access-profile instrução no nível da [edit services service-set name ipsec-vpn-options] hierarquia:

A ike-access-profile declaração deve fazer referência ao mesmo nome que a profile declaração que você configurou para acesso ao IKE no nível de [edit access] hierarquia. Você pode fazer referência a 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 referenciadas pela instrução dentro de inside-service-interface um conjunto de serviços devem pertencer à mesma instância VRF.

Você pode configurar um identificador de interface para um grupo de peers dinâmicos, que especifica quais interfaces lógicas de serviços adaptativos participam da negociação de IPsec dinâmico. 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 declaração e a ipsec-interface-id dedicated instrução or shared no nível da [edit interfaces interface-name unit logical-unit-number dial-options] hierarquia:

Especificar o identificador de interface na dial-options instrução torna essa interface lógica parte do pool identificado pela ipsec-interface-id instrução.

Se você configurar shared o modo, ele permitirá 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 enlace IPsec. Você deve incluir a dedicated instrução ao especificar um ipsec-interface-id valor.

O software inclui propostas implícitas de IKE e IPsec padrão para corresponder às propostas enviadas pelos pares dinâmicos. Os valores são mostrados na Tabela 1; Se mais de um valor for mostrado, o primeiro valor será 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únel configurando um conjunto de serviços IPsec de próximo salto para a interface de multisserviços (ms-) de cada PIC de serviço. 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 next-hop para cada interface AMS.

Posteriormente, 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únel simplesmente adicionando outro conjunto de serviços, sem a necessidade de mudar a configuração dos pares IPsec.

Para configurar a distribuição de túneis, execute as seguintes etapas ao configurar túneis IPsec de endpoint dinâmico:

• Configure um conjunto de serviços IPsec next-hop para cada interface de serviços ou interface AMS usada pelo túnel IPsec do endpoint dinâmico (consulte Referenciando o 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 instrução que esteja na mesma instância de roteamento e encaminhamento de VPN (VRF) que as interfaces nos outros conjuntos de serviços.

  • Ter o mesmo local-gateway endereço IP.

  • Ter o mesmo ike-access-profile nome.

• Ao configurar o identificador de interface (consulte Configurando o identificador de interface), o ipsec-interface-id identifier deve ser configurado:

  • Somente em interfaces que aparecem nas inside-service-set instruções dos conjuntos de serviços.

  • Com dedicated para todas as interfaces ou com shared para todas as interfaces.

  • Em 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.