Visão geral do grupo VPNv2

Entender o VPNv2 do grupo

O Grupo VPN é um grupo confiável para eliminar túneis ponto a ponto e o roteamento overlay associado. Todos os membros do grupo compartilham uma associação de segurança comum (SA), conhecida como SA do grupo (GSA). A GSA permite que os membros do grupo descriptografem o tráfego criptografado por qualquer outro membro do grupo. A partir do Junos OS Release 18.2R1, confirmamos a redundância de VPN do grupo com o protocolo de redundância de serviços [SRD] em execução em roteadores MX. Os roteadores MX com redundância entre eles atuam como membros do Grupo VPN. Para obter mais detalhes sobre o protocolo de redundância de serviços, consulte a visão geral do Daemon de redundância de serviços.

A partir do Junos OS Release 15.1, o Junos OS oferece suporte ao Grupo VPNv2. O Grupo VPNv2 é uma categoria de VPN que elimina a necessidade de túneis VPN ponto a ponto em uma arquitetura de malha. É um conjunto de recursos necessários para proteger o tráfego unicast em uma WAN privada que se origina em ou flui através de um roteador.

O Grupo VPNv2 introduz o conceito de um grupo confiável para eliminar túneis ponto a ponto e o roteamento overlay associado. Todos os membros do grupo compartilham uma associação de segurança comum (SA), também conhecida como SA do grupo. Isso permite que os membros do grupo descriptografem tráfego criptografado por qualquer outro membro do grupo.

O VPNv2 do grupo oferece as seguintes vantagens:

• Fornece segurança de dados e autenticação de transporte, ajudando a atender à conformidade de segurança e à regulamentação interna criptografando todo o tráfego wan.

• Permite malhas de rede de alta escala e elimina o gerenciamento complexo de chaves peer-to-peer com chaves de criptografia de grupo.

• Reduz o número de mudanças de endpoint que precisam ser feitas devido à mudança de política ou mudança de política dos membros do grupo.

• Mantém a inteligência de rede, como conectividade de malha completa, caminho de roteamento natural e qualidade de serviço (QoS) em redes MPLS.

• Concede controle de membro autenticado com um servidor de chave centralizado.

• Permite criptografia e descriptografia de tráfego entre todos os membros do grupo definidos na política do grupo.

• Ajuda a garantir baixa latência e jitter, permitindo comunicações diretas e em tempo integral entre os locais, sem exigir o transporte por um hub central.

• Reduz as cargas de tráfego nos dispositivos de criptografia de equipamentos de instalações do cliente (CPE) e de borda de provedor (PE), usando a rede principal para replicação de tráfego, evitando a replicação de pacotes em cada local de peer individual.

VPNv2 do grupo e VPN IPsec padrão

O grupo VPNv2 é construído com base em tecnologias baseadas em padrões que integram roteamento e criptografia juntos na rede. Uma SA de segurança IPsec é um acordo unidirecional entre participantes de VPN que define as regras a usar para autenticação e algoritmos de criptografia, mecanismos de troca chave e comunicações seguras.

As implantações tradicionais de VPN IPsec resolvem o problema de proteger o tráfego entre gateways na rede, criando uma rede overlay com base no uso de túneis ponto a ponto. O tráfego transportado por esses túneis normalmente é criptografado e autenticado para fornecer integridade e confidencialidade dos dados. Os membros seguros do grupo são gerenciados por meio do protocolo de domínio de interpretação (GDOI) do grupo. A solução de GDOI adota uma abordagem diferente ao desassociar o problema de criptografia e autenticação do transporte. Ao fazer isso, as soluções baseadas em GDOI fornecem uma maneira de criptografar as comunicações de filial para filial sem a necessidade de configurar túneis de filial a filial.

Com as implementações de VPN atuais, o SA é um túnel ponto a ponto entre dois pontos finais. O Grupo VPNv2 estende a arquitetura IPsec para oferecer suporte a SAs compartilhados por um grupo de roteadores (consulte a Figura 1). Um servidor-chave distribui chaves e políticas para todos os roteadores membros registrados e autenticados. Ao distribuir políticas de um ponto centralizado e compartilhar a mesma associação de segurança de grupo (todo o grupo tem uma única SA fase 2) com membros autenticados do grupo, a distribuição e o gerenciamento de chaves são muito simplificados.

Figura 1: VPN IPsec padrão e VPNv2 de grupo

O VPNv2 do grupo é uma arquitetura de cliente/servidor. Todos os membros têm uma SA IKE única da Fase 1 com o servidor-chave. Portanto, se houver n membros, há um total de SAs IKE da n Fase 1. No entanto, todo o grupo compartilha uma única Sa Fase 2.

