Sobre os requisitos criptográficos e os gateways de VPN do Azure
Este artigo discute como é possível configurar os gateways de VPN do Azure para satisfazer seus requisitos criptográficos para ambos os túneis de VPN S2S entre instalações e as conexões Rede Virtual a Rede Virtual no Azure.
Sobre IKEv1 e IKEv2 para conexões VPN do Azure
Tradicionalmente, permitimos conexões IKEv1 somente para SKUs básicas e conexões IKEv2 permitidas para todas as SKUs de gateway de VPN diferentes de SKUs básicas. Os SKUs básicos permitem apenas uma conexão e, juntamente com outras limitações, como desempenho, os clientes que usam dispositivos herdados que dão suporte apenas a protocolos IKEv1 têm experiência limitada. Para aprimorar a experiência dos clientes que usam protocolos IKEv1, agora estamos permitindo conexões IKEv1 para todos os SKUs do gateway VPN, exceto SKU Básico. Para obter mais informações, confira SKUs do Gateway de VPN. Observe que os gateways de VPN que usam IKEv1 podem experimentar reconexões de túnel durante os rechaveamentos de modo principal.
Quando as conexões IKEv1 e IKEv2 são aplicadas ao mesmo gateway de VPN, o trânsito entre essas duas conexões é habilitado automaticamente.
Sobre os parâmetros de política IKE e IPsec para os gateways de VPN do Azure
O padrão de protocolo IKE e IPsec suporta uma ampla gama de algoritmos criptográficos em várias combinações. Se você não solicitar uma combinação específica de algoritmos e algoritmo de criptografia, os gateways de VPN do Azure usarão um conjunto de propostas padrão. Os conjuntos de políticas padrão foram escolhidos para maximizar a interoperabilidade com uma ampla gama de dispositivos de VPN de terceiros em configurações padrão. Como resultado, as políticas e o número de propostas não podem cobrir todas as combinações possíveis de algoritmo de criptografia disponíveis e dos principais pontos fortes.
Política padrão
O conjunto de políticas padrão para o gateway de VPN do Azure está listado no artigo: Sobre dispositivos VPN e parâmetros IPsec/IKE para conexões de Gateway de VPN Site a Site.
Requisitos criptográficos
Para comunicações que exigem parâmetros ou algoritmos criptográficos específicos, geralmente devido a requisitos de segurança ou conformidade, você agora pode configurar seus gateways de VPN do Azure para usar uma política de IPsec/IKE personalizada com algoritmos de criptografia específicos e intensidades de chave, em vez dos conjuntos de políticas padrão do Azure.
Por exemplo, as políticas de modo principal do IKEv2 para os gateways de VPN do Azure utilizam apenas o Grupo Diffie-Hellman 2 (1.024 bits), enquanto você pode precisar especificar grupos mais fortes a serem usados no IKE, como o Grupo 14 (2.048 bits), o Grupo 24 (Grupo MODP de 2.048 bits) ou o ECP (grupos de curvas elípticas) 256 ou 384 bits (Grupo 19 e Grupo 20, respectivamente). Requisitos semelhantes aplicam-se também às políticas de modo rápido do IPsec.
Política de IPsec/IKE personalizada com gateways de VPN do Azure
Os gateways de VPN agora suportam política de IPsec/IKE personalizada por conexão. Para uma conexão Site a Site ou Rede Virtual a Rede Virtual, você pode escolher uma combinação específica de algoritmos criptográficos para IPsec e IKE com a intensidade de chave desejada, como mostrado neste exemplo:
Você pode criar uma política de IPsec/IKE e aplicar a uma conexão nova ou existente.
Fluxo de trabalho
- Crie as redes virtuais, os gateways de VPN ou os gateways de rede local para sua topologia de conectividade, conforme descrito em outros documentos de instruções.
- Criar uma política de IPsec/IKE.
- Você pode aplicar a política ao criar uma conexão S2S ou conexão VNet a VNet.
- Se a conexão já estiver criada, você poderá aplicar ou atualizar a política para uma conexão existente.
FAQ sobre a política de IPsec/IKE
A política de IPsec/IKE personalizada é compatível com todos os SKUs de Gateway de VPN do Azure?
A política de IPsec/IKE personalizada é compatível com todos os SKUs do Gateway de VPN do Azure, exceto pelo SKU Básico.
Quantas políticas eu posso especificar em uma conexão?
Você só pode especificar uma combinação de políticas para uma determinada conexão.
Posso especificar uma política parcial em uma conexão (por exemplo, apenas algoritmos IKE, mas não IPsec)?
Não, você deve especificar todos os algoritmos e parâmetros para IKE (modo principal) e IPsec (modo rápido). A especificação de política parcial não é permitida.
A quais algoritmos e pontos fortes a política personalizada dá suporte?
A tabela a seguir lista as forças da chave e os algoritmos de criptografia configuráveis compatíveis. Você deve selecionar uma opção para cada campo.
IPsec/IKEv2 | Opções |
---|---|
Criptografia IKEv2 | GCMAES256, GCMAES128, AES256, AES192, AES128 |
Integridade IKEv2 | SHA384, SHA256, SHA1, MD5 |
Grupo DH | DHGroup24, ECP384, ECP256, DHGroup14, DHGroup2048, DHGroup2, DHGroup1, Nenhum |
Criptografia IPsec | GCMAES256, GCMAES192, GCMAES128, AES256, AES192, AES128, DES3, DES, nenhum |
Integridade IPsec | GCMAES256, GCMAES192, GCMAES128, SHA256, SHA1, MD5 |
Grupo PFS | PFS24, ECP384, ECP256, PFS2048, PFS2, PFS1, nenhum |
Tempo de vida de SA do Modo Rápido | (Opcional; valores padrão, se não for especificado) Segundos (inteiro; mínimo 300, padrão 27.000) Quilobytes (inteiro; mínimo 1.024, padrão 10.2400.000) |
Seletor de tráfego | UsePolicyBasedTrafficSelectors ($True ou $False , mas opcional; $False padrão, se não for especificado) |
Tempo limite de DPD | Segundos (inteiro; mínimo 9, máximo 3.600, padrão 45) |
A configuração do dispositivo VPN local precisa corresponder ou conter os seguintes algoritmos e parâmetros que você especifica na política de IPsec ou IKE do Azure:
- Algoritmo de criptografia IKE (Modo Principal, Fase 1)
- Algoritmo de integridade IKE (Modo Principal, Fase 1)
- Grupo DH (Modo Principal, Fase 1)
- Algoritmo de criptografia IPsec (Modo Rápido, Fase 2)
- Algoritmo de integridade IPsec (Modo Rápido, Fase 2)
- Grupo PFS (Modo Rápido, fase 2)
- Seletor de tráfego (se você usar
UsePolicyBasedTrafficSelectors
) - Tempos de vida de SA (especificações locais que não precisam ser correspondentes)
Se você usar GCMAES para o algoritmo de criptografia IPsec, precisará selecionar o mesmo algoritmo GCMAES e comprimento de chave para integridade IPsec. Por exemplo, use GCMAES128 para ambos.
Na tabela de algoritmos e chaves:
- O IKE corresponde ao Modo Principal ou à Fase 1.
- O IPsec corresponde ao Modo Rápido ou à Fase 2.
- O grupo DH especifica o grupo Diffie-Hellman usando no Modo Principal ou na Fase 1.
- O grupo PFS especifica o grupo Diffie-Hellman usado no Modo Rápido ou na Fase 2.
O tempo de vida da SA de modo principal IKE é fixo em 28.800 segundos nos gateways de VPN do Azure.
UsePolicyBasedTrafficSelectors
é um parâmetro opcional na conexão. Se você definirUsePolicyBasedTrafficSelectors
para$True
em uma conexão, ele configurará o gateway de VPN para se conectar a um firewall VPN baseado em políticas locais.Se você habilitar
UsePolicyBasedTrafficSelectors
, verifique se o seu dispositivo VPN tem os seletores de tráfego correspondentes com todas as combinações dos prefixos de rede local (gateway de rede local) de ou para os prefixos de rede virtual do Azure, em vez de any-to-any. O gateway de VPN aceita qualquer seletor de tráfego proposto pelo gateway de VPN remoto, independentemente do que está configurado no gateway de VPN.Por exemplo, se os prefixos da rede local são 10.1.0.0/16 e 10.2.0.0/16, e os prefixos da rede virtual são 192.168.0.0/16 e 172.16.0.0/16, você precisa especificar os seguintes seletores de tráfego:
- 10.1.0.0/16 <====> 192.168.0.0/16
- 10.1.0.0/16 <====> 172.16.0.0/16
- 10.2.0.0/16 <====> 192.168.0.0/16
- 10.2.0.0/16 <====> 172.16.0.0/16
Para obter mais informações sobre seletores de tráfego baseados em política, confira Conectar um gateway de VPN a vários dispositivos VPN baseados em políticas locais.
Definir o tempo limite como períodos mais curtos faz com que o IKE faça o rechaveamento de forma mais agressiva. Em seguida, a conexão pode parecer estar desconectada em algumas instâncias. Essa situação pode não ser desejável se os locais estiverem distantes da região do Azure onde o gateway de VPN reside ou se a condição de link físico puder causar perda de pacotes. Geralmente, recomendamos que você defina o tempo limite entre 30 e 45 segundos.
Para saber mais, confira Conectar um gateway de VPN a vários dispositivos VPN locais baseados em políticas.
A quais grupos Diffie-Hellman a política personalizada dá suporte?
A seguinte tabela lista os Grupos Diffie-Hellman correspondentes compatíveis com a política personalizada:
Grupo Diffie-Hellman | DHGroup | PFSGroup | Comprimento da chave |
---|---|---|---|
1 | DHGroup1 | PFS1 | MODP de 768 bits |
2 | DHGroup2 | PFS2 | MODP de 1024 bits |
14 | DHGroup14 DHGroup2048 |
PFS2048 | MODP de 2048 bits |
19 | ECP256 | ECP256 | ECP de 256 bits |
20 | ECP384 | ECP384 | ECP de 384 bits |
24 | DHGroup24 | PFS24 | MODP de 2048 bits |
Para saber mais, confira RFC3526 e RFC5114.
A política personalizada substitui os conjuntos de políticas de IPsec/IKE padrão para gateways de VPN?
Sim. Depois que você especificar uma política personalizada em uma conexão, o Gateway de VPN do Azure usa apenas essa política na conexão, tanto como iniciador IKE quanto respondente IKE.
Se eu remover uma política de IPsec/IKE personalizada, a conexão ficará desprotegida?
Não, o IPsec/IKE ainda ajuda a proteger a conexão. Após você remover a política personalizada de uma conexão, o gateway de VPN reverterá para a lista padrão de propostas de IPsec/IKE e reiniciará o handshake do IKE com o dispositivo VPN local.
Adicionar ou atualizar uma política de IPsec/IKE pode atrapalhar minha conexão VPN?
Sim. Isso pode causar uma interrupção pequena (alguns segundos) uma vez que o gateway de VPN subdivide a conexão existente e reiniciará o handshake do IKE para restabelecer o túnel IPsec com os algoritmos de criptografia e os parâmetros novos. Verifique se o dispositivo VPN local também está configurado com os algoritmos correspondentes e as restrições de chave para minimizar a interrupção.
Eu posso usar políticas diferentes em conexões diferentes?
Sim. Uma política personalizada é aplicada em uma base por conexão. Você pode criar e aplicar políticas de IPsec/IKE diferentes em conexões diferentes.
Também é possível aplicar políticas personalizadas em um subconjunto de conexões. As restantes usam os conjuntos de políticas de IPsec/IKE padrão do Azure.
Eu posso usar uma política personalizada em conexões de VNet para VNet?
Sim. Você pode aplicar uma política personalizada em conexões entre locais de IPsec e em conexões de VNet para VNet.
É necessário especificar a mesma política em ambos os recursos de conexão de VNet para VNet?
Sim. Um túnel de VNet para VNet consiste em dois recursos de conexão no Azure, uma para cada sentido. Verifique se ambos os recursos de conexão têm a mesma política. Caso contrário, a conexão de VNet para VNet não será estabelecida.
Qual é o valor do tempo limite de DPD padrão? Posso especificar um tempo limite de DPD diferente?
O tempo limite de DPD padrão é de 45 segundos em gateways de VPN. Você pode especificar um valor de tempo limite de DPD diferente em cada conexão IPsec ou VNet a VNet entre 9 segundos e 3.600 segundos.
Observação
Definir o tempo limite como períodos mais curtos faz com que o IKE faça o rechaveamento de forma mais agressiva. Em seguida, a conexão pode parecer estar desconectada em algumas instâncias. Essa situação pode não ser desejável se os locais estiverem distantes da região do Azure onde o gateway de VPN reside ou se a condição de link físico puder causar perda de pacotes. Geralmente, recomendamos que você defina o tempo limite entre 30 e 45 segundos.
A política de IPsec/IKE personalizada funciona em conexões ExpressRoute?
Não. Uma política IPsec/IKE só funciona em conexões VNet para VNet e VPN S2S por meio de gateways de VPN.
Como fazer para criar conexões com o tipo de protocolo IKEv1 ou IKEv2?
Conexões IKEv1 podem ser criadas em todos os SKUs do tipo VPN RouteBased, exceto pelo SKU Básico, SKU Standard e outros SKUs mais antigos.
Você pode especificar o tipo de protocolo de conexão IKEv1 ou IKEv2 ao criar conexões. Se você não especificar um tipo de protocolo de conexão, o IKEv2 será usado como opção padrão quando aplicável. Para obter mais informações, confira a documentação do cmdlet do Azure PowerShell.
Para obter informações sobre tipos de SKU e suporte para IKEv1 e IKEv2, confira Conectar um gateway de VPN a vários dispositivos VPN baseados em política local.
O tráfego entre conexões IKEv1 e IKEv2 é permitido?
Sim.
Posso ter conexões site a site do IKEv1 no SKU Básico para o tipo de VPN baseado em rota?
Não. O SKU Básico não dá suporte a essa configuração.
Posso alterar o tipo de protocolo de conexão após a conexão ser criada (IKEv1 para IKEv2 e vice-versa)?
Não. Depois de criar a conexão, você não poderá alterar os protocolos IKEv1 e IKEv2. Você precisa excluir e recriar uma conexão com o tipo de protocolo desejado.
Por que minha conexão IKEv1 está reconectando com frequência?
Se o roteamento estático ou a conexão IKEv1 baseada em rota estiver desconectando em intervalos de rotina, é provável que os gateways de VPN não deem suporte a rechaveamentos no local. Quando o modo principal estiver sendo rechaveado, os túneis IKEv1 serão desconectados e levarão até cinco segundos para reconectar. O valor de tempo limite de negociação do modo principal determinará a frequência de rechaveamentos. Para evitar essas reconexões, você pode alternar para o uso de IKEv2, que dá suporte a rechaveamentos no local.
Se sua conexão estiver se reconectando aleatoriamente, siga o guia de solução de problemas.
Onde posso encontrar mais informações e etapas de configuração?
Veja os artigos a seguir:
- Configurar políticas de conexão IPsec/IKE personalizadas para VPN S2S e VNet para VNet: portal do Azure
- Configurar políticas de conexão IPsec/IKE personalizadas para VPN S2S e VNet para VNet: PowerShell
Próximas etapas
Consulte Configurar a política de IPsec/IKE para obter as instruções passo a passo sobre a configuração da política de IPsec/IKE personalizada em uma conexão.
Consulte também Conectar vários dispositivos de VPN baseados em políticas para saber mais sobre a opção UsePolicyBasedTrafficSelectors.