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 necessários para proteger o tráfego de grupo ip multicast ou o tráfego unicast em uma WAN privada que se origina ou flue por meio de um dispositivo.

Visão geral do GRUPO VPNv1

Uma associação de segurança IPsec (SA) é um acordo unidirecional entre os participantes da rede privada virtual (VPN) que define as regras de uso para algoritmos de autenticação e criptografia, mecanismos de troca de chaves e comunicações seguras. Com as implementações de VPN atuais, a SA é um túnel ponto a ponto entre dois dispositivos de segurança. O grupo VPNv1 amplia a arquitetura IPsec para dar suporte a SAs compartilhados por um grupo de dispositivos de segurança (consulte Figura 1 ).

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

O grupo VPNv1 é compatível com SRX100, SRX110, SRX210, SRX220, SRX240 e SRX650 de segurança. Com o grupo VPNv1, conectividade any-to-any (entre dois ou mais pontos) alcançada com a preservação dos endereços IP de origem e destino no header externo. Os pacotes multicast seguros são replicados da mesma maneira que os pacotes cleartext multicast na rede de núcleo.

A partir da versão 12.3X48-D30 Junos OS, os membros do Grupo VPNv1 podem operar com servidores VPNv2 do grupo.

O grupo VPNv1 tem algumas limitações de propriedade relacionadas à RFC 6407, The Group Domain of Interpretation (GDOI). Para usar a VPN do grupo sem limitações proprietárias, atualize para o grupo VPNv2. O grupo VPNv2 é compatível com vSRX instâncias, começando com os dispositivos Junos OS Release 15.1X49-D30, Série SRX, a partir dos dispositivos Junos OS Release 15.1X49-D40 e Série MX, a partir do Junos OS Release 15.1r2.

Entender o protocolo GDOI para VPNv1 do grupo

O grupo VPNv1 baseia-se na RFC 3547, The Group Domain of Interpretation (GDOI). Esta RFC descreve o protocolo entre membros do grupo e um servidor de grupo para estabelecer SAs entre os membros do grupo. Mensagens 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 IKE AutoKey. A Fase 1 permite que dois dispositivos estabeleçam uma SA ISAKMP. A Fase 2 estabelece SAs para outros protocolos de segurança, como o GDOI.

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

Existem dois tipos de trocas GDOI:

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

  • A troca é uma única mensagem rekey que permite ao servidor enviar SAs em grupo e chaves para os membros antes que os SAs do groupkey-push grupo existente expirem. Mensagens chaves são mensagens não solicitadas enviadas do servidor para os membros.

Entender as limitações do GRUPO VPNv1

Nesta versão, não há suporte para VPNv1 do grupo:

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

  • cluster de chassi

  • clusters de servidor

  • VPN em grupo baseada em rotear

  • Implantação pública baseada na Internet

  • Snmp

  • Negar política do servidor Cisco GET VPN

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