No IPsec tradicional, os endereços endpoint do túnel são usados como uma nova fonte e destino de pacotes. O pacote é então roteado pela infraestrutura IP, usando o endereço IP de origem de ponto final criptografado e o endereço IP de destino de ponto final de descriptografação. No caso da VPN do grupo, os pacotes de dados protegidos pelo IPsec preservam os endereços originais de origem e destino do host no cabeçalho IP externo, a fim de preservar o endereço IP. Isso é conhecido como preservação de cabeçalho de túnel. A maior vantagem da preservação do cabeçalho de túnel é a capacidade de rotear pacotes criptografados usando a infraestrutura de roteamento de rede subjacente.

Entender o protocolo GDOI

O protocolo de domínio de interpretação em grupo (GDOI) descrito no RFC 6407 é usado para distribuir um conjunto de chaves e políticas criptográficas para um grupo de dispositivos. O GDOI é definido como o Protocolo de Gerenciamento de Chaves (ISAKMP) da Internet Security Association para gerenciamento de chave de grupo. Em um modelo de gerenciamento de grupo, o protocolo GDOI opera entre um membro do grupo e um controlador de grupo ou servidor-chave (GC/KS) e gerencia associações de segurança de grupo e chaves de grupo para um conjunto de participantes de segurança. O ISAKMP define duas fases de negociação. O GDOI é um protocolo de Fase 2 protegido por uma associação de segurança ISAKMP fase 1. O IKEv1 é especificado no RFC 6407 como um protocolo de Fase 1.

O GDOI introduz duas chaves de criptografia diferentes:

• Chave de criptografia (KEK)— Usada para proteger o plano de controle. KEK é o nome da chave usada pelos membros do grupo para descriptografar mensagens rekey do GC/KS. Essa chave faz parte da chave de criptografia chave (SAK) da Security Association.

• Chave de criptografia de tráfego (TEK)— Usada para proteger o plano de dados. TEK é o nome da chave usada pelos membros do grupo para criptografar ou descriptografar a comunicação entre outros membros do grupo. Essa chave faz parte da chave de criptografia de transporte (SA TEK) da Security Association.

Como acontece com o IPsec padrão, todas as chaves têm uma vida útil e precisam ser reequipadas. As chaves distribuídas por GDOI são chaves de grupo e são usadas por todo o grupo.

Os SAs do grupo e o gerenciamento-chave são tratados por dois tipos de trocas de GDOI:

• groupkey-pull— Essa troca permite que um membro solicite SAs e chaves compartilhadas pelo grupo do servidor.

  No método pull, o membro do grupo solicita a SA do grupo e a política do servidor-chave. Esta solicitação está protegida pelo IKE SA.

  A groupkey-pull primeira troca no protocolo GDOI é usada para o registro de membros do grupo no GC/KS. O membro do grupo especifica o grupo com o qual deseja se registrar, e o GC/KS envia todas as SAs do grupo e chaves necessárias ao membro do grupo se o membro estiver autorizado a participar do grupo. A troca completa é protegida por um SA da Fase 1 (IKEv1 SA), que é estabelecido com o IKEv1 antes da groupkey-pull troca começar. Ela groupkey-pull faz parte da Fase 2 do protocolo GDOI.

• groupkey-push— Essa troca é uma mensagem re-chave única que permite que o servidor envie SAs e chaves de grupo para os membros antes que os SAs do grupo existente expirem. Mensagens rekey são mensagens não solicitadas enviadas do servidor aos membros.

  A groupkey-push segunda troca no protocolo GDOI é iniciada pelo GC/KS a todos os membros registrados do grupo. A Tabela 2 mostra os payloads que o membro do grupo da Série MX espera receber em groupkey-push mensagens.

  Tabela 2: payloads de mensagens com chave de grupo

  Carga	Descrição
  política associada ao grupo (GAP)	Uma carga de pagamento GAP permite a distribuição de políticas em todo o grupo, como instruções sobre quando ativar e desativar SAs. Esta carga de pagamento contém valores para atraso de tempo de ativação (ATD) e atraso de tempo de desativação (DTD) para a chave de criptografia de tráfego (TEK), bem como tipo de janela e tamanho da janela do protocolo de detecção de atraso de entrega de IP para o tráfego IPsec.
  Chave de criptografia de transporte da Security Association (SA TEK)	Seletores de tráfego.
  Chave de criptografia de chave da Associação de Segurança (SAK) (opcional)	A associação de segurança (SA) para a chave de criptografia chave (KEK). Também conhecida como SA KEK. Nota: groupkey-push mensagens que não incluem as cargas opcionais ainda são mensagens válidas.
  chave de criptografia de tráfego (TEK) (Opcional)	Chave para criptografar o tráfego de dados entre membros do grupo.
  chave de criptografia (KEK) (Opcional)	Usado para proteger o TEK.

  A groupkey-push troca é protegida por um SA KEK (SAK), que é instalado durante a groupkey-pull troca. Ela groupkey-push faz parte da Fase 2 do protocolo GDOI.

