Laboratório de Troubleshooting: Create and configure an IPsec/Internet Key Exchange (IKE) policy
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de infraestrutura relata que um túnel VPN Site-to-Site entre o Azure e um firewall corporativo foi estabelecido com sucesso por meses. Após uma janela de manutenção na sexta-feira, o túnel parou de subir. Nenhuma alteração foi feita no Azure VPN Gateway. O time de redes informa que o certificado TLS do portal de gerenciamento do firewall foi renovado durante a manutenção e que o firmware do dispositivo foi atualizado para a versão mais recente.
Ao verificar os logs do Azure VPN Gateway, a equipe observa a seguinte mensagem repetida:
IKE SA MM: FAILED - No proposal match found
Phase 1 negotiation failed
Local policy: AES256-SHA256-DHGroup14
Remote proposal received: AES128-SHA1-DHGroup2
O gateway Azure está configurado com uma política IPsec/IKE personalizada. A política no firewall on-premises também usa configuração personalizada. O SKU do gateway é VpnGw2 e está operacional. O endereço IP público do gateway não mudou.
Qual é a causa raiz da falha no estabelecimento do túnel?
A) A renovação do certificado TLS do portal do firewall alterou as credenciais de autenticação usadas na fase 1 do IKE, invalidando a SA existente.
B) A atualização de firmware do firewall redefiniu a política IPsec/IKE customizada do dispositivo para os valores padrão do fabricante, que são incompatíveis com a política configurada no Azure.
C) O SKU VpnGw2 não suporta políticas IPsec/IKE personalizadas após atualizações de firmware em dispositivos remotos, exigindo recriação do gateway.
D) A política personalizada no Azure expirou após a janela de manutenção, pois políticas customizadas têm validade limitada vinculada ao tempo de vida da SA ativa.
Cenário 2 — Decisão de Ação
A causa de uma falha em um túnel VPN Site-to-Site já foi identificada: a política IPsec/IKE configurada no Azure especifica PfsGroup PFS24 (ECP384), mas o dispositivo on-premises é um appliance legado que suporta apenas PFS2 e PFS14. A conexão está em produção e suporta integração com um sistema de pagamentos que opera 24 horas por dia. A equipe tem aprovação para realizar mudanças apenas em janelas de manutenção agendadas, que ocorrem aos domingos entre 02h e 04h. Hoje é quinta-feira e a janela mais próxima disponível é em 10 dias.
A equipe dispõe das seguintes opções:
- Atualizar a política IPsec/IKE no Azure agora, fora da janela
- Aguardar a janela de manutenção e atualizar a política para
PFS14 - Criar uma segunda conexão VPN com política compatível e redirecionar o tráfego
- Remover a política personalizada agora para restaurar o comportamento padrão
Qual é a ação correta a tomar neste momento?
A) Atualizar a política IPsec/IKE da conexão imediatamente, substituindo PFS24 por PFS14, pois a causa já foi identificada e o impacto atual é maior do que o risco da mudança.
B) Aguardar a janela de manutenção em 10 dias e aplicar a correção com PFS14, respeitando o processo de controle de mudanças estabelecido.
C) Remover a política personalizada da conexão agora, fora da janela, para restaurar a política padrão do Azure e permitir que o túnel negocie automaticamente com o dispositivo legado.
D) Criar uma nova conexão VPN paralela com a política corrigida e redirecionar o tráfego para ela antes de remover a conexão com problema, executando tudo dentro da próxima janela de manutenção.
Cenário 3 — Causa Raiz
Um engenheiro está implantando uma nova conexão VPN Site-to-Site com política IPsec/IKE personalizada. O Local Network Gateway e o Azure VPN Gateway foram criados corretamente. A conexão foi provisionada e aparece com status Connected no portal Azure. No entanto, nenhum tráfego passa pelo túnel. Pings de máquinas virtuais na VNet Azure para hosts na rede on-premises falham completamente.
O engenheiro verifica e confirma:
- O dispositivo VPN on-premises está online e sem alertas
- A rota para o prefixo da VNet Azure existe na tabela de roteamento do firewall
- Não há alertas de saúde no Azure VPN Gateway
- O status da conexão é Connected
A política configurada no Azure é:
$policy = New-AzIpsecPolicy `
-IkeEncryption AES256 `
-IkeIntegrity SHA384 `
-DhGroup DHGroup24 `
-IpsecEncryption AES256 `
-IpsecIntegrity SHA256 `
-PfsGroup PFS24 `
-SALifeTimeSeconds 27000 `
-SADataSizeKilobytes 102400000
O dispositivo on-premises está configurado com os mesmos parâmetros de fase 1 e fase 2. O grupo de segurança de rede associado à subnet das VMs permite todo o tráfego de saída. A subnet do GatewaySubnet não tem NSG associado.
Ao capturar pacotes no dispositivo on-premises, o engenheiro observa que os pacotes IPsec chegam corretamente ao firewall, mas nenhum pacote retorna em direção ao Azure.
Qual é a causa raiz do problema?
A) O valor SADataSizeKilobytes 102400000 está acima do limite suportado pelo Azure para políticas personalizadas, causando descarte silencioso dos pacotes na fase 2.
B) A política personalizada no Azure está correta, mas os prefixos de rede configurados no Local Network Gateway não incluem os endereços dos hosts on-premises que precisam ser alcançados, impedindo o tráfego de retorno de ser encapsulado corretamente pelo dispositivo remoto.
C) O status Connected indica apenas que a fase 1 foi concluída; a fase 2 falhou silenciosamente devido à incompatibilidade de PfsGroup PFS24 com o dispositivo remoto.
D) O grupo de segurança de rede na subnet das VMs está bloqueando o tráfego de retorno, mesmo que permita saída, pois regras de entrada para respostas IPsec não foram configuradas.
Cenário 4 — Sequência de Diagnóstico
Um túnel VPN Site-to-Site com política IPsec/IKE personalizada apresenta falha intermitente: o túnel cai e sobe sozinho a cada poucas horas, sem intervenção. O ambiente usa Azure VPN Gateway com SKU VpnGw1 e uma conexão com política customizada aplicada.
Os passos de investigação disponíveis são:
- Passo P: Comparar o valor de
SALifeTimeSecondsconfigurado na política Azure com o tempo de vida configurado no dispositivo on-premises - Passo Q: Verificar os logs do Azure VPN Gateway em busca de mensagens de renegociação de SA ou falha de rekey
- Passo R: Confirmar se o SKU VpnGw1 suporta a quantidade de conexões ativas no gateway
- Passo S: Verificar se o dispositivo on-premises inicia a renegociação ou se é o Azure que inicia, e se ambos os lados aceitam a proposta durante o rekey
- Passo T: Revisar se a política personalizada especifica um
SADataSizeKilobytesmuito baixo que provoca rekey frequente por esgotamento de volume
Qual é a sequência correta de investigação para este sintoma?
A) R, Q, P, S, T
B) Q, P, T, S, R
C) P, R, T, Q, S
D) T, P, R, Q, S
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está na mensagem de log: o Azure está propondo AES256-SHA256-DHGroup14, exatamente o que foi configurado na política personalizada, e o dispositivo remoto está enviando AES128-SHA1-DHGroup2. Essa divergência indica que o dispositivo on-premises passou a usar parâmetros diferentes dos que estavam configurados antes da manutenção.
A atualização de firmware é a causa real: muitos fabricantes redefinem configurações personalizadas para valores padrão de fábrica durante atualizações de firmware, especialmente quando há mudanças no esquema de configuração entre versões. O resultado visível é exatamente o observado: a proposta enviada pelo dispositivo remoto muda para os padrões do fabricante.
A renovação do certificado TLS do portal de gerenciamento não tem relação com as credenciais de autenticação IKE; são planos completamente diferentes. Esse detalhe foi incluído propositalmente como informação irrelevante para testar se o leitor associaria incorretamente certificado de gerenciamento com autenticação de túnel. O SKU VpnGw2 não tem qualquer limitação relacionada a atualizações de firmware de dispositivos remotos. Políticas personalizadas no Azure não expiram por tempo; elas persistem enquanto a conexão existir.
O distrator mais perigoso é a alternativa A: um diagnóstico equivocado levaria a equipe a investigar autenticação e certificados IKE, perdendo tempo enquanto a causa real é a política de fase 1 redefinida no firewall.
Gabarito — Cenário 2
Resposta: D
O contexto estabelece restrições explícitas: o sistema é de pagamentos em produção 24 horas e mudanças só são permitidas em janelas agendadas. A causa já foi identificada e a solução é conhecida. O critério de decisão não é técnico; é operacional.
A alternativa D é a correta porque cria a nova conexão com a política corrigida e só realiza o corte dentro da janela de manutenção, respeitando todas as restrições. Isso minimiza o risco ao tráfego de produção e mantém conformidade com o processo de mudanças.
A alternativa A ignora a restrição de janela de manutenção para um sistema crítico. Mesmo que tecnicamente válida, agir fora da janela em um sistema de pagamentos viola o controle de mudanças e pode causar indisponibilidade não planejada durante a reconfiguração. A alternativa B aguarda 10 dias sem oferecer alternativa funcional, o que significa que o túnel permanece inoperante por todo esse período. A alternativa C remove a política personalizada fora da janela, o que também viola o processo e pode introduzir comportamento inesperado em um sistema de pagamentos.
Gabarito — Cenário 3
Resposta: B
A pista crítica está na captura de pacotes: os pacotes IPsec chegam corretamente ao dispositivo on-premises, mas nenhum pacote retorna em direção ao Azure. Isso significa que a fase 1 e a fase 2 foram estabelecidas com sucesso (o túnel está Connected e os pacotes chegam ao destino), mas o dispositivo on-premises não está encapsulando o tráfego de retorno para enviá-lo ao Azure.
O comportamento descrito indica que o firewall on-premises recebe os pacotes, os decapsula corretamente, mas ao tentar responder, não encontra uma SA IPsec ativa para o destino (os endereços IP das VMs Azure). Isso ocorre quando os prefixos configurados no Local Network Gateway no Azure não cobrem corretamente os endereços de origem on-premises que precisam devolver tráfego. O dispositivo on-premises encapsula tráfego de retorno com base nos seletores de tráfego negociados na fase 2, que derivam dos prefixos do Local Network Gateway.
O valor SADataSizeKilobytes 102400000 é válido no Azure. O status Connected confirma que tanto a fase 1 quanto a fase 2 foram estabelecidas, descartando a alternativa C. O NSG da subnet não bloqueia tráfego de retorno IPsec, pois o tráfego encapsulado chega ao gateway, não diretamente às VMs. A informação sobre a ausência de NSG no GatewaySubnet é irrelevante para este diagnóstico e foi incluída propositalmente para distrair.
Gabarito — Cenário 4
Resposta: B
A sequência correta é: Q, P, T, S, R.
O raciocínio diagnóstico progressivo para falha intermitente com reconexão periódica deve seguir do geral para o específico:
- Q primeiro: os logs do gateway mostram o que está acontecendo no momento da queda; se há renegociação ou erro de rekey, isso confirma que o problema está no ciclo de vida da SA.
- P em seguida: com o padrão confirmado nos logs, compara-se o
SALifeTimeSecondsnos dois lados. Assimetria de lifetime é a causa mais comum de reconexões periódicas com políticas personalizadas. - T na sequência: se os lifetimes em segundos coincidirem, verifica-se o limite por volume (
SADataSizeKilobytes), que pode forçar rekey antes do tempo se estiver muito baixo para o volume de tráfego. - S depois: identifica qual lado inicia o rekey e se a proposta é aceita; isso revela se há incompatibilidade durante a renegociação.
- R por último: a capacidade do SKU é a hipótese menos provável para este sintoma específico e deve ser verificada apenas após esgotadas as causas relacionadas à política.
A sequência A começa pela capacidade do SKU, que é improvável para o sintoma descrito. As sequências C e D iniciam por parâmetros específicos sem antes observar o que os logs revelam, invertendo a lógica de diagnóstico progressivo.
Árvore de Troubleshooting: Create and configure an IPsec/IKE policy
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (decisão binária ou observável) |
| Vermelho | Causa identificada ou ação corretiva |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz e responda cada pergunta com base no que você observa no ambiente, sem presumir a causa. Siga o caminho que corresponde ao estado observado, não ao estado esperado. Ao chegar a um nó vermelho, você tem a causa ou a ação corretiva; ao chegar a um nó laranja, execute a validação antes de considerar o problema resolvido. Se a validação falhar, retorne ao nó de pergunta imediatamente anterior e reavalie a resposta dada.