A partir do Junos OS Release 12.3X48-D30, os membros do Grupo VPNv1 nos SRX100, SRX110, SRX210, SRX220, SRX240, SRX550 e SRX650 podem operar com os servidores VpNv2 do grupo. Ao configurar os membros do grupo VPNv1 para uso com servidores VPNv2 do grupo, observe as seguintes limitações:

  • O VPNv2 do grupo tem suporte para IETF projeto de especificação IP Delivery Delay Detection Protocol para um mecanismo de antireplay baseado em tempo. Portanto, a antireplay baseada em protocolo de detecção de atraso de entrega IP não é suportada nos membros do grupo VPNv1 e deve ser desabilitada no servidor VPNv2 do grupo com deactivate security group-vpn server group group-name anti-replay-time-window o comando.

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

  • O servidor VPNv2 do grupo não tem suporte para transmitais de coração. O coração do coração deve ser desabilitado no membro do grupo VPNv1 com o deactivate security group-vpn member ipsec vpn vpn-name heartbeat-threshold comando. Recomendamos usar clusters de servidor VPNv2 do grupo para evitar o impacto do tráfego devido a reinicializações ou outras interrupções no servidor de VPNv2 do grupo.

  • As mensagens push-push de grupo enviadas do servidor VPNv2 do grupo são baseadas em RFC 6407, The Group Domain of Interpretation (GDOI) e não são suportadas nos membros do grupo VPNv1. Portanto, as mensagens groupkey-push devem ser desabilitadas no servidor VPNv2 do grupo com o deactivate security group-vpn server group group-name server-member-communication comando.

    As chaves de texto são suportadas com mensagens de pull em grupo. Se houver problemas de escalonamento nos quais os membros do Grupo VPNv1 não podem concluir a operação groupkey-pull antes da vida útil dura do TEK expirar, recomendamos aumentar a vida útil do TEK para permitir tempo suficiente para os membros concluirem a operação groupkey-pull. Juniper 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 serem eliminados, novos membros não poderão ser adicionados à rede até que a próxima chave ocorra para os membros existentes. Novos membros não podem enviar tráfego para membros existentes que tenham chaves antigas. Como solução alternativa, limpar as SAs sobre os membros VPNv1 do grupo existentes com o clear security group-vpn member ipsec security-associations comando.

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

Entender os servidores e os membros do grupo VPNv1

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

  • Membro do grupo Controles

  • Gera chaves de criptografia

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

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

Um servidor de grupo pode ser atendido por 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, que é um número entre 1 e 65.535. O servidor de grupo e os membros do grupo são vinculados juntos pelo identificador de 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 de servidor e membro de VPN de grupo:

  1. O servidor de grupo escuta na porta UDP 848 para que os membros se inscrevam. Um dispositivo de membro deve fornecer autenticação IKE Fase 1 correta para se juntar ao grupo. É suportada autenticação de chaves pré-compartilhadas por membro.

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

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

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

Periodicamente, o servidor envia SA e atrúes-chave para os membros do grupo com mensagens rekey (GDOI). groupkey-push Mensagens chaves são enviadas antes de os SAs expirarem; isso garante que chaves válidas estão disponíveis para criptografar tráfego entre os membros do grupo.

O servidor também envia mensagens reajustadas para fornecer novas chaves para os membros quando houver uma mudança na adesão ao grupo ou quando a S.A do grupo tiver sido mudada.

Entender a comunicação do membro do servidor VPNv1 do grupo

O grupo VPNv1 é compatível com SRX100, SRX110, SRX210, SRX220, SRX240 e SRX650 de segurança. A comunicação com membro do servidor permite que o servidor envie mensagens GDOI groupkey-push para os membros. Caso a comunicação com membro do servidor não esteja configurada para o grupo, os membros podem enviar mensagens GDOI para registrar e recadastrar-se no servidor, mas o servidor não pode enviar mensagens rekey para os groupkey-pull membros.

A comunicação do membro do servidor está configurada para o grupo usando a instrução server-member-communication de configuração na hierarquia edit security group-vpn server [ ] 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 existe nenhum algoritmo padrão.

  • Algoritmo de autenticação (md5 ou sha1) usado para autenticar o membro ao servidor. Não existe nenhum algoritmo padrão.

  • Seja o servidor que envia mensagens unicast ou multicast para membros de grupo e parâmetros relacionados ao tipo de comunicação.

  • Intervalo no qual o servidor envia mensagens de coração para o membro do grupo. Com isso, o membro pode determinar se o servidor foi reinicializado, o que exigiria o recadastramento do servidor. O padrão é de 300 segundos.

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

Configurar a comunicação do membro do servidor é necessário para que o servidor de grupo envie mensagens rekey para os membros, mas pode haver situações em que esse comportamento não seja desejado. Por exemplo, se os membros do grupo são peers dinâmicos (como em um home office), nem sempre os dispositivos estão acionados e o endereço IP de um dispositivo pode ser diferente a cada vez que for acionado. Configurar a comunicação do membro do servidor para um grupo de peers dinâmicos pode resultar em transmissões desnecessárias pelo servidor. Se você quiser IKE uma negociação SA da fase 1 sempre a ser executada para proteger a negociação GDOI, não configure a comunicação do membro do servidor.