Em alguns casos, o GC/KS pode querer receber mensagens de reconhecimento de push chave do grupo dos membros do grupo. As mensagens de reconhecimento push dos membros do grupo confirmam que o membro recebeu a mensagem e tomou medidas sobre sua política. O GC/KS também pode usar o reconhecimento para determinar quais membros do grupo estão recebendo a política do grupo atual e quais membros do grupo não estão mais participando do grupo. A partir do Junos OS 19.2R1, o Junos OS envia uma mensagem de reconhecimento com o checksum SHA-256 quando recebe uma mensagem push groupkey com um valor de KEK_ACK_REQUESTED padrão de 9 no payload SA KEK conforme definido no RFC 8263 ou um valor KEK_ACK_REQUESTED de 129 que é usado são servidores-chave mais antigos.

Protocolo GDOI e VPNv2 de grupo

VPNv2 do grupo é o nome da tecnologia de segurança implementada nos roteadores MX5, MX10, MX40, MX240, MX480, MX960 da Juniper Networks. O Grupo VPNv2 usa o protocolo GDOI (RFC 6407) como base, além de outras funcionalidades.

A tecnologia VPNv2 do grupo é baseada no protocolo GDOI para lidar com as funcionalidades mais importantes. Este protocolo é especificado no RFC 6407 e define um Domínio de Interpretação (DOI) ISAKMP para gerenciar SAs de grupo e chaves para um grupo de participantes de segurança. Assim, todos os membros do grupo compartilham informações idênticas para criptografar e descriptografar o tráfego entre si. A criação, gerenciamento e distribuição de SAs de grupo e chaves de grupo são centralizadas e executadas pelo GC/KS. A Figura 2 fornece uma breve visão geral da funcionalidade do Grupo VPNv2 usando GDOI.

Figura 2: Grupo VPNv2 usando GDOI

Os membros do grupo usam o protocolo encapsulamento security payload (ESP) em modo de túnel para proteger o tráfego. No entanto, no Grupo VPN, o modo túnel é modificado. Como não há associação direta entre os membros do grupo, não é necessário usar endereços IP especiais no cabeçalho IP externo (ou seja, endereços IP de gateways IPsec). Todos os membros do grupo podem descriptografar o tráfego de todos os outros membros do grupo. Assim, o IP-Header interno é copiado para o IP-Header externo, e a infraestrutura de roteamento subjacente e a infraestrutura de QoS podem ser usadas. Esse recurso se chama Preservação de Cabeçalho e é mostrado na Figura 3.

Figura 3: Preservação do cabeçalho

Para obter SAs do grupo e chaves de grupo, o membro do grupo deve se inscrever no GC/KS para um grupo específico. O resultado é um IKEv1 SA, que só é necessário para garantir o processo de registro. Após o registro, o membro do grupo tem todas as informações para se comunicar com os outros membros do grupo (SA TEK), bem como as informações para descriptografar com sucesso as mensagens de rekeying (SAK). O GC/KS envia mensagens de rekeying antes que a vida útil do SA TEK ou do SAK expira. Também é possível enviar uma atualização SA TEK, bem como uma atualização de SAK na mesma mensagem rekey. O IKEv1 SA não é mais necessário e é excluído após a expiração da vida útil (sem reequipamento IKEv1).

Tráfego VPNv2 do grupo

O tráfego VPNv2 do grupo inclui:

• Tráfego de plano de controle — tráfego dos membros do grupo para o GC/KS na implantação do VPNv2 do grupo apenas com o protocolo GDOI.

• Tráfego de plano de dados — Tráfego entre os membros do grupo na implantação do Grupo VPNv2 com o protocolo ESP apenas que já é conhecido do IPsec.

Associação de segurança de grupos

Ao contrário das soluções de criptografia IPsec tradicionais, o Grupo VPN usa o conceito de associação de segurança de grupo. Uma SA em grupo é semelhante a uma SA em termos de funcionalidade. As SAs do grupo são compartilhadas entre todos os membros do grupo de um grupo de GDOI comum. Todos os membros do grupo VPN do grupo podem se comunicar entre si usando uma política de criptografia comum e uma SA de grupo compartilhado. Com uma política de criptografia comum e uma SA de grupo compartilhado, não há necessidade de negociar IPsec entre os membros do grupo. Isso reduz a carga de recursos dos membros do grupo. Os problemas de escalabilidade IPsec tradicionais (número de túneis e SAs associados) não se aplicam aos membros do grupo VPN do grupo.

Controlador de grupo/servidor-chave

