Laboratório Técnico: Create and configure an IPsec/Internet Key Exchange (IKE) policy
Questões
Questão 1 — Múltipla Escolha
Um arquiteto de redes precisa estabelecer um túnel VPN Site-to-Site entre o Azure e um dispositivo on-premises legado que suporta apenas IKEv1. Ao configurar a política IPsec/IKE no Azure, qual afirmação descreve corretamente o comportamento esperado?
A) O Azure negocia automaticamente entre IKEv1 e IKEv2 com base na oferta do dispositivo remoto, sem necessidade de configuração explícita.
B) Uma política IPsec/IKE personalizada aplicada a uma conexão VPN permite especificar IKEv1, mas apenas em gateways com SKU VpnGw1 ou superior.
C) O Azure suporta IKEv1 em conexões Site-to-Site com gateways baseados em rota, mas não em gateways baseados em política.
D) Para usar IKEv1, é necessário deixar a política IPsec/IKE como padrão, pois políticas personalizadas no Azure exigem obrigatoriamente IKEv2.
Questão 2 — Cenário Técnico
Uma equipe configura uma conexão VPN Site-to-Site com política IPsec/IKE personalizada. Após aplicar a configuração abaixo via PowerShell, o túnel não estabelece conectividade com o dispositivo on-premises:
$ipsecPolicy = New-AzIpsecPolicy `
-IkeEncryption AES256 `
-IkeIntegrity SHA256 `
-DhGroup DHGroup14 `
-IpsecEncryption AES256 `
-IpsecIntegrity SHA256 `
-PfsGroup PFS2048 `
-SALifeTimeSeconds 3600 `
-SADataSizeKilobytes 0
O dispositivo on-premises está configurado com SA lifetime de 3600 segundos e PFS Group 2. O que mais provavelmente impede o estabelecimento do túnel?
A) O valor SADataSizeKilobytes 0 desativa o limite por volume, o que não é suportado pelo Azure em políticas personalizadas.
B) O PfsGroup PFS2048 no Azure não corresponde ao PFS Group 2 configurado no dispositivo remoto, causando falha na negociação da fase 2.
C) O parâmetro DhGroup DHGroup14 é incompatível com IkeEncryption AES256 em políticas IKEv2 personalizadas.
D) A combinação de IkeIntegrity SHA256 com IpsecIntegrity SHA256 não é permitida em uma única política IPsec/IKE no Azure.
Questão 3 — Verdadeiro ou Falso
Uma política IPsec/IKE personalizada aplicada a uma conexão de VPN Gateway no Azure substitui completamente a política padrão e impede que o gateway utilize qualquer outra combinação de algoritmos durante a negociação, mesmo que o dispositivo remoto ofereça propostas adicionais.
( ) Verdadeiro ( ) Falso
Questão 4 — Cenário Técnico
Uma organização precisa que sua conexão VPN Site-to-Site atenda a requisitos de conformidade que exigem Perfect Forward Secrecy (PFS) obrigatório e o uso de curvas elípticas para troca de chaves na fase 2. Ao revisar a configuração atual, o engenheiro identifica o seguinte trecho:
$ipsecPolicy = New-AzIpsecPolicy `
-IkeEncryption GCMAES256 `
-IkeIntegrity GCMAES256 `
-DhGroup ECP384 `
-IpsecEncryption GCMAES256 `
-IpsecIntegrity GCMAES256 `
-PfsGroup None `
-SALifeTimeSeconds 27000
Qual é o problema desta configuração em relação ao requisito de conformidade?
A) O uso de GCMAES256 tanto para criptografia quanto para integridade é redundante e inválido em políticas IPsec/IKE do Azure.
B) O PfsGroup None desativa o PFS na fase 2, violando diretamente o requisito de Perfect Forward Secrecy obrigatório.
C) O DhGroup ECP384 não é compatível com IpsecEncryption GCMAES256, tornando a política inválida no Azure.
D) O valor SALifeTimeSeconds 27000 está fora do intervalo permitido para políticas que utilizam algoritmos GCMAES.
Questão 5 — Múltipla Escolha
Ao comparar o comportamento de políticas IPsec/IKE padrão com políticas IPsec/IKE personalizadas no Azure VPN Gateway, qual das afirmações abaixo é tecnicamente correta?
A) A política padrão do Azure VPN Gateway utiliza um conjunto fixo e único de algoritmos para todas as conexões, sem suporte a negociação dinâmica com o dispositivo remoto.
B) Uma política personalizada pode ser aplicada simultaneamente a múltiplas conexões de um mesmo gateway, desde que todas as conexões sejam do tipo Site-to-Site.
C) A política personalizada se aplica apenas à conexão específica à qual é associada; as demais conexões do mesmo gateway continuam usando a política padrão ou suas próprias políticas.
D) Políticas personalizadas só podem ser criadas e associadas a conexões durante a criação inicial do gateway; não é possível modificá-las após o gateway estar ativo.
Gabarito e Explicações
Gabarito — Questão 1
Resposta: A
O Azure VPN Gateway suporta tanto IKEv1 quanto IKEv2 em conexões Site-to-Site com gateways baseados em rota. Quando nenhuma política personalizada é aplicada, o gateway utiliza a política padrão e negocia automaticamente a versão do IKE com base na proposta enviada pelo dispositivo remoto. Isso significa que IKEv1 é aceito sem configuração explícita, desde que o gateway seja baseado em rota.
O principal equívoco representado pelos distratores é associar o suporte a IKEv1 a restrições de SKU ou à obrigatoriedade de políticas personalizadas. Na realidade, políticas personalizadas no Azure exigem que se especifique a versão do IKE, mas a ausência de política personalizada não bloqueia IKEv1. Gateways baseados em política, por sua vez, têm restrições próprias que não se aplicam aqui.
Gabarito — Questão 2
Resposta: B
O ponto crítico é o mapeamento correto entre os grupos PFS. No Azure, PFS2048 corresponde ao Group 14 do padrão MODP, enquanto o PFS Group 2 do dispositivo on-premises corresponde ao grupo MODP 1024, representado no Azure como PFS2. Como os grupos são diferentes, a negociação da fase 2 (Quick Mode no IKEv1 / Child SA no IKEv2) falha por ausência de proposta compatível.
O valor SADataSizeKilobytes 0 é válido no Azure e indica que o limite por volume está desativado. A combinação de DhGroup DHGroup14 com AES256 é suportada, e usar o mesmo algoritmo de integridade nas duas fases é permitido. O erro está exclusivamente no grupo PFS incompatível entre os dois lados do túnel.
Gabarito — Questão 3
Resposta: Verdadeiro
Quando uma política IPsec/IKE personalizada é aplicada a uma conexão, o Azure envia ao dispositivo remoto exatamente e somente os algoritmos e parâmetros definidos nessa política. Não há negociação adicional com outras combinações. O dispositivo remoto precisa aceitar exatamente aquela proposta; caso contrário, o túnel não é estabelecido.
Esse comportamento é diferente da política padrão, que envia múltiplas propostas durante a negociação. A política personalizada é, por design, restritiva: ela garante conformidade com um conjunto exato de algoritmos, mas exige que ambos os lados estejam precisamente alinhados. Entender essa distinção é fundamental para diagnosticar falhas de túnel após customizações.
Gabarito — Questão 4
Resposta: B
O PfsGroup None explicitamente desativa o Perfect Forward Secrecy na fase 2 da negociação IPsec. Mesmo que a fase 1 (IKE) utilize ECP384 para troca de chaves e algoritmos robustos como GCMAES256, a ausência de PFS na fase 2 significa que as chaves de sessão derivam da mesma material keying da fase 1. Se essa chave for comprometida no futuro, todas as sessões passadas podem ser decifradas, violando diretamente o requisito de conformidade.
O uso de GCMAES256 tanto para criptografia quanto para integridade é válido no Azure, pois algoritmos AEAD como GCM incorporam autenticação internamente. O DhGroup ECP384 é compatível com GCMAES256, e o SALifeTimeSeconds 27000 está dentro do intervalo suportado pelo Azure.
Gabarito — Questão 5
Resposta: C
No Azure VPN Gateway, uma política IPsec/IKE personalizada tem escopo de conexão individual. Isso significa que ela é associada a uma conexão específica e não afeta as demais conexões do mesmo gateway. Cada conexão pode ter sua própria política personalizada ou usar a política padrão do gateway independentemente.
A política padrão, ao contrário do que a alternativa A sugere, envia múltiplas propostas de algoritmos durante a negociação, não um conjunto fixo único. A alternativa B está incorreta porque não há limitação que impeça aplicar políticas a múltiplas conexões, mas cada associação é individual por conexão, não uma configuração em lote. A alternativa D está incorreta pois políticas personalizadas podem ser criadas, modificadas e associadas a conexões existentes a qualquer momento via portal, PowerShell ou CLI.