Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

VPNv1 do grupo

VPN em grupo é um conjunto de recursos que são necessários para proteger o tráfego de grupos multicast IP ou tráfego unicast em uma WAN privada que se origina ou flui através de um dispositivo.

Visão geral do grupo VPNv1

Uma associação de segurança IPsec (SA) é um acordo unidirecional entre participantes de redes privadas virtuais (VPN) que define as regras para uso para algoritmos de autenticação e criptografia, mecanismos de troca chave e comunicações seguras. Com as implementações de VPN atuais, o SA é um túnel ponto a ponto entre dois dispositivos de segurança. O Grupo VPNv1 estende a arquitetura IPsec para oferecer suporte a SAs que são compartilhadas por um grupo de dispositivos de segurança (ver Figura 1).

Figura 1: VPN IPsec padrão e VPNv1 em grupoVPN IPsec padrão e VPNv1 em grupo

O grupo VPNv1 tem suporte para dispositivos SRX100, SRX110, SRX210, SRX220, SRX240 e SRX650. Com o Grupo VPNv1, a conectividade entre todos é alcançada preservando os endereços IP de origem e destino originais no cabeçalho externo. Pacotes multicast seguros são replicados da mesma forma que pacotes cleartext multicast na rede principal.

Começando com o Junos OS Release 12.3X48-D30, os membros do Grupo VPNv1 podem interoperar com servidores VPNv2 do grupo.

O Grupo VPNv1 tem algumas limitações de propriedade em relação à RFC 6407, O Domínio de Interpretação do Grupo (GDOI). Para usar a VPN do grupo sem limitações próprias, atualize para o Grupo VPNv2. O VPNv2 do grupo tem suporte para instâncias vSRX, começando com o Junos OS Release 15.1X49-D30, dispositivos da Série SRX começando com o Junos OS Release 15.1X49-D40 e dispositivos da Série MX começando com o Junos OS Release 15.1r2.

Entendendo o protocolo GDOI para VPNv1 do grupo

O grupo VPNv1 é baseado na RFC 3547, O Domínio de Interpretação do Grupo (GDOI). Esta RFC descreve o protocolo entre membros do grupo e um servidor de grupo para estabelecer SAs entre os membros do grupo. As mensagens de GDOI criam, mantêm ou excluem SAs para um grupo de dispositivos. O protocolo GDOI é executado na porta 848.

A Internet Security Association e o Key Management Protocol (ISAKMP) definem duas fases de negociação para estabelecer SAs para um túnel IPsec autokey IKE. A fase 1 permite que dois dispositivos estabeleçam um SA ISAKMP. A Fase 2 estabelece SAs para outros protocolos de segurança, como o GDOI.

Com a VPN do grupo, a negociação de SA ISAKMP fase 1 é realizada entre um servidor de grupo e um membro do grupo. O servidor e o membro devem usar a mesma política ISAKMP. Na Fase 2, as trocas de GDOI entre o servidor e o membro estabelecem os SAs que são compartilhados com outros membros do grupo. Um membro do grupo não precisa negociar o IPsec com outros membros do grupo. As trocas de GDOI na Fase 2 devem ser protegidas pelos SAs de Fase 1 do ISAKMP.

Existem dois tipos de trocas de GDOI:

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

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

Entender as limitações do VPNv1 do grupo

Os seguintes não são compatíveis nesta versão para o grupo VPNv1:

  • Instâncias de roteamento não padrão

  • Cluster de chassi

  • Clusters de servidor

  • VPN de grupo baseado em rotas

  • Implantação pública baseada na Internet

  • SNMP

  • Negar política do servidor VPN Cisco GET

  • Interface J-Web para configuração e monitoramento

Começando pelo Junos OS Release 12.3X48-D30, membros do Grupo VPNv1 no SRX100, SRX110, SRX210, SRX220, SRX240, SRX550 e SRX650 podem interoperar com servidores do Grupo VPNv2. Ao configurar membros do Grupo VPNv1 para uso com servidores VPNv2 do grupo, observe as seguintes limitações:

  • O VPNv2 do grupo oferece suporte ao protocolo de detecção de atraso de entrega de IP de especificação do IETF para um mecanismo de antireplay baseado em tempo. Portanto, o antireplay baseado em protocolo de detecção de atraso de entrega de IP não tem suporte para membros do Grupo VPNv1 e deve ser desativado no servidor VPNv2 do grupo com o deactivate security group-vpn server group group-name anti-replay-time-window comando.

  • O servidor VPNv2 do grupo não oferece suporte à colocação, onde as funções do servidor de grupo e do membro do grupo existem no mesmo dispositivo.

  • O servidor VPNv2 do grupo não oferece suporte a transmissões de batimentos cardíacos. O batimento cardíaco deve ser desativado no membro do Grupo VPNv1 com o deactivate security group-vpn member ipsec vpn vpn-name heartbeat-threshold comando. Recomendamos o uso de clusters de servidor VPNv2 em grupo para evitar impactos no tráfego devido a reinicializações ou outras interrupções no servidor VPNv2 do grupo.

  • As mensagens de push em grupo enviadas do servidor VPNv2 do grupo são baseadas no RFC 6407, no domínio de interpretação do grupo (GDOI) e não têm suporte para membros do Grupo VPNv1. Portanto, as mensagens de push em grupo devem ser desabilitadas no servidor VPNv2 do grupo com o deactivate security group-vpn server group group-name server-member-communication comando.

    Os rekeys são suportados com mensagens de puxar chaves de grupo. Se houver problemas de escalabilidade em que os membros do Grupo VPNv1 não possam concluir a operação de retirada de chaves de grupo antes que a dura vida útil do TEK expira, recomendamos o aumento da vida útil do TEK para permitir que os membros completem a operação de retirada de chaves de grupo. Os números de escalabilidade da Juniper são qualificados com uma vida útil de 2 horas de TEK.

  • Se o servidor VPNv2 do grupo for reinicializado ou atualizado, ou os SAs do grupo forem liberados, novos membros não poderão ser adicionados à rede até que a próxima reexame ocorra para os membros existentes. Os novos membros não podem enviar tráfego para membros existentes que tenham chaves antigas. Como uma solução alternativa, libere os SAs sobre os membros existentes do Grupo VPNv1 com o clear security group-vpn member ipsec security-associations comando.

  • Como o tráfego de dados multicast não é suportado pelos membros do Grupo VPNv2, o tráfego de dados multicast não pode ser usado quando os membros do Grupo VPNv1 e VPNv2 coexistem na rede para o mesmo grupo.