Caso a comunicação do membro do servidor para um grupo não esteja configurada, a lista de membros exibido pelo comando mostra os membros do grupo que se registraram no servidor; os membros podem estar ativos show security group-vpn server registered-members ou não. Quando a comunicação do membro do servidor para um grupo está configurada, a lista de membros do grupo é liberada. Se o tipo de comunicação estiver configurado como unicast, show security group-vpn server registered-members o comando mostrará apenas membros ativos. Caso o tipo de comunicação esteja configurado como multicast, o comando mostra os 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 sair após o show security group-vpn server registered-members registro.

Entender as operações-chave do grupo VPNv1 Group

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

Chaves de grupo

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

  • Chave de criptografia (KEK) — Usado para criptografar mensagens recriadas. Um KEK é suportado por grupo.

  • TEK (Traffic Encryption Key, Chave de criptografia de tráfego) — Usado para criptografar e descriptografar o tráfego de dados IPsec entre os 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 recusada é descartada.

Mensagens prontas

Caso o grupo esteja configurado para comunicações com membros do servidor, o servidor envia PERIODICAMENTE SA e a chave é atualizada para os membros do grupo com mensagens rekey (GDOI). groupkey-push Mensagens chaves são enviadas antes de os SAs expirarem; isso garante que chaves válidas estão disponíveis para criptografar tráfego entre os 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 se a SA do grupo tiver sido alterada (por exemplo, uma política de grupo é adicionada ou eliminada).

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

Existem dois tipos de mensagens chaves:

  • Mensagens chaves da Unicast — O servidor de grupo envia uma cópia da mensagem rekey para cada membro do grupo. Após o recebimento da mensagem rekey, os membros devem enviar um reconhecimento (ACK) ao servidor. Caso o servidor não receba um 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 para de enviar mensagens rekey para o membro.

    As declarações de configuração e as declarações de configuração para comunicações do servidor controlam number-of-retransmission o ressamento de mensagens chaves pelo servidor quando nenhum ACK é retransmission-period recebido de um membro.

  • Mensagens chaves de multicast — O servidor de grupo envia uma cópia da mensagem rekey da interface de saída especificada para o endereço do grupo multicast configurado. Os membros não enviam reconhecimento do recebimento de mensagens prontas para multicast. A lista de membros registrado não representa necessariamente membros ativos, porque os membros podem sair após o registro inicial. Todos os membros do grupo precisam estar configurados para dar suporte a mensagens multicast.

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

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

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

Registro de membro

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

A recadastração de membro pode ocorrer pelos seguintes motivos:

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

  • A mensagem rekey do servidor de grupo é perdida ou retardada, e a vida útil do TEK expirou.

Ativação de chaves

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 activation-time-delay é determinado pela instrução de configuração e se a chave é recebida por meio de uma mensagem rekey enviada do servidor ou como resultado do recadastramento do membro com o servidor.

Caso a chave seja recebida por meio de uma mensagem rekey enviada do servidor, o membro espera 2*( ) segundos antes de activation-time-delay usar a chave. Caso a chave seja recebida por meio do recadastramento de membro, o membro espera o número de segundos especificado pelo activation-time-delay valor.

Um membro mantém as duas chaves mais recentes enviadas do servidor para cada grupo SA 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 depois que a nova chave é ativada.