Um controlador de grupo ou servidor-chave (GC/KS) é um dispositivo usado para criar e manter o plano de controle VPNv2 do grupo. Ela é responsável pela criação e distribuição de SAs de grupo e chaves de grupo. Todas as informações de que os membros do grupo precisam para se comunicar com outros membros do grupo são fornecidas pelo GC/KS. Todas as políticas de criptografia, como tráfego interessante, protocolos de criptografia, associação de segurança, temporizadors rekey e assim por diante, são definidas centralmente no GC/KS e são empurrados para todos os membros do grupo no momento do registro. Os membros do grupo autenticam com o GC/KS usando a Fase 1 do IKE e depois baixam as políticas de criptografia e as chaves necessárias para a operação de VPN em grupo. O GC/KS também é responsável por renovar e distribuir as chaves.

Membro do grupo

Um membro do grupo é um dispositivo de endpoint IPsec usado para o processo de criptografia de tráfego e é responsável pela criptografia e descriptografia reais do tráfego de dados. Um membro do grupo está configurado com parâmetros da Fase 1 do IKE e informações de GC/KS. As políticas de criptografia são definidas centralmente no GC/KS e baixadas para o membro do grupo no momento do registro bem-sucedido. Cada membro do grupo determina se o tráfego de entrada e saída deve ser descriptografado ou criptografado (usando sua SA) com base em sua participação em grupo.

Do ponto de vista da funcionalidade, um membro do grupo é semelhante a um gateway IPsec. No entanto, os SAs no IPsec normal existem entre dois gateways IPsec. No GDOI, o membro do grupo se registra no GC/KS para participar da VPN do grupo. Durante a inscrição, o membro do grupo fornece o ID do grupo ao GC/KS para obter as respectivas políticas, SAs e chaves necessárias para esse grupo. A relquisão é realizada pelos membros do grupo por meio do groupkey-pull método (recadastramento) ou pelo GC/KS por meio do groupkey-push método.

Proteção anti-replay para tráfego VPNv2 em grupo

Como a comunicação vpn em grupo é essencialmente uma comunicação qualquer sobre a mesma associação de segurança compartilhada, o uso de números de sequência para proteção anti-replay não funciona. Por causa disso, o Junos OS oferece suporte a uma especificação de rascunho do IETF para um mecanismo anti-replay baseado em tempo, draft-weis-delay-detection-01. Ele está disponível em http://tools.ietf.org/html/draft-weis-delay-detection-01 .

Para implementar esse recurso, os roteadores membros da Série MX fazem uso de um novo cabeçalho de selo de atraso de entrega de IP dentro do pacote. Consulte a implementação do protocolo de detecção de atraso de entrega de IP (proteção anti-replay baseada em tempo) para obter detalhes.

Falha parcial aberta nos roteadores membros da Série MX

Os membros do grupo em uma VPN de grupo contam com o GC/KS para gerar material de chave para a SA compartilhada. Portanto, a conectividade entre os membros do grupo e os GC/KSs é necessária para proteger inicialmente o tráfego e proteger continuamente o tráfego em eventos reais. No caso de falha de comunicação entre o membro do grupo e o GC/KS, o comportamento padrão dos membros do grupo é parar de encaminhar o tráfego. Isso é conhecido como fail-closed.

Uma opção de configuração sem desdestabilizado está disponível para permitir que algum tráfego definido especificamente flua pelo membro do grupo sem ser criptografado até que o membro seja capaz de entrar em contato com o GC/KS e recuperar a SA ativa. Isso é conhecido como fail-open parcial.

O recurso parcial aberto por falhas requer uma opção de configuração de política que cria uma regra sobre o membro do grupo da Série MX aplicável para um VPNv2 de grupo específico definido por endereços de origem e destino. Essa regra de fail-open só está ativa quando a SA do grupo está em estado de desabilitado por causa de uma falha de conectividade com o servidor-chave. O tráfego que normalmente passaria pela VPN do grupo, mas não corresponde à regra de fail-open, é descartado. Mais de uma regra de fail-open pode ser definida para o objeto VPN do grupo. Se não houver configuração de regras abertas contra falhas, o recurso aberto contra falhas será desativado.

Habilitação do Grupo VPNv2

Um conjunto de serviços é usado para habilitar o Grupo VPNv2 em uma interface específica em roteadores da Série MX aplicáveis.

[edit services]
service-set service-set-name {
    interface-service {
        service-interface service-interface-name;
    }
}
ipsec-group-vpn vpn-name;

[edit interfaces]
interface-name {
    unit 0 {
        family inet {
            service {
                input {
                    service-set service-set-name;
                }
                output {
                    service-set service-set-name;
                }
            }
            address 10.0.30.2/30;
        }
    }
}

Registrar um membro do grupo