Entendendo servidores e membros do VPNv1 do grupo

O centro de uma VPN em grupo é o servidor do grupo. O servidor do grupo executa as seguintes tarefas:

  • Controla a adesão ao grupo

  • Gera chaves de criptografia

  • Gerencia SAs e chaves de grupo e as distribui para membros do grupo

Os membros do grupo criptografam o tráfego com base nos SAs do grupo e nas chaves fornecidas pelo servidor do grupo.

Um servidor de grupo pode atender a vários grupos. Um único dispositivo de segurança pode ser um membro de vários grupos.

Cada grupo é representado por um identificador de grupo, número entre 1 e 65.535. O servidor do grupo e os membros do grupo são vinculados pelo identificador do grupo. Só pode haver um identificador de grupo por grupo, e vários grupos não podem usar o mesmo identificador de grupo.

A seguir, uma visão de alto nível das ações do servidor VPN do grupo e dos membros:

  1. O servidor do grupo escuta a porta UDP 848 para que os membros se inscrevam. Um dispositivo membro deve fornecer a autenticação correta da Fase 1 do IKE para participar do grupo. A autenticação de chave pré-compartilhada por membro é suportada.

  2. Após autenticação e registro bem-sucedidos, o dispositivo de membro recupera SAs e chaves do grupo do servidor com uma troca de GDOI groupkey-pull .

  3. O servidor adiciona o membro à adesão ao grupo.

  4. Os membros do grupo trocam pacotes criptografados com chaves SA do grupo.

O servidor envia periodicamente sa e atualizações de chave para membros do grupo com mensagens rekey (GDOI groupkey-push). As mensagens rekey são enviadas antes que os SAs expiram; isso garante que chaves válidas estejam disponíveis para criptografar o tráfego entre membros do grupo.

O servidor também envia mensagens rekey para fornecer novas chaves aos membros quando houver uma mudança na adesão ao grupo ou quando a SA do grupo tiver mudado.

Entender a comunicação entre membros do servidor VPNv1 do grupo

O grupo VPNv1 tem suporte para dispositivos SRX100, SRX110, SRX210, SRX220, SRX240 e SRX650. A comunicação entre membros do servidor permite que o servidor envie mensagens de GDOI groupkey-push aos membros. Se a comunicação entre membros do servidor não estiver configurada para o grupo, os membros podem enviar mensagens de GDOI groupkey-pull para registrar e recadastrar com o servidor, mas o servidor não é capaz de enviar mensagens rekey aos membros.

A comunicação entre membros do servidor é configurada para o grupo usando a server-member-communication declaração de configuração na [edit security group-vpn server] hierarquia. As seguintes opções podem ser definidas:

  • Algoritmo de criptografia usado para comunicações entre o servidor e o membro. Você pode especificar 3des-cbc, aes-128-cbc, aes-192-cbc, aes-256-cbc, ou des-cbc. Não há algoritmo padrão.

  • Algoritmo de autenticação (md5 ou sha1) usado para autenticar o membro no servidor. Não há algoritmo padrão.

  • Se o servidor envia mensagens de re-chave unicast ou multicast para membros do grupo e parâmetros relacionados ao tipo de comunicação.

  • Intervalo em que o servidor envia mensagens de batimentos cardíacos para o membro do grupo. Isso permite que o membro determine se o servidor foi reiniciado, o que exigiria que o membro reregissor com o servidor. O padrão é de 300 segundos.

  • Vida útil para a chave de criptografia chave (KEK). O padrão é de 3600 segundos.

A configuração da comunicação entre membros do servidor é necessária para que o servidor do grupo envie mensagens rekey aos membros, mas pode haver situações em que esse comportamento não seja desejado. Por exemplo, se os membros do grupo são colegas dinâmicos (como em um home office), os dispositivos nem sempre estão ativos e o endereço IP de um dispositivo pode ser diferente cada vez que ele é alimentado. Configurar a comunicação de membros do servidor para um grupo de pares dinâmicos pode resultar em transmissões desnecessárias pelo servidor. Se você quiser que a negociação de SA da Fase 1 da IKE seja sempre realizada para proteger a negociação do GDOI, não configure a comunicação entre membros do servidor.

Se a comunicação entre servidor e membro de um grupo não estiver configurada, a lista de membros exibida pelo comando mostra membros do show security group-vpn server registered-members grupo que se registraram no servidor; os membros podem estar ativos ou não. Quando a comunicação entre membros do servidor para um grupo é configurada, a lista de membros do grupo é liberada. Se o tipo de comunicação estiver configurado como unicast, o show security group-vpn server registered-members comando mostrará apenas membros ativos. Se o tipo de comunicação for configurado como multicast, o show security group-vpn server registered-members comando mostra membros que se registraram no servidor após a configuração; a lista de membros não representa necessariamente membros ativos porque os membros podem desistir após o registro.

Entender as operações-chave do grupo VPNv1

Este tópico contém as seguintes seções:

Chaves de grupo

O servidor do grupo mantém um banco de dados para acompanhar a relação entre grupos VPN, membros do grupo e chaves de grupo. Existem dois tipos de chaves de grupo que o servidor baixa para os membros:

  • Chave de criptografia (KEK)— Usada para criptografar mensagens rekey. Um KEK é compatível por grupo.

  • Chave de criptografia de tráfego (TEK)— usada para criptografar e descriptografar o tráfego de dados IPsec entre membros do grupo.