O padrão da instrução activation-time-delay de configuração é de 15 segundos. Definir esse período de tempo muito pequeno pode fazer com que um pacote seja abandonado em um membro do grupo remoto antes da nova chave ser instalada. Considere os atrasos de transporte da topologia e do sistema quando você alterar 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 groupkey-pull solicitação. O seguinte descreve como o membro do grupo VPNv1 lida com o TEK existente e os TEKs que ele recebe do servidor:

  • Caso o membro do grupo VPNv1 receba dois ou mais TEKs, ele detém os dois TEKs mais recentes e elimina o TEK existente. Dos dois TEKs mantidos, o TEK mais antigo é ativado imediatamente, e o TEK mais novo é ativado depois que o servidor VPNv1 configurado em grupo tenha se desacordo (o padrão é activation-time-delay de 15 segundos).

  • Caso o membro do grupo VPNv1 receba apenas um TEK ou se receber um TEK por meio de uma mensagem do servidor, o TEK existente não será excluído até que a vida útil groupkey-push expirar. 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 inferior a duas vezes o activation-time-delay valor.

Entender mensagens de coração do grupo VPNv1

Quando a comunicação do membro do servidor está configurada, o servidor VPNv1 do grupo envia mensagens de coração para os membros em intervalos especificados (o intervalo padrão é de 300 segundos). O mecanismo de pulsação permite que os membros recadastram-se 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 coração durante uma reinicialização do servidor. Quando o servidor for reinicializado, os membros recadastram o servidor.

Os batimentos cardíacos são groupkey-push transmitidas por meio de mensagens. O número de sequência é incrementado em cada mensagem de coração, o que protege os membros contra ataques de resposta. Ao contrário das mensagens re-chaves, as mensagens de coração não são reconhecidas por receptores e não são retransmitidas pelo servidor.

As mensagens de coração contêm as seguintes informações:

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

  • Tempo relativa, se a antireplay estiver ativada

Ao comparar as informações nos batimentos cardíacos, um membro pode detectar se perdeu informações do servidor ou mensagens rekey. O membro se reregrega para se sincronizar com o servidor.

Mensagens de coração podem aumentar o congestionamento da rede e causar recadastramentos de membros desnecessárias. Assim, a detecção de coração pode ser desabilitada no membro, se necessário.

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

As funções do servidor de grupo e dos membros do grupo são diferentes 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 colocation, 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 endereços IP diferentes para que os pacotes possam ser entregues corretamente. No modo colocation, só pode haver um endereço IP atribuído ao servidor e um endereço IP atribuído ao membro entre os grupos.

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

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

No servidor de grupo, configure o seguinte:

  1. IKE de fase 1. Use a hierarquia [ edit security group-vpn server ike ] para configurar a IKE Fase 1 SA. Consulte a compreensão IKE configuração da fase 1 para o grupo VPNv2.
  2. IPsec SA fase 2. Consulte Entender a configuração IPsec SA para VPNv1 do grupo.
  3. grupo VPN. Consulte a visão geral da configuração do grupo VPNv1.

No membro do grupo, configure o seguinte:

  1. IKE de fase 1. Use a hierarquia [ edit security group-vpn member ike ] para configurar IKE Fase 1 SA. Consulte a compreensão IKE configuração da Fase 1 para VPNv1 do grupo.

  2. IPsec SA fase 2. Consulte Entender a configuração IPsec SA para VPNv1 do grupo.

  3. Política de escopo que determina quais políticas de grupo estão instaladas no membro. Consulte Entender as políticas dinâmicas para 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 unidade de transmissão máxima (MTU) não maior que 1.400 bytes. Use a set interface mtu instrução de configuração para definir o MTU tamanho.

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

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 instrução ike-gateway de configuração. Pode haver várias instâncias dessa instrução de configuração, uma para cada membro do grupo.

  • Endereço IP do servidor (recomenda-se o endereço da interface de loopback).

  • Políticas de grupo — Políticas que devem ser baixadas para os membros. As políticas de grupo descreverão o tráfego ao qual a SA e as chaves se aplicam. Consulte Entender as políticas dinâmicas para VPNv1 do grupo.

  • Comunicação com membro do servidor — configuração opcional que permite ao servidor enviar mensagens rekey para os membros. Consulte a visão geral do GRUPO VPNv1.

  • Antireplay — configuração opcional que detecta interceptação e reprodução de pacotes. Veja a compreensão da antireplay para o grupo VPNv1.