O registro do membro do grupo no servidor começa quando a ipsec-group-vpn declaração está configurada para um conjunto de serviços e a interface de serviço está ativa. Quando a interface de serviço cai, todos os SAs de grupo associados a essa interface são liberados, e nenhum registro é acionado para essas VPNs do grupo até que a interface seja ativada.

O registro de membros do grupo envolve estabelecer a IKE SA com o GC/KS seguido de uma groupkey-pull troca para baixar as SAs e as chaves de tráfego para o identificador de grupo especificado.

Rekeying a um membro do grupo (método groupkey-push)

O GC/KS enviará uma mensagem unicast groupkey-push aos membros do grupo registrado para:

• Envie novas chaves de criptografia (KEKs) ou chaves de criptografia de tráfego (TEKs).

  As mensagens push podem conter todos ou apenas alguns dos elementos de carga mostrados na Tabela 2. Quando a carga de pagamento GAP contém SAs antigos e novos SAs de substituição, o roteador membro do grupo aplicará os valores ATD e DTD como uma releição normal por meio de push. Se não houver valor ATD na atualização, o roteador membro instala os novos SAs imediatamente. Se não houver valor de DTD, os SAs antigos permanecerão em vigor até a expiração.

• Atualize a política associada ao grupo (GAP) para uma SA existente.

  Um GC/KS pode enviar uma mensagem de push unicast para atualizar a configuração aos membros do grupo a qualquer momento. O payload GAP pode incluir alterações de configuração no protocolo de detecção de atrasos de entrega de IP, algoritmo de criptografia, vida útil e assim por diante. A configuração atualizada é aplicada imediatamente ou com um atraso. Os valores de ATD e DTD são usados para alcançar o tempo de ativação da nova TEK e exclusão da TEK existente, respectivamente. Se a vida útil da TEK existente tiver que ser reduzida, o valor do DTD será definido de acordo com a mensagem push. O novo TEK na mensagem push é ativado com base no valor atd na carga útil.

• Envie notificações de exclusão para TEK ou KEK.

  O GC/KS pode enviar o payload de notificação de exclusão opcional na mensagem push para excluir chaves e SAs no membro. A mensagem push contém o ID de protocolo que indica se a notificação de exclusão é para TEK ou KEK. O roteador membro do grupo exclui a chave com base no valor de ID e SPI do grupo contido na carga útil. A exclusão de um TEK ou KEK específico pode ser feita com um valor de atraso especificado no atributo DTD. Se o valor de atraso for 0, e a carga contém um SPI específico, então a TEK ou KEK correspondentes são excluídas imediatamente. Se todos os TEKs ou KEKs (ou ambos) precisarem ser excluídos no grupo, o valor de SPI será definido em 0 para o ID de protocolo correspondente na carga útil.

• Remova um roteador membro da VPN do grupo no Grupo VPNv2.

  As mensagens push são usadas para permitir que o GC/KS exclua membros da VPN do grupo. Em um caso, o GC/KS envia uma mensagem re-chave com apenas os SAs antigos e um valor DTD menor. O roteador membro do grupo instala o novo valor DTD menor. Como não recebeu novas chaves SA, o roteador membro tenta se registrar novamente usando o groupkey-pull método. Essa tentativa de recadastramento é rejeitada pelo GC/KS, excluindo assim o membro da VPN do grupo. No segundo caso, o GC/KS envia uma carga de pagamento de exclusão para o SPI da SA antiga. O roteador membro do grupo exclui a SA imediatamente e tenta se registrar novamente usando o groupkey-pull método. Essa tentativa de recadastramento é rejeitada pelo GC/KS, excluindo assim o membro da VPN do grupo.

Os membros do grupo da Série MX registrados enviam uma mensagem PUSH ACK unicast de volta ao GC/KS para reconhecer o recebimento da mensagem push original.

Rekeying a Group Member (groupkey-pull Method)

Para reexistência de membros do grupo, usando o groupkey-pull método, os membros do grupo normalmente se registram novamente no GC/KS quando há entre 7% e 5% restantes na vida útil macia existente de TEK ou KEK. Se a SA IKE existente estiver disponível, ela será usada na mensagem de atração. Após a resposta do GC/KS com uma nova chave, tanto a chave antiga quanto a nova chave podem ser usadas para descriptografia. No entanto, a nova chave não é usada para criptografia até que 30 segundos de vida útil da chave antiga permaneça. Se o IKE SA existente não estiver disponível, a mensagem de atração resulta em novas negociações de IKE entre o membro do grupo e o GC/KS.

Ao receber a mensagem de atração sobre uma VPN de grupo específica do membro do grupo, o GC/KS responde com todos os TEKs e o KEK para esse grupo.

Se alguma SA existente não for incluída na resposta do GC/KS, os SAs ausentes serão excluídos pelo membro do grupo.