A chave associada a uma SA é aceita por um membro do grupo apenas se houver uma política de escopo correspondente configurada no membro. Uma chave aceita é instalada para a VPN do grupo, enquanto uma chave rejeitada é descartada.

Mensagens rekey

Se o grupo estiver configurado para comunicações de membros do servidor, o servidor envia periodicamente SA e atualizações de chave aos membros do grupo com mensagens rekey (GDOI groupkey-push). As mensagens rekey são enviadas antes que os SAs expiram; isso garante que chaves válidas estejam disponíveis para criptografar o tráfego entre membros do grupo.

O servidor também envia mensagens rekey para fornecer novas chaves aos membros quando há uma mudança na adesão ao grupo ou a SA do grupo mudou (por exemplo, uma política de grupo é adicionada ou excluída).

As opções de comunicação entre membros do servidor devem ser configuradas no servidor para permitir que o servidor envie mensagens rekey aos membros do grupo. Essas opções especificam o tipo de mensagem e os intervalos em que as mensagens são enviadas, conforme explicado nas seções a seguir:

Existem dois tipos de mensagens rekey:

  • Mensagens rekey unicast — o servidor do grupo envia uma cópia da mensagem rekey para cada membro do grupo. Após o recebimento da mensagem re-chave, os membros devem enviar um reconhecimento (ACK) ao servidor. Se o servidor não receber uma ACK de um membro (incluindo a retransmissão de mensagens rekey), o servidor considera o membro inativo e o remove da lista de membros. O servidor deixa de enviar mensagens prontas para o membro.

    As number-of-retransmission declarações de configuração para retransmission-period comunicações de membros do servidor controlam a reenconsão de mensagens re-chaves pelo servidor quando nenhuma ACK é recebida de um membro.

  • Mensagens rekey multicast — o servidor do grupo envia uma cópia da mensagem re-chave da interface de saída especificada para o endereço de grupo multicast configurado. Os membros não enviam reconhecimento do recebimento de mensagens rekey multicast. A lista de membros registrados não representa necessariamente membros ativos porque os membros podem desistir após o registro inicial. Todos os membros do grupo devem ser configurados para dar suporte a mensagens multicast.

    Protocolos multicast IP devem ser configurados para permitir a entrega de tráfego multicast na rede. Para obter informações detalhadas sobre a configuração de protocolos multicast em dispositivos da Juniper Networks, consulte o Guia de usuário do Multicast Protocols .

O intervalo em que o servidor envia mensagens rekey é calculado com base nos valores das lifetime-seconds declarações de configuração e activation-time-delay na hierarquia.edit security group-vpn server group O intervalo é calculado como lifetime-seconds minus 4*(activation-time-delay).

O lifetime-seconds kek está configurado como parte das comunicações de membros do servidor; o padrão é de 3600 segundos. O lifetime-seconds TEK está configurado para a proposta IPsec; o padrão é de 3600 segundos. Ele activation-time-delay está configurado para o grupo no servidor; o padrão é de 15 segundos. Usando os valores padrão para lifetime-seconds e activation-time-delay, o intervalo em que o servidor envia mensagens rekey é 3600 minus 4*15, ou 3540 segundos.

Registro de membros

Se um membro do grupo não receber uma nova chave SA do servidor antes da expiração da chave atual, o membro deve se recadastrar com o servidor e obter chaves atualizadas com uma troca de GDOI groupkey-pull . Nesse caso, o intervalo em que o servidor envia mensagens rekey é calculado da seguinte forma: lifetime-seconds menos 3*(activation-time-delay). Usando os valores padrão para lifetime-seconds e activation-time-delay, o intervalo em que o servidor envia mensagens rekey é 3600 menos 3*15, ou 3555 segundos.

O recadastramento dos membros pode ocorrer pelos seguintes motivos:

  • O membro detecta uma reinicialização de servidor pela ausência de batimentos cardíacos recebidos do servidor.

  • A mensagem re-chave do servidor do grupo está perdida ou atrasada, e a vida útil da TEK expirou.

Ativação chave

Quando um membro recebe uma nova chave do servidor, ele espera um período antes de usar a chave para criptografia. Esse período de tempo é determinado pela activation-time-delay declaração de configuração e se a chave é recebida por meio de uma mensagem re-chave enviada do servidor ou como resultado do recadastramento do membro com o servidor.

Se a chave for recebida por uma mensagem re-chave enviada do servidor, o membro espera 2*(activation-time-delay) segundos antes de usar a chave. Se a chave for recebida por meio do reregistramento de membros, o membro aguarda o número de segundos especificado pelo activation-time-delay valor.

Um membro retém as duas chaves mais recentes enviadas do servidor para cada SA de grupo instalada no membro. Ambas as chaves podem ser usadas para descriptografia, enquanto a chave mais recente é usada para criptografia. A chave anterior é removida o número de segundos especificado pelo activation-time-delay valor após a ativação da nova chave.

O padrão para a activation-time-delay declaração de configuração é de 15 segundos. Definir esse período de tempo muito pequeno pode resultar em um pacote sendo descartado em um membro remoto do grupo antes que a nova chave seja instalada. Considere a topologia da rede e os atrasos no transporte do sistema quando você altera o activation-time-delay valor. Para transmissões unicast, o atraso no transporte do sistema é proporcional ao número de membros do grupo.

Um servidor VPNv1 de grupo pode enviar várias chaves de criptografia de tráfego (TEKs) a um membro do grupo VPNv1 em resposta a uma solicitação groupkey-pull . O seguinte descreve como o membro do grupo VPNv1 lida com o TEK existente e os TEKs que recebe do servidor:

  • Se o membro do grupo VPNv1 receber dois ou mais TEKs, ele detém os dois TEKs mais recentes e elimina o TEK existente. Dos dois TEKs detidos, o TEK mais antigo é ativado imediatamente, e o TEK mais novo é ativado depois que o activation-time-delay configurado no servidor VPNv1 do grupo tiver decorrido (o padrão é de 15 segundos).

  • Se o membro do grupo VPNv1 receber apenas um TEK ou se receber um TEK por meio de uma groupkey-push mensagem do servidor, o TEK existente não será excluído até que a dura vida útil termine. A vida útil não é reduzida para o TEK existente.

O membro do grupo VPNv1 ainda instala um TEK recebido, mesmo que a vida útil do TEK seja menos de duas vezes o activation-time-delay valor.

Entender as mensagens de batimento cardíaco do VPNv1 do grupo

Quando a comunicação entre membros do servidor é configurada, o servidor VPNv1 do grupo envia mensagens de batimentos cardíacos aos membros em intervalos especificados (o intervalo padrão é de 300 segundos). O mecanismo de batimentos cardíacos permite que os membros se reregistram com o servidor se o número especificado de batimentos cardíacos não for recebido. Por exemplo, os membros não receberão mensagens de batimento cardíaco durante uma reinicialização de servidor. Quando o servidor é reiniciado, os membros reregistram com o servidor.

Os batimentos cardíacos são transmitidos por mensagens groupkey-push . O número de sequência é incrementado em cada mensagem de batimento cardíaco, que protege os membros contra ataques de resposta. Ao contrário das mensagens rekey, as mensagens de batimento cardíaco não são reconhecidas pelos destinatários e não são retransmitidas pelo servidor.

As mensagens de batimentos cardíacos contêm as seguintes informações:

  • Estado e configuração atuais das chaves no servidor

  • Tempo relativo, se o antireplay estiver ativado

Comparando as informações nos batimentos cardíacos, um membro pode detectar se perdeu informações do servidor ou rekey messages. O membro reregissores para sincronizar-se com o servidor.

Mensagens de batimentos cardíacos podem aumentar o congestionamento da rede e causar recadastramentos desnecessários de membros. Assim, a detecção de batimentos cardíacos pode ser desativada no membro, se necessário.

Entender o modo de colocação de membros do servidor VPNv1 do grupo

As funções de servidor de grupo e de grupo são separadas e não se sobrepõem. As funções de servidor e membro podem coexistir no mesmo dispositivo físico, que é chamado de modo de colocação. No modo de colocação, não há mudança em termos de funcionalidade e comportamento do servidor ou de um membro, mas o servidor e o membro precisam ser atribuídos diferentes endereços IP para que os pacotes possam ser entregues corretamente. No modo de colocação, só pode haver um endereço IP atribuído ao servidor e um endereço IP atribuído ao membro em todos os grupos.

Visão geral da configuração do grupo VPNv1

Este tópico descreve as principais tarefas para configurar o grupo VPNv1.

No servidor do grupo, configure o seguinte:

  1. Negociação da Fase 1 da IKE. Use a [edit security group-vpn server ike] hierarquia para configurar o IKE Phase 1 SA. Veja como entender a configuração da Fase 1 do IKE para o VPNv2 do grupo .
  2. FASE 2 IPsec SA. Veja a compreensão da configuração de SA IPsec para VPNv1 em grupo.
  3. Grupo VPN. Consulte a visão geral da configuração do Grupo VPNv1.

No membro do grupo, configure o seguinte:

  1. Negociação da Fase 1 da IKE. Use a [edit security group-vpn member ike] hierarquia para configurar o IKE Phase 1 SA. Veja como entender a configuração da Fase 1 do IKE para VPNv1 do grupo .

  2. FASE 2 IPsec SA. Veja a compreensão da configuração de SA IPsec para VPNv1 em grupo.

  3. Política de escopo que determina quais políticas de grupo estão instaladas no membro. Veja a compreensão das políticas dinâmicas para o VPNv1 do grupo.

Para evitar problemas de fragmentação de pacotes, recomendamos que a interface usada pelo membro do grupo para se conectar à rede MPLS seja configurada para um tamanho máximo de unidade de transmissão (MTU) não maior que 1400 bytes. Use a set interface mtu declaração de configuração para definir o tamanho do MTU.

O grupo vpn está configurado no servidor com a group declaração de configuração na [edit security group-vpn server] hierarquia.

As informações do grupo consistem nas seguintes informações:

  • Identificador de grupo — um valor entre 1 e 65.535 que identifica o grupo VPN. O mesmo identificador de grupo deve ser configurado no membro do grupo para Autokey IKE.

  • Membros do grupo, conforme configurado com a declaração de ike-gateway configuração. Pode haver várias instâncias desta declaração de configuração, uma para cada membro do grupo.

  • Endereço IP do servidor (o endereço da interface de loopback é recomendado).

  • Políticas de grupo — políticas que devem ser baixadas aos membros. As políticas de grupo descrevem o tráfego ao qual a SA e as chaves se aplicam. Veja a compreensão das políticas dinâmicas para o VPNv1 do grupo.

  • Comunicação entre membros do servidor — configuração opcional que permite que o servidor envie mensagens rekey aos membros. Veja a visão geral do grupo VPNv1.

  • Antireplay — configuração opcional que detecta interceptação e repetição de pacotes. Consulte o Understanding Antireplay para o Grupo VPNv1.

Entendendo a configuração da Fase 1 do IKE para o Grupo VPNv1

Uma SA IKE fase 1 entre o servidor do grupo e um membro do grupo estabelece um canal seguro para negociar SAs IPsec que são compartilhados por um grupo. Para VPNs IPsec padrão em dispositivos de segurança da Juniper Networks, a configuração de SA da Fase 1 consiste em especificar uma proposta de IKE, política e gateway. Para VPNv1 de grupo, a configuração SA da Fase 1 do IKE é semelhante à configuração para VPNs IPsec padrão, mas é realizada na hierarquia [edit security group-vpn].

Na configuração da proposta de IKE, você define o método de autenticação e os algoritmos de autenticação e criptografia que serão usados para abrir um canal seguro entre os participantes. Na configuração da política de IKE, você define o modo (principal ou agressivo) no qual o canal da Fase 1 será negociado, especifica o tipo de troca de chave a ser usada e faz referência à proposta de Fase 1. Na configuração do gateway IKE, você faz referência à política de Fase 1.

Como o Grupo VPNv2 só oferece suporte a algoritmos fortes, a opção sha-256 do algoritmo de autenticação é compatível com membros do Grupo VPNv1 nos dispositivos SRX100, SRX110, SRX210, SRX220, SRX240, SRX550 e SRX650. Quando os membros do Grupo VPNv1 interoperam com servidores VPNv2 do grupo, essa opção deve ser configurada nos membros do Grupo VPNv1 com o edit security group-vpn member ike proposal proposal-name authentication-algorithm sha-256 comando. No servidor VPNv2 do grupo, authentication-algorithm sha-256 deve ser configurado para propostas de IKE e authentication-algorithm hmac-sha-256-128 deve ser configurado para propostas IPsec.

Se um gateway IKE em um membro do Grupo VPNv1 estiver configurado com mais de um endereço de gateway, a mensagem de erro "Apenas um endereço remoto pode ser configurado por configuração de gateway IKE" é exibido quando a configuração é comprometida.

A configuração da Fase 1 do IKE no servidor de grupo deve corresponder à configuração da Fase 1 do IKE aos membros do grupo.

Entendendo a configuração do IPsec SA para o grupo VPNv1

Após o servidor e o membro terem estabelecido um canal seguro e autenticado na negociação da Fase 1, eles passam pela Fase 2. A negociação da fase 2 estabelece os SAs IPsec que são compartilhados pelos membros do grupo para proteger dados transmitidos entre os membros. Embora a configuração IPsec SA para VPN de grupo seja semelhante à configuração para VPNs padrão, um membro do grupo não precisa negociar a SA com outros membros do grupo.

A configuração IPsec da fase 2 para VPNv1 em grupo consiste nas seguintes informações:

  • Uma proposta para que o algoritmo de protocolo, autenticação e criptografia de segurança seja usado para o SA. A proposta do IPsec SA está configurada no servidor de grupo com a proposal declaração de configuração naedit security group-vpn server ipsec [] hierarquia.

  • Uma política de grupo que faz referência à proposta. Uma política de grupo especifica o tráfego (protocolo, endereço de origem, porta de origem, endereço de destino e porta de destino) ao qual a SA e as chaves se aplicam. A política de grupo está configurada no servidor com a declaração de ipsec-sa configuração na hierarquiaedit security group-vpn server group .

  • Um IKE autokey que faz referência ao identificador de grupo, ao servidor de grupo (configurado com a declaração de ike-gateway configuração) e à interface usada pelo membro para se conectar ao grupo. O IKE autokey está configurado no membro com a declaração de ipsec vpn configuração naedit security group-vpn member [] hierarquia.

Entendendo as políticas dinâmicas para o grupo VPNv1

O servidor do grupo distribui SAs de grupo e chaves para membros de um grupo especificado. Todos os membros que pertencem ao mesmo grupo podem compartilhar o mesmo conjunto de SAs IPsec. Mas nem todos os SAs configurados para um grupo são instalados em todos os membros do grupo. A SA instalada em um membro específico é determinada pela política associada à SA do grupo e pelas políticas de segurança configuradas no membro.

Em um grupo de VPN, cada SA de grupo e a chave que o servidor empurra para um membro está associada a uma política de grupo. A política do grupo descreve o tráfego no qual a chave deve ser usada, incluindo protocolo, endereço de origem, porta de origem, endereço de destino e porta de destino.

As políticas de grupo idênticas (configuradas com o mesmo endereço de origem, endereço de destino, porta de origem, porta de destino e valores de protocolo) não podem existir para um único grupo. Um erro é devolvido se você tentar cometer uma configuração que contenha políticas de grupo idênticas para um grupo. Se esse for o caso, você deve excluir uma das políticas de grupo idênticas.

Em um membro do grupo, uma política de escopo deve ser configurada que defina o escopo da política de grupo baixada do servidor. Uma política de grupo distribuída do servidor é comparada com as políticas de escopo configuradas no membro. Para que uma política de grupo seja instalada no membro, as seguintes condições devem ser atendidas:

  • Quaisquer endereços especificados na política de grupo devem estar dentro da faixa de endereços especificados na política de escopo.

  • A porta de origem, a porta de destino e o protocolo especificados na política de grupo devem corresponder aos configurados na política de escopo.

Uma política de grupo instalada em um membro é chamada de política dinâmica.

Uma política de escopo pode fazer parte de uma lista ordenada de políticas de segurança para um contexto específico de zona e zona. O Junos OS realiza uma busca por políticas de segurança nos pacotes recebidos a partir do topo da lista ordenada.

Dependendo da posição da política de escopo dentro da lista ordenada de políticas de segurança, existem várias possibilidades de busca dinâmica de políticas:

  • Se o pacote recebido corresponde a uma política de segurança antes que a política de escopo seja considerada, a busca dinâmica de políticas não ocorrerá.

  • Se uma política de entrada corresponder a uma política de escopo, o processo de pesquisa continua para uma política dinâmica correspondente. Se houver uma política dinâmica correspondente, essa ação de política (permissão) é executada. Se não houver uma política dinâmica correspondente, o processo de pesquisa continua a pesquisar as políticas abaixo da política de escopo.

    Nesta versão, apenas a ação tunnel é permitida para uma política de escopo. Outras ações não são apoiadas.

Você configura uma política de escopo em um membro do grupo usando a policies declaração de configuração na hierarquia.edit security Use a ipsec-group-vpn declaração de configuração na regra do túnel de permissão para fazer referência à VPN do grupo; isso permite que os membros do grupo compartilhem uma única SA.

Entendendo o antireplay para o grupo VPNv1

O antireplay é um recurso IPsec que pode detectar quando um pacote é interceptado e depois reproduzido por invasores. O antireplay é habilitado por padrão para VPNs de grupo, mas pode ser desativado para um grupo com a no-anti-replay declaração de configuração.

Quando o antireplay é ativado, o servidor de grupo sincroniza o tempo entre os membros do grupo. Cada pacote IPsec contém um ponto de tempo. O membro do grupo verifica se o tempo do pacote está dentro do valor configurado anti-replay-time-window (o padrão é de 100 segundos). Um pacote é descartado se o tempotamp exceder o valor.

Exemplo: Configuração do servidor e membros do VPNv1 do grupo

Este exemplo mostra como configurar o grupo VPNv1 para estender a arquitetura IPsec para oferecer suporte a SAs que são compartilhadas por um grupo de dispositivos de segurança. O grupo VPNv1 tem suporte para dispositivos SRX100, SRX110, SRX210, SRX220, SRX240 e SRX650.

Requisitos

Antes de começar:

Visão geral

Em Figura 2, uma VPN em grupo consiste em dois dispositivos membros (membro1 e membro2) e um servidor de grupo (o endereço IP da interface de loopback no servidor é 20.0.0.1). O identificador do grupo é 1.

Figura 2: Exemplo de configuração de membros do servidorExemplo de configuração de membros do servidor

Os SAs vpn do grupo Fase 2 devem ser protegidos por uma SA de Fase 1. Portanto, a configuração de VPN do grupo deve incluir a configuração das negociações da Fase 1 do IKE no servidor do grupo e nos membros do grupo. Além disso, o mesmo identificador de grupo deve ser configurado no servidor do grupo e nos membros do grupo.

As políticas de grupo estão configuradas no servidor do grupo. Todas as políticas de grupo configuradas para um grupo são baixadas para membros do grupo. As políticas de escopo configuradas em um membro do grupo determinam quais políticas de grupo estão realmente instaladas no membro. Neste exemplo, as seguintes políticas de grupo estão configuradas no servidor do grupo para download a todos os membros do grupo:

  • p1 — permite todo o tráfego de 10.1.0.0/16 a 10.2.0.0./16

  • p2 — Permite todo o tráfego de 10.2.0.0./16 a 10.1.0.0/16

  • p3 — permite tráfego multicast a partir de 10.1.1.1/32

O dispositivo member1 é configurado com políticas de escopo que permitem todo o tráfego unicast de e para a sub-rede 10.0.0.0/8. Não há uma política de escopo configurada no membro1 para permitir o tráfego multicast; portanto, a política de SA p3 não está instalada no membro1.

O dispositivo member2 é configurado com políticas de escopo que retiram o tráfego de 10.1.0.0/16 da zona de confiança para a zona de confiança não confiável e para 10.1.0.0/16 da zona não confiável para a zona de confiança. Portanto, a política de SA p2 não está instalada no membro2.

Configuração

Configuração do servidor de grupo

Configuração rápida de CLI

Para configurar este exemplo rapidamente, copie os seguintes comandos, cole-os em um arquivo de texto, remova quaisquer quebras de linha, altere todos os detalhes necessários para combinar com sua configuração de rede, copiar e colar os comandos no CLI no nível de [edit] hierarquia e, em seguida, entrar no commit modo de configuração.

Procedimento passo a passo

O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter instruções sobre como fazer isso, consulte o uso do Editor de CLI no modo de configuração.

Para configurar o servidor de grupo:

  1. Configure o endereço de loopback no dispositivo.

  2. Configure o IKE Phase 1 SA (essa configuração deve combinar com a SA da Fase 1 configurada nos membros do grupo).

  3. Defina a política de IKE e defina os gateways remotos.

  4. Configure a troca sa fase 2.

  5. Configure o identificador de grupo e o gateway IKE.

  6. Configure comunicações de servidor para membro.

  7. Configure as políticas de grupo a serem baixadas para membros do grupo.

Resultados

A partir do modo de configuração, confirme sua configuração entrando no show security group-vpn server comando. Se a saída não exibir a configuração pretendida, repita as instruções de configuração neste exemplo para corrigi-la.

Se terminar de configurar o dispositivo, entre no commit modo de configuração.

Configuração do Membro1

Configuração rápida de CLI

Para configurar este exemplo rapidamente, copie os seguintes comandos, cole-os em um arquivo de texto, remova quaisquer quebras de linha, altere todos os detalhes necessários para combinar com sua configuração de rede, copiar e colar os comandos no CLI no nível de [edit] hierarquia e, em seguida, entrar no commit modo de configuração.

Procedimento passo a passo

O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter instruções sobre como fazer isso, consulte o uso do Editor de CLI no modo de configuração.

Para configurar o membro1:

  1. Configure a Sa fase 1 (essa configuração deve combinar com a SA da Fase 1 configurada no servidor de grupo).

  2. Defina a política de IKE e defina os gateways remotos.

  3. Configure o identificador de grupo, o gateway IKE e a interface para o membro1.

    Para evitar problemas de fragmentação de pacotes, recomendamos que a interface usada pelos membros do grupo para se conectar à rede MPLS seja configurada para um tamanho de MTU não maior que 1400 bytes. Use a set interface mtu declaração de configuração para definir o tamanho do MTU.

  4. Crie livros de endereços e conecte zonas a eles.

  5. Configure uma política de escopo da zona de confiança até a zona não confiável que permite o tráfego unicast de e para a sub-rede 10.0.0.0/8.

  6. Configure uma política de escopo da zona não confiável para a zona de confiança que permite o tráfego unicast de e para a sub-rede 10.0.0/8.

Resultados

A partir do modo de configuração, confirme sua configuração entrando no e show security policies comandosshow security group-vpn member. Se a saída não exibir a configuração pretendida, repita as instruções de configuração neste exemplo para corrigi-la.

Se terminar de configurar o dispositivo, entre no commit modo de configuração.

Configuração do Membro2

Configuração rápida de CLI

Para configurar este exemplo rapidamente, copie os seguintes comandos, cole-os em um arquivo de texto, remova quaisquer quebras de linha, altere todos os detalhes necessários para combinar com sua configuração de rede, copiar e colar os comandos no CLI no nível de [edit] hierarquia e, em seguida, entrar no commit modo de configuração.

Procedimento passo a passo

O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter instruções sobre como fazer isso, consulte o uso do Editor de CLI no modo de configuração.

Para configurar o membro2:

  1. Configure a Sa fase 1 (essa configuração deve combinar com a SA da Fase 1 configurada no servidor de grupo).

  2. Defina a política de IKE e defina o gateway remoto.

  3. Configure o identificador de grupo, o gateway IKE e a interface para o membro2.

    Para evitar problemas de fragmentação de pacotes, recomendamos que a interface usada pelos membros do grupo para se conectar à rede MPLS seja configurada para um tamanho de MTU não maior que 1400 bytes. Use a set interface mtu declaração de configuração para definir o tamanho do MTU.

  4. Crie um livro de endereços e anexe-o à zona de confiança.

  5. Crie outro livro de endereços e anexe-o à zona não confiável.

  6. Configure uma política de escopo da zona de confiança até a zona não confiável que bloqueia o tráfego de 10.1.0.0/16.

  7. Configure uma política de escopo da zona não confiável até a zona de confiança que bloqueia o tráfego para 10.1.0.0/16.

Resultados

A partir do modo de configuração, confirme sua configuração entrando no e show security policies comandosshow security group-vpn member. Se a saída não exibir a configuração pretendida, repita as instruções de configuração neste exemplo para corrigi-la.

Se terminar de configurar o dispositivo, entre no commit modo de configuração.

Verificação

Para confirmar que a configuração está funcionando corretamente, execute esta tarefa:

Verificação de políticas dinâmicas para membro1

Propósito

Veja as políticas dinâmicas instaladas no member1.

Ação

Após o servidor do grupo baixar as chaves do membro1, entre no comando do show security dynamic-policies modo operacional.

Significado

A política multicast p3 do servidor não está instalada no membro1 porque não há uma política de escopo configurada no member1 que permita o tráfego multicast.

Verificação de políticas dinâmicas para membro2

Propósito

Veja as políticas dinâmicas instaladas no membro 2.

Ação

Após o servidor do grupo baixar as chaves do membro2, entre no comando do show security dynamic-policies modo operacional.

Significado

A política p2 (para tráfego de 10.1.0.0/16 a 10.2.0.0/16) do servidor não está instalada no membro2, porque corresponde à política de segurança deny2 configurada no membro2.

Exemplo: Configuração da comunicação de membros do servidor VPNv1 do grupo para mensagens rekey da Unicast

Este exemplo mostra como permitir que o servidor envie mensagens de rekey unicast aos membros do grupo para garantir que chaves válidas estejam disponíveis para criptografar o tráfego entre os membros do grupo. O grupo VPNv1 tem suporte para dispositivos SRX100, SRX110, SRX210, SRX220, SRX240 e SRX650.

Requisitos

Antes de começar:

  • Configure o servidor e os membros do grupo para a negociação da Fase 1 do IKE.

  • Configure o servidor de grupo e os membros para a Fase 2 IPsec SA.

  • Configure o grupo g1 no servidor do grupo.

Visão geral

Neste exemplo, você especifica os seguintes parâmetros de comunicação entre membros do servidor para grupo g1:

  • O servidor envia mensagens rekey unicast aos membros do grupo.

  • 3des-cbc é usado para criptografar o tráfego entre o servidor e os membros.

  • sha1 é usado para autenticação de membros.

Os valores padrão são usados para batimentos cardíacos de servidor, vida útil kek e retransmissões.

Configuração

Procedimento

Procedimento passo a passo

O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter instruções sobre como fazer isso, consulte o uso do Editor de CLI no modo de configuração.

Para configurar a comunicação entre membros do servidor:

  1. Defina o tipo de comunicação.

  2. Defina o algoritmo de criptografia.

  3. Defina a autenticação dos membros.

Verificação

Para verificar se a configuração está funcionando corretamente, entre no show security group-vpn server group g1 server-member-communication comando.

Exemplo: Configuração da comunicação de membros do servidor VPNv1 do grupo para mensagens rekey multicast

Este exemplo mostra como permitir que o servidor envie mensagens rekey multicast aos membros do grupo para garantir que chaves válidas estejam disponíveis para criptografar o tráfego entre membros do grupo. O grupo VPNv1 tem suporte para dispositivos SRX100, SRX110, SRX210, SRX220, SRX240 e SRX650.

Requisitos

Antes de começar:

Visão geral

Neste exemplo, você especifica a seguinte comunicação entre membros do servidor para grupo g1:

  • O servidor envia mensagens rekey multicast aos membros do grupo por meio do endereço multicast 226.1.1.1 e interface ge-0/0/1.0.

  • 3des-cbc é usado para criptografar o tráfego entre o servidor e os membros.

  • sha1 é usado para autenticação de membros.

Os valores padrão são usados para batimentos cardíacos de servidor, vida útil kek e retransmissões.

Configuração

Procedimento

Configuração rápida de CLI

Para configurar este exemplo rapidamente, copie os seguintes comandos, cole-os em um arquivo de texto, remova quaisquer quebras de linha, altere todos os detalhes necessários para combinar com sua configuração de rede, copiar e colar os comandos no CLI no nível de [edit] hierarquia e, em seguida, entrar no commit modo de configuração.

Procedimento passo a passo

O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter instruções sobre como fazer isso, consulte o uso do Editor de CLI no modo de configuração.

Configurar a configuração da comunicação entre membros do servidor para mensagens rekey multicast:

  1. Defina o tipo de comunicação.

  2. Defina o grupo multicast.

  3. Defina a interface para mensagens multicast de saída.

  4. Defina o algoritmo de criptografia.

  5. Defina a autenticação dos membros.

Resultados

A partir do modo de configuração, confirme sua configuração entrando no show security group-vpn server group g1 server-member-communication comando. Se a saída não exibir a configuração pretendida, repita as instruções de configuração neste exemplo para corrigi-la.

Se terminar de configurar o dispositivo, entre no commit modo de configuração.

Verificação

Para confirmar que a configuração está funcionando corretamente, execute essas tarefas:

Verificando a comunicação entre membros do servidor para mensagens rekey multicast

Propósito

Verifique se os parâmetros de comunicação entre membros do servidor para mensagens multicast são configurados corretamente para garantir que chaves válidas estejam disponíveis para criptografar o tráfego entre os membros do grupo.

Ação

A partir do modo operacional, entre no show security group-vpn server group g1 server-member-communication comando.

Exemplo: Configuração do grupo VPNv1 com colocação de membros do servidor

Este exemplo mostra como configurar um dispositivo para o modo de colocação, que permite que funções de servidor e membro coexistam no mesmo dispositivo físico. O grupo VPNv1 tem suporte para dispositivos SRX100, SRX110, SRX210, SRX220, SRX240 e SRX650.

Requisitos

Antes de começar:

Visão geral

Quando o modo de colocação é configurado, as funções de servidor de grupo e de grupo podem coexistir no mesmo dispositivo. No modo de colocação, o servidor e o membro devem ter endereços IP diferentes para que os pacotes sejam entregues corretamente.

Em Figura 3, uma VPN em grupo (identificador de grupo é 1) consiste em dois membros (membro1 e membro2) e um servidor de grupo (o endereço IP da interface de loopback é 20.0.0.1). Observe que o membro1 coexiste no mesmo dispositivo que o servidor de grupo. Neste exemplo, a interface que o membro1 usa para se conectar à rede MPLS (ge-0/1/0) é atribuída ao endereço IP 10.1.0.1/32.

Figura 3: Exemplo de colocação de membros do servidorExemplo de colocação de membros do servidor

As instruções de configuração neste tópico descrevem como configurar o dispositivo de servidor de grupo-membro1 para o modo de colocação. Para configurar o membro2, veja Exemplo: Configuração do servidor e membros do VPNv1 do grupo.

Para evitar problemas de fragmentação de pacotes, recomendamos que a interface usada pelo membro do grupo para se conectar à rede MPLS seja configurada para um tamanho de MTU não maior que 1400 bytes. Use a set interface mtu declaração de configuração para definir o tamanho do MTU.

Configuração

Procedimento

Configuração rápida de CLI

Para configurar este exemplo rapidamente, copie os seguintes comandos, cole-os em um arquivo de texto, remova quaisquer quebras de linha, altere todos os detalhes necessários para combinar com sua configuração de rede, copiar e colar os comandos no CLI no nível de [edit] hierarquia e, em seguida, entrar no commit modo de configuração.

Procedimento passo a passo

O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter instruções sobre como fazer isso, consulte o uso do Editor de CLI no modo de configuração.

Para configurar a VPN do grupo com a colocação de membros do servidor:

  1. Configure o endereço de loopback no dispositivo.

  2. Configure a interface que o membro1 usa para se conectar à rede MPLS.

  3. Configure a colocação de VPN em grupo no dispositivo.

  4. Configure o IKE Phase 1 SA para o servidor (essa configuração deve combinar com a SA da Fase 1 configurada em membros do grupo).

  5. Defina a política de IKE e defina os gateways remotos.

  6. Configure a troca sa fase 2 para o servidor.

  7. Configure o identificador de grupo, o gateway IKE, o tempo de antireplay e o endereço do servidor no servidor.

  8. Configure o servidor para as comunicações dos membros.

  9. Configure as políticas de grupo a serem baixadas para membros do grupo.

  10. Configure a Sa fase 1 para membro1 (essa configuração deve combinar com a SA da Fase 1 configurada para o servidor de grupo).

  11. Defina a política e defina o gateway remoto para membro1.

  12. Configure o identificador de grupo, o gateway IKE e a interface para o membro1.

  13. Crie livros de endereços e conecte-os a zonas.

  14. Configure uma política de escopo da zona de confiança até a zona não confiável que permite o tráfego unicast de e para a sub-rede 10.0.0.0/8.

  15. Configure uma política de escopo da zona não confiável para a zona de confiança que permite o tráfego unicast de e para a sub-rede 10.0.0/8.

Resultados

A partir do modo de configuração, confirme sua configuração entrando no e show security policies no show security group-vpn comando. Se a saída não exibir a configuração pretendida, repita as instruções de configuração neste exemplo para corrigi-la.

Na lista de políticas de segurança configuradas, certifique-se de que as políticas de escopo estejam listadas antes das políticas padrão.

Se terminar de configurar o dispositivo, entre no commit modo de configuração.

Verificação

Para confirmar que a configuração está funcionando corretamente, execute essas tarefas:

Verificação do registro de membros de VPN do grupo

Propósito

Verifique se os membros da VPN do grupo estão registrados corretamente.

Ação

A partir do modo operacional, entre no show security group-vpn registered-members comando.

Verificando as associações de segurança do servidor VPN do grupo para IKE

Propósito

Verifique os SAs do servidor VPN do grupo para IKE.

Ação

A partir do modo operacional, entre no show security group-vpn server ike security-associations comando.

Verificando as associações de segurança do servidor VPN do grupo para IPsec

Propósito

Verifique os SAs do servidor VPN do grupo para IPsec.

Ação

A partir do modo operacional, entre no show security group-vpn server ipsec security-associations comando.

Verificação de associações de segurança de membros de VPN do grupo para IKE

Propósito

Verifique os SAs para os membros vpn do grupo para IKE.

Ação

A partir do modo operacional, entre no show security group-vpn member ike security-associations comando.

Verificando as associações de segurança de membros do Grupo VPN para IPsec

Propósito

Verifique os SAs para os membros vpn do grupo para IPsec.

Ação

A partir do modo operacional, entre no show security group-vpn member ipsec security-associations comando.

Tabela de histórico de liberação
Versão
Descrição
12.3X48-D30
Começando com o Junos OS Release 12.3X48-D30, os membros do Grupo VPNv1 podem interoperar com servidores VPNv2 do grupo.
12.3X48-D30
Começando pelo Junos OS Release 12.3X48-D30, membros do Grupo VPNv1 no SRX100, SRX110, SRX210, SRX220, SRX240, SRX550 e SRX650 podem interoperar com servidores do Grupo VPNv2.