Compreender IKE configuração de fase 1 para VPNv1 do grupo

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

Na configuração IKE proposta, você definirá 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 IKE política, você configura o modo (principal ou agressivo) no qual o canal da Fase 1 será negociado, especifique o tipo de troca de chaves a ser usada e referência à proposta da Fase 1. Na configuração IKE gateway, você faz referência à política de Fase 1.

Como o grupo VPNv2 só aceita algoritmos fortes, a opção do algoritmo de autenticação é compatível com os membros do sha-256 grupo VPNv1 em 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, é necessário estar configurado para IKE propostas e estar configurado para as propostas authentication-algorithm sha-256authentication-algorithm hmac-sha-256-128 do IPsec.

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

A configuração IKE Fase 1 no servidor de grupo deve combinar a configuração IKE Fase 1 nos membros do grupo.

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

Depois que o servidor e o membro estabeleceram um canal seguro e autenticado na negociação da Fase 1, eles passam pela Fase 2. A negociação da fase 2 estabelece as SAs IPsec compartilhadas por membros do grupo para proteger dados que são transmitidas entre os membros. Embora a configuração IPsec SA para VPN em grupo seja semelhante à configuração de 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 o grupo VPNv1 consiste nas seguintes informações:

  • Uma proposta para que o protocolo de segurança, a autenticação e o algoritmo de criptografia sejam usados na S.A. A proposta IPsec SA está configurada no servidor de grupo com proposal a instrução de configuração na hierarquia edit security group-vpn server ipsec [ ]

  • Uma política de grupo que referencia a 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 instrução ipsec-sa de configuração na hierarquia edit security group-vpn server group [ ]

  • Uma IKE autokey que referencia o identificador de grupo, o servidor de grupo (configurado com a instrução de configuração) e a interface usada pelo membro para se conectar ao ike-gateway grupo. O sistema autokey IKE está configurado no membro com a instrução ipsec vpn de configuração na hierarquia edit security group-vpn member [ ]

Compreender políticas dinâmicas para VPNv1 de grupo

O servidor de grupo distribui SAs em 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 estão instalados em todos os membros do grupo. A SA instalada em um membro específico é determinada pela política associada ao grupo SA e pelas políticas de segurança configuradas no membro.

Em um grupo de VPN, cada GRUPO SA e a chave que o servidor pressiona para um membro estão associadas a uma política de grupo. A política de 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.

Políticas de grupo que são 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. Nesse 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 define o escopo da política de grupo baixada do servidor. Uma política de grupo distribuída do servidor é comparada às 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 do intervalo 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 àqueles 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 olhada na política de segurança nos pacotes recebidos a partir do topo da lista ordenada.

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

  • Se o pacote de entrada estiver de acordo com uma política de segurança antes da política de escopo ser considerada, a análise da política dinâmica não ocorrerá.

  • Se uma política de entrada for compatível com uma política de escopo, o processo de pesquisa continuará a procurar uma política dinâmica correspondente. Se houver uma política dinâmica correspondente, essa ação (permissão) será executada. Caso não haja política dinâmica correspondente, o processo de pesquisa continua a pesquisar as políticas abaixo da política de escopo.

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

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

Compreender a antireplay para o grupo VPNv1

O antireplay é um recurso IPsec que pode detectar quando um pacote é interceptado e reprisado por invasores. A antireplay é habilitada por padrão para VPNs de grupo, mas pode ser desabilitada para um grupo com a instrução no-anti-replay de configuração.

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

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

Este exemplo mostra como configurar o grupo VPNv1 para estender a arquitetura IPsec para dar suporte a SAs compartilhadas por um grupo de dispositivos de segurança. O grupo VPNv1 é compatível com SRX100, SRX110, SRX210, SRX220, SRX240 e SRX650 de segurança.

Requisitos