Como exemplo, o GC/KS está configurado com uma vida útil de 3600 segundos e está conectado a um membro do grupo sem retransmitir. Com base na configuração do servidor, o GC/KS gera uma nova chave quando 10% da vida útil permanece. O membro do grupo, no entanto, recadastra-se no GC/KS quando 5% a 7% da vida útil permanece.

A Figura 4 representa o processo de reexame entre o GC/KS e o membro do grupo.

Figura 4: Reexequição de membros do grupo

Autenticando um membro do grupo

O Junos OS não oferece suporte de infraestrutura de chave pública (PKI) para VPN de grupo no Grupo VPNv2. Como resultado, chaves pré-compartilhadas são usadas para autenticação de membros do grupo.

Fragmentando o tráfego VPNv2 do grupo

Devido à funcionalidade de preservação do cabeçalho e ao uso da infraestrutura de roteamento subjacente, é necessário fragmentar os pacotes antes que a criptografia ocorra (se não puder ser evitada).

Assim, a pré-fragmentação é suportada e é recomendada para todas as implantações.

Para evitar a pós-fragmentação, defina a cleare copy setas opções para o bit DF na configuração do Grupo VPNv2.

Com base nesta configuração da bandeira, o cabeçalho IPsec tem o df-bit conjunto de clear, setou copy do pacote interno.

[edit]
security {
    group-vpn {
        member {
            ipsec {
                vpn group-vpn-name {
                    df-bit clear;
                }
            }
        }
    }
}

Criptografia do tráfego VPNv2 do grupo

Os membros do grupo criptografam o tráfego com base nos SAs do grupo e nas chaves fornecidas pelo GC/KS. O caminho de criptografia VPNv2 do grupo é o seguinte:

1. O pacote recebido pelo Mecanismo de Encaminhamento de Pacotes é verificado em uma correspondência de fluxo. Se uma correspondência for encontrada, o pacote será processado e transmitido.

2. Se uma correspondência não for encontrada, uma pesquisa de regras é realizada. Se uma correspondência for encontrada, um fluxo é criado e o pacote será processado e transmitido.

3. Se a busca da regra falhar, o pacote será descartado.

Descriptografando o tráfego VPNv2 do grupo

Após o sucesso do registro e a instalação de SAs de VPN em grupo, uma sessão esp é criada. O grupo VPNv2 cria a sessão ESP com um IP de origem e destino zero. Como a sessão ESP já está criada na instalação de SA, espera-se que os pacotes correspondam à sessão ESP existente.

O caminho de descriptografia do Grupo VPNv2 é o seguinte:

1. O pacote recebido pelo Mecanismo de Encaminhamento de Pacotes passa por uma verificação de fragmentação. Se o pacote for fragmentado, ele será montado para processamento adicional.

2. Após a montagem de pacotes ou se o pacote não for fragmentado, um IP de origem zero e destino é usado na busca de fluxo de descriptografado de 5 tuples. Se uma correspondência for encontrada, o pacote será processado e transmitido.

3. Se a busca do fluxo de descriptografado falhar, o pacote será verificado em um fluxo SPI sem ip de origem e destino.

4. Se a busca do fluxo SPI falhar, o pacote será descartado.

5. Se uma correspondência de fluxo SPI for encontrada, um fluxo de descriptografado é criado para evitar a busca do fluxo DE SPI para os pacotes subsequentes.

Configurando uma instância de roteamento para o Grupo VPNv2

As instâncias de roteamento são suportadas para controle e tráfego de dados. Para permitir que o suporte a instâncias de roteamento no tráfego de plano de controle para um membro do grupo chegue ao GC/KS em uma determinada instância de roteamento VRF, adicione a routing-instance declaração no nível de [edit security group-vpn member ike gateway gateway-name local-address address] hierarquia.

Nenhuma CLI adicional é necessária para dar suporte a uma instância de roteamento para pacotes de plano de dados, pois ela é determinada com base na interface de mídia na qual o conjunto de serviços é aplicado.

Estabelecendo vários grupos, políticas e SAs

O Junos OS oferece suporte para uma VPN de grupo por conjunto de serviços no Grupo VPNv2. No entanto, vários conjuntos de serviços podem ser criados para dar suporte a vários grupos em uma instância de roteamento. Vários SAs podem ser configurados por grupo. No entanto, várias políticas para a mesma chave de tráfego/SPI não são suportadas. Se o servidor enviar duas políticas para o mesmo TEK, então elas devem ser emparelhadas para serem aceitas, por exemplo, A-B e B-A, onde A e B são endereços IP ou sub-redes. Se várias políticas não pagas para um determinado TEK forem recebidas, o registro falhará e uma mensagem de log do sistema for gerada.

Conectando-se com vários GC/KSs cooperativos

Para um membro do grupo trabalhar com um GC/KS no modo cooperativo, a configuração é estendida para permitir um máximo de quatro servidores na lista de servidores.

Durante a reformulação ao usar o groupkey-pull método, o membro do grupo tenta se conectar ao GC/KS. Quando a conexão com o GC/KS falha, o membro do grupo tenta se reconectar ao GC/KS. Após três tentativas com um intervalo de 10 segundos, se a conexão com o GC/KS não for restaurada, o membro do grupo tenta estabelecer uma conexão com o próximo servidor disponível na lista de servidores. Esse processo é repetido até que o membro do grupo se conecte a um GC/KS. Durante esse período, as SAs de GDOI não inexpiradas nos membros do grupo não são limpas, de modo que o tráfego de VPN do grupo não seja afetado. A lacuna de tempo entre o rekeying e o expiração dura da vida útil oferece tempo suficiente para que os membros do grupo se conectem ao próximo servidor disponível, nesses casos.

Implementação do protocolo de detecção de atraso de entrega de IP (proteção anti-replay baseada em tempo)

Não há nenhuma configuração necessária para implementar o protocolo de detecção de atrasos de entrega de IP. Os membros do grupo da Série MX têm o tamanho da janela de repetição para usar como parte da carga de pagamento GAP no push ou na retirada de mensagens do servidor-chave. Se o tamanho da janela recebida for 0, a proteção anti-replay baseada em tempo será desativada.

Se o protocolo de detecção de atrasos de entrega de IP for ativado, o remetente adiciona seu tempotamp atual e criptografa o pacote. O receptor descriptografa o pacote e compara seu tempo atual com o tempo no pacote. Os pacotes que ficam fora do tamanho da janela são descartados. Por causa disso, todos os membros do grupo devem ter seus relógios sincronizados usando o Protocolo de Tempo de Rede (NTP).

Os tempos de protocolo de detecção de atraso de entrega de IP são medidos em segundos. Consulte o protocolo de detecção de atraso de entrega de IP Para obter mais informações, consulte o protocolo de detecção de atrasos de IP-draft-weis-delay-detection-01 .

Mudança na configuração do VPNv2 do grupo

A maioria das mudanças de configuração do Grupo VPNv2 resulta na exclusão de SAs existentes e recadastramento. Isso aciona o download da fase 1 e da SA com novas chaves de tráfego.

Ignorando a configuração do Grupo VPNv2

Se determinado tráfego como um protocolo de roteamento precisar contornar uma VPN de grupo no Grupo VPNv2, um filtro de serviço precisa ser configurado na interface em que o conjunto de serviços é aplicado. Os pacotes correspondentes ao filtro de serviço não chegam ao PIC para processamento de serviços e são encaminhados diretamente ao Mecanismo de Roteamento.

[edit interfaces]
interface-name {
    unit 0 {
        family inet {
            service {
                input {
                    service-set service-set-name service-filter filter-name;
                }
                output {
                    service-set service-set-name service-filter filter-name;
                }
            }
        }
    }
}

Implementação de falha parcial aberta em roteadores membros da Série MX

Por padrão, os pacotes são descartados se um roteador membro do grupo não conseguir obter SAs do GC/KS devido à perda de conectividade. Se você quiser permitir que algum tráfego passe sem criptografia no caso de uma falha de comunicação entre o membro do grupo e o GC/KS, você deve configurar uma fail-open regra no nível [edit security group-vpn member ipsec vpn vpn-name] de hierarquia.

As regras de falha aberta serão aplicadas ao tráfego apenas em caso de perda de conectividade de servidor. As regras de fail-open serão desativadas assim que a conectividade for restaurada e as chaves forem recebidas do GC/KS.

[edit security group-vpn member ipsec vpn vpn-name]
fail-open {
    rule rule-name{
        source-address source-ip-address
            destination-address destination-ip-address}
        }
    }

Um máximo de 10 regras de fail-open pode ser configurada para qualquer grupo.

Parâmetros IPsec de GDOI suportados

Cada grupo de GDOI tem um ID único. Ela é usada como uma base comum entre GC/KS e o membro do grupo para se comunicar sobre SAs de grupo e chaves de grupo.

Durante o processo de registro, o GC/KS envia chaves de criptografia de transporte (SA TEKs) para os membros do grupo. Todos os parâmetros relativos a toda a política de segurança do grupo estão configurados no GC/KS. O SA TEK é usado pelos membros do grupo para proteger o tráfego trocado entre si. A Tabela 3 mostra os parâmetros do SA TEK.

Além dos algoritmos criptográficos, o tráfego, que deve ser criptografado pelos membros do grupo, faz parte da política SA TEK (seletor de tráfego).

As declarações a seguir podem ser usadas em um membro do grupo Juniper Networks. Assim, os endereços precisam ser especificados no nível de hierarquia do IKE. A enumeração também é priorizada. Assim, na configuração do exemplo a seguir, o KS1 é contatado antes do KS2.

[edit security]
group-vpn {
    member {
        ike {
            gateway gateway-name {
                ike-policy policy-name;
                server-address <IP_KS1> <IP_KS2> <IP_KS3> <IP_KS4>;
                local-address <IP_GM> routing-instance routing-instance-name;
            }
        }
        ipsec {
            vpn vpn-group-name {
                ike-gateway gateway-name;
                fail-open {
                    rule rule-name {
                    source-address 198.51.100.1/24 
                    destination-address 192.0.2.1/24 
                    }
                }
                group group-ID;
                match-direction output;
            }
        }
    }
}

Parâmetros de GDOI IKEv1 suportados

Os padrões IKEv1 mencionados acima estão configurados da seguinte forma:

Aplicando políticas dinâmicas

A e output as input opções previstas na ipsec-group-vpn declaração especificam se as políticas dinâmicas recebidas do servidor são usadas quando a interface em que o conjunto de serviços é aplicado é a interface de entrada ou saída. Isso oferece flexibilidade para especificar regras diferentes nas direções de entrada e saída.

Suporte a TOS e DSCP

Os bits de tipo de serviço (TOS) e DiffServ Code Points (DSCP) são copiados do pacote interno para o pacote ESP.

Interoperabilidade dos membros do grupo

A implementação do GDOI pela Cisco se chama VPN de transporte de criptografia em grupo (GET). Embora o Grupo VPNv2 no Junos OS e a VPN GET da Cisco sejam ambos baseados no RFC 6407, o domínio de interpretação do grupo, existem algumas diferenças de implementação que você precisa estar ciente ao implantar o GDOI em um ambiente de rede que inclui dispositivos de segurança e roteamento da Juniper Networks e roteadores Cisco. Para obter mais informações, consulte as notas de versão atuais do Junos OS.

A interoperabilidade do grupo VPNv2 é a seguinte:

• O Junos OS oferece suporte de interoperabilidade com suporte cisco IOS GC/KS.

• O Junos OS não oferece suporte para a interoperabilidade do Grupo VPNv2 com o servidor VPN do Grupo SRX.

  Tabela 5: Interoperabilidade do Grupo VPNv2

  Membro do grupo	Membro do grupo SRX	Membro do MX Group VPNv2	Membro do Grupo Cisco	SRX GC	SRX KS	Cisco GC/KS
  Membro do MX Group VPNv2	Não	Sim	Sim	Não	Sim	Sim
  Membro do grupo SRX	Sim	Não	Não	Sim	Sim	Sim

O Junos OS não aceita a política de negação usada em um servidor Cisco GC/SK para adicionar uma exceção à política do grupo. Como uma solução alternativa, isso pode ser feito configurando regras de firewall em um membro do grupo da Série MX. Além disso, os membros do grupo Junos OS podem trabalhar com a política de negar por não falharem na negociação e simplesmente ignorarem o conteúdo. Isso permite que os administradores do sistema gerenciem facilmente redes onde os membros do grupo Cisco e os membros do grupo Junos OS coexistem.

Limitações do VPNv2 do grupo

O Junos OS Group VPNv2 não oferece suporte para o seguinte:

• Mensagens de push multicast

• Tráfego multicast

• GDOI SNMP MIBs

• Protocolo e porta nas políticas enviadas pelo servidor. O membro do grupo honra apenas o endereço/sub-rede IP especificado na política.

• Várias políticas não pagas para a mesma chave de tráfego/SPI

• Sobreposição de IP local e remoto em instâncias de roteamento em uma configuração de gateway IKE

• Políticas sobrepostas de VPNv2 de grupo que podem resultar em SAs incompatíveis

• IPv6 para controle e tráfego de dados

• Coexistência de IPsec e VPN em grupo no mesmo conjunto de serviços

• Coexistência de serviços como NAT e ALG no mesmo conjunto de serviços. NAT e VPN em grupo podem coexistir em diferentes conjuntos de serviços. No entanto, eles não podem coexistir no mesmo conjunto de serviços.

• VPN site a site (S2S) e VPN de ponto final dinâmico (DEP) podem coexistir com o Grupo VPN em diferentes conjuntos de serviços. No entanto, eles não podem coexistir no mesmo conjunto de serviços.

• Vários grupos no mesmo conjunto de serviços

• Suporte a membros do grupo com GC/KS da Série SRX

• Suporte a membros do grupo com membro do grupo SRX Series

• Hierarquia de chave lógica (LKH)

• Recomeço gracioso

• Alta disponibilidade

• ISSU unificado

• Suporte para PKI para autenticação