Antes de começar:

Visão geral

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

Figura 2: Exemplo de configuração do servidor-membroExemplo de configuração do servidor-membro

As SAs de grupo De Fase 2 precisam ser protegidas por uma SA de fase 1. Portanto, a configuração de VPN do grupo deve incluir a configuração IKE negociações da Fase 1, tanto no servidor de grupo como nos membros do grupo. Além disso, o mesmo identificador de grupo precisa estar configurado no servidor de grupo e nos membros do grupo.

As políticas de grupo estão configuradas no servidor de 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 instaladas no membro. Neste exemplo, as seguintes políticas de grupo estão configuradas no servidor de grupo para download para 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 está configurado com políticas de escopo que permitem que todo o tráfego unicast entre e a sub-rede 10.0.0.0/8. Não há política de escopo configurada no membro1 para permitir tráfego multicast; portanto, a política DEA p3 não está instalada no membro1.

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

Configuração

Configuração do servidor de grupo

Configuração rápida CLI

Para configurar rapidamente este exemplo, copie os comandos a seguir, confie-os em um arquivo de texto, remova quaisquer quebras de linha, altere quaisquer detalhes necessários para combinar a configuração da rede, copie e copie e copie os comandos na CLI no nível da hierarquia e, em seguida, entre no modo de [edit]commit configuração.

Procedimento passo a passo

O exemplo a seguir requer que você navegar por vários níveis na hierarquia de configuração. Para obter instruções sobre como fazer isso, consulte Como usar o ClI Editor no modo de configuração.

Para configurar o servidor de grupo:

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

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

  3. Defina a IKE e defina os gateways remotos.

  4. Configure o exchange SA de Fase 2.

  5. Configure o identificador de grupo e IKE gateway.

  6. Configure as 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 ao entrar no show security group-vpn server comando. Se a saída não apresentar a configuração pretendido, repetirá as instruções de configuração neste exemplo para corrigi-la.

Caso você não configure o dispositivo, entre commit no modo de configuração.

Configuração do Membro1

Configuração rápida CLI

Para configurar rapidamente este exemplo, copie os comandos a seguir, confie-os em um arquivo de texto, remova quaisquer quebras de linha, altere quaisquer detalhes necessários para combinar a configuração da rede, copie e copie e copie os comandos na CLI no nível da hierarquia e, em seguida, entre no modo de [edit]commit configuração.

Procedimento passo a passo

O exemplo a seguir requer que você navegar por vários níveis na hierarquia de configuração. Para obter instruções sobre como fazer isso, consulte Como usar o ClI Editor no modo de configuração.

Para configurar o membro1:

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

  2. Defina a IKE e defina os gateways remotos.

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

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

  4. Crie livros de endereço e anexe zonas a eles.

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

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

Resultados

A partir do modo de configuração, confirme sua configuração inserindo show security group-vpn member os comandos e os show security policies comandos. Se a saída não apresentar a configuração pretendido, repetirá as instruções de configuração neste exemplo para corrigi-la.

Caso você não configure o dispositivo, entre commit no modo de configuração.

Configuração do Membro2

Configuração rápida CLI

Para configurar rapidamente este exemplo, copie os comandos a seguir, confie-os em um arquivo de texto, remova quaisquer quebras de linha, altere quaisquer detalhes necessários para combinar a configuração da rede, copie e copie e copie os comandos na CLI no nível da hierarquia e, em seguida, entre no modo de [edit]commit configuração.

Procedimento passo a passo

O exemplo a seguir requer que você navegar por vários níveis na hierarquia de configuração. Para obter instruções sobre como fazer isso, consulte Como usar o ClI Editor no modo de configuração.

Para configurar o membro2:

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

  2. Defina a IKE e defina o gateway remoto.

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

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

  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 de confiança.

  6. Configure uma política de escopo da zona de confiança para a zona de confiança que bloqueia o tráfego de 10.1.0.0/16.

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

Resultados

A partir do modo de configuração, confirme sua configuração inserindo show security group-vpn member os comandos e os show security policies comandos. Se a saída não apresentar a configuração pretendido, repetirá as instruções de configuração neste exemplo para corrigi-la.

Caso você não configure o dispositivo, entre commit no modo de configuração.

Verificação

Para confirmar se a configuração está funcionando corretamente, realize essa tarefa:

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

Propósito

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

Ação

Depois que o servidor do grupo baixar as chaves para membro1, insira show security dynamic-policies o comando do modo operacional.

Significado

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

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

Propósito

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

Ação

Depois que o servidor do grupo baixar as chaves para o membro2, insira show security dynamic-policies o comando do 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 ela bate com a política de segurança deny2 configurada no membro2.

Exemplo: Configuração da comunicação do servidor VPNv1 do grupo para mensagens rekey unicast

Este exemplo mostra como permitir que o servidor envie mensagens prontas para unicast para os membros do grupo a fim de garantir que chaves válidas estão disponíveis para criptografar o tráfego entre os membros do grupo. O grupo VPNv1 é compatível com SRX100, SRX110, SRX210, SRX220, SRX240 e SRX650 de segurança.

Requisitos

Antes de começar:

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

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

  • Configure o grupo g1 no servidor de grupo.

Visão geral

Neste exemplo, você especificará os seguintes parâmetros de comunicação entre servidor e membro do g1 grupo:

  • O servidor envia mensagens rekey unicast para os membros do grupo.

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

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

Os valores padrão são usados para pulsações do servidor, vida útil do KEK e retransmissões.

Configuração

Procedimento

Procedimento passo a passo

O exemplo a seguir requer que você navegar por vários níveis na hierarquia de configuração. Para obter instruções sobre como fazer isso, consulte Como usar o ClI Editor no modo de configuração.

Para configurar a comunicação do membro do servidor:

  1. Definir o tipo de comunicações.

  2. Definir o algoritmo de criptografia.

  3. De definir a autenticação de membro.

Verificação

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

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

Este exemplo mostra como permitir que o servidor envie mensagens chaves multicast para os membros do grupo a fim de garantir que chaves válidas estão disponíveis para criptografar o tráfego entre os membros do grupo. O grupo VPNv1 é compatível com SRX100, SRX110, SRX210, SRX220, SRX240 e SRX650 de segurança.

Requisitos

Antes de começar:

Visão geral

Neste exemplo, você especificará a seguinte comunicação de membro do servidor para o g1 grupo:

  • O servidor envia mensagens prontas para multicast para os 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 tráfego entre o servidor e os membros.

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

Os valores padrão são usados para pulsações do servidor, vida útil do KEK e retransmissões.

Configuração

Procedimento

Configuração rápida CLI

Para configurar rapidamente este exemplo, copie os comandos a seguir, confie-os em um arquivo de texto, remova quaisquer quebras de linha, altere quaisquer detalhes necessários para combinar a configuração da rede, copie e copie e copie os comandos na CLI no nível da hierarquia e, em seguida, entre no modo de [edit]commit configuração.

Procedimento passo a passo

O exemplo a seguir requer que você navegar por vários níveis na hierarquia de configuração. Para obter instruções sobre como fazer isso, consulte Como usar o ClI Editor no modo de configuração.

Para configurar a comunicação do membro do servidor para mensagens rekey multicast:

  1. Definir o tipo de comunicações.

  2. De definir o grupo multicast.

  3. De definir a interface para mensagens de multicast de saída.

  4. Definir o algoritmo de criptografia.

  5. De definir a autenticação de membro.

Resultados

A partir do modo de configuração, confirme sua configuração ao entrar no show security group-vpn server group g1 server-member-communication comando. Se a saída não apresentar a configuração pretendido, repetirá as instruções de configuração neste exemplo para corrigi-la.

Caso você não configure o dispositivo, entre commit no modo de configuração.

Verificação

Para confirmar se a configuração está funcionando corretamente, realize essas tarefas:

Verificação da comunicação do membro do servidor para mensagens chaves de multicast

Propósito

Verificar se os parâmetros de comunicação do membro do servidor para a mensagem rekey multicast estão configurados corretamente para garantir que chaves válidas estão disponíveis para criptografar o tráfego entre os membros do grupo.

Ação

Do modo operacional, insira o show security group-vpn server group g1 server-member-communication comando.

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

Este exemplo mostra como configurar um dispositivo para o modo colocation, que permite que funções de servidor e membro coexistam no mesmo dispositivo físico. O grupo VPNv1 é compatível com SRX100, SRX110, SRX210, SRX220, SRX240 e SRX650 de segurança.

Requisitos

Antes de começar:

Visão geral

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

Em, um vpn em grupo (identificador de grupo é 1) é composto por dois membros (membro1 e membro2) e um servidor de grupo (o endereço IP da interface de loopback é Figura 3 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ído ao endereço IP 10.1.0.1/32.

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

As instruções de configuração deste tópico descreve como configurar o dispositivo group server-member1 para o modo de colocação. Para configurar o membro2, consulte Exemplo: Configuração do servidor e dos membros do grupo VPNv1.

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

Configuração

Procedimento

Configuração rápida CLI

Para configurar rapidamente este exemplo, copie os comandos a seguir, confie-os em um arquivo de texto, remova quaisquer quebras de linha, altere quaisquer detalhes necessários para combinar a configuração da rede, copie e copie e copie os comandos na CLI no nível da hierarquia e, em seguida, entre no modo de [edit]commit configuração.

Procedimento passo a passo

O exemplo a seguir requer que você navegar por vários níveis na hierarquia de configuração. Para obter instruções sobre como fazer isso, consulte Como usar o ClI Editor no modo de configuração.

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

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

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

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

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

  5. Defina a IKE e defina os gateways remotos.

  6. Configure o exchange SA de Fase 2 para o servidor.

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

  8. Configure as comunicações do servidor para os membros.

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

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

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

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

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

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

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

Resultados

A partir do modo de configuração, confirme sua configuração ao entrar show security group-vpn no e-mail e show security policies no comando. Se a saída não apresentar a configuração pretendido, repetirá 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 sejam listadas antes das políticas padrão.

Caso você não configure o dispositivo, entre commit no modo de configuração.

Verificação

Para confirmar se a configuração está funcionando corretamente, realize essas tarefas:

Verificação do registro de membro da VPN do grupo

Propósito

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

Ação

Do modo operacional, insira o show security group-vpn registered-members comando.

Verificar associações de segurança de servidor vpn em grupo para IKE

Propósito

Verificar as SAs para o servidor de VPN de grupo para IKE.

Ação

Do modo operacional, insira o show security group-vpn server ike security-associations comando.

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

Propósito

Verificar as SAs para O servidor de VPN de grupo para IPsec.

Ação

Do modo operacional, insira o show security group-vpn server ipsec security-associations comando.

Verificar associações de segurança de membros do grupo VPN para IKE

Propósito

Verificar os SAs para os membros da VPN do grupo para IKE.

Ação

Do modo operacional, insira o show security group-vpn member ike security-associations comando.

Verificar associações de segurança de membros do grupo VPN para IPsec

Propósito

Verificar os SAs para os membros de VPN do grupo para IPsec.

Ação

Do modo operacional, insira o show security group-vpn member ipsec security-associations comando.

Tabela de histórico de liberação
Versão
Descrição
12.3X48-D30
A partir da versão 12.3X48-D30 Junos OS, os membros do Grupo VPNv1 podem operar com servidores VPNv2 do grupo.
12.3X48-D30
A partir do Junos OS Release 12.3X48-D30, os membros do Grupo VPNv1 nos SRX100, SRX110, SRX210, SRX220, SRX240, SRX550 e SRX650 podem operar com os servidores VpNv2 do grupo.