Laboratório de Troubleshooting: Diagnose and Resolve Virtual Network Gateway Connectivity Issues
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma empresa opera uma conexão VPN Site-to-Site entre a rede on-premises e uma VNet no Azure há seis meses sem problemas. Após uma manutenção programada no firewall on-premises na última sexta-feira, a conexão parou de funcionar. O time de rede confirmou que nenhuma alteração foi feita no lado do Azure. O VPN Gateway usa SKU VpnGw2 e está em modo Active-Passive.
A saída do Network Watcher VPN Diagnostics retornou o seguinte:
Initiating IKEv2 Main Mode...
Sending SA proposal to peer: 52.x.x.x
No response received from peer after 3 retries
IKE negotiation failed: timeout waiting for peer response
Informações adicionais coletadas pelo time:
- O endereço IP público do Local Network Gateway no Azure é
198.51.100.10 - O firewall on-premises foi atualizado para uma versão mais recente do firmware
- O certificado TLS do portal do Azure foi renovado automaticamente nesta semana
- O IP público atribuído ao gateway on-premises continua sendo
198.51.100.10 - UDP 500 e UDP 4500 estão permitidos no NSG da gateway subnet
Qual é a causa raiz da falha observada?
A) O SKU VpnGw2 não suporta IKEv2 após atualizações de firmware em dispositivos de terceiros
B) A atualização de firmware do firewall alterou a policy de IKE Phase 1, tornando-a incompatível com a configuração do gateway do Azure
C) O certificado TLS renovado automaticamente invalidou as credenciais de autenticação do túnel VPN
D) O NSG da gateway subnet passou a bloquear UDP 4500 após a manutenção, impedindo o NAT-T
Cenário 2 — Decisão de Ação
A equipe de operações identificou que a causa de uma falha em uma conexão ExpressRoute é a expiração do certificado de autenticação configurado no peering privado. O ambiente possui as seguintes restrições:
- O circuito ExpressRoute é utilizado por sistemas de pagamento em produção com SLA de 99,95%
- Existe uma conexão VPN Site-to-Site de backup já configurada e testada, atualmente em standby
- A janela de manutenção aprovada para este circuito é sábados entre 02h e 04h
- São 15h de uma quinta-feira
- A renovação do certificado exige entre 20 e 40 minutos e causa interrupção completa do peering
Qual é a ação correta a tomar neste momento?
A) Iniciar imediatamente a renovação do certificado, pois a causa já foi identificada e cada minuto representa risco de falha total
B) Ativar manualmente o failover para a conexão VPN de backup e executar a renovação do certificado dentro da janela de manutenção aprovada
C) Abrir um ticket no provedor de conectividade para que a renovação seja feita sem impacto no lado do Azure
D) Monitorar o circuito até a janela de manutenção sem nenhuma ação preventiva, pois o certificado ainda está ativo
Cenário 3 — Causa Raiz
Uma organização expandiu sua topologia adicionando uma nova Spoke VNet (10.2.0.0/16) conectada via peering a um Hub VNet existente (10.0.0.0/16). O Hub possui um VPN Gateway conectado à rede on-premises (192.168.0.0/16). As configurações de peering foram aplicadas conforme a tabela abaixo:
| Peering | Allow Gateway Transit | Use Remote Gateways | Allow Forwarded Traffic |
|---|---|---|---|
| Hub para Spoke | Habilitado | Desabilitado | Habilitado |
| Spoke para Hub | Desabilitado | Habilitado | Habilitado |
Após a configuração, o time reportou que máquinas na rede on-premises conseguem alcançar recursos no Hub VNet normalmente, mas não conseguem alcançar nenhuma VM no Spoke VNet. Máquinas no Spoke conseguem se comunicar com o Hub sem problemas. O time verificou que os NSGs de todas as subnets do Spoke permitem o tráfego de entrada de 192.168.0.0/16.
O gateway do Azure foi consultado com o comando abaixo e o prefixo 10.2.0.0/16 não aparece nas rotas anunciadas ao peer on-premises:
Get-AzVirtualNetworkGatewayLearnedRoute `
-VirtualNetworkGatewayName "gw-hub" `
-ResourceGroupName "rg-network"
Qual é a causa raiz do problema?
A) O NSG do Hub VNet está bloqueando o tráfego de retorno de 10.2.0.0/16 para 192.168.0.0/16
B) A flag "Use Remote Gateways" no peering Spoke para Hub está habilitada, criando um conflito de roteamento quando o BGP não está ativo
C) A flag "Allow Gateway Transit" no peering Hub para Spoke está habilitada, mas a flag "Use Remote Gateways" no peering Spoke para Hub está desabilitada, impedindo que o gateway aprenda e anuncie o prefixo do Spoke
D) O prefixo 10.2.0.0/16 sobrepõe rotas internas do Hub VNet, causando descarte silencioso dos pacotes
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte relato: "A conexão VPN Site-to-Site foi recriada ontem após uma migração de subscription. Agora o status no portal aparece como 'Connected', mas nenhum tráfego flui entre as redes."
Os seguintes passos de investigação estão disponíveis, fora de ordem:
- Verificar se o PSK configurado no Local Network Gateway do Azure corresponde ao configurado no dispositivo on-premises
- Executar o Network Watcher VPN Diagnostics para capturar logs de negociação IKE
- Confirmar se os prefixos de endereço no Local Network Gateway correspondem exatamente aos prefixos da rede on-premises
- Verificar se há sobreposição de prefixos entre o espaço de endereçamento da VNet e os prefixos declarados no Local Network Gateway
- Analisar as tabelas de rota efetivas nas NICs das VMs de destino para confirmar se a rota para
192.168.x.xestá presente
Qual é a sequência correta de investigação, do mais amplo para o mais específico?
A) 2, 1, 3, 4, 5
B) 4, 3, 1, 2, 5
C) 1, 2, 3, 5, 4
D) 2, 4, 3, 1, 5
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
Explicar:
- O log deixa claro que a negociação IKE falha por timeout: o gateway do Azure envia propostas e não recebe resposta do peer. Isso indica que o dispositivo on-premises está ignorando ou rejeitando as propostas recebidas, o que é o comportamento típico de uma incompatibilidade de policy IKE Phase 1. Após uma atualização de firmware, dispositivos frequentemente redefinem ou alteram os algoritmos padrão de criptografia, integridade e grupo DH, tornando as propostas enviadas pelo Azure inaceitáveis.
- A informação sobre o certificado TLS do portal do Azure é deliberadamente irrelevante: certificados TLS do portal não têm nenhuma relação com a autenticação do túnel VPN, que usa PSK ou certificados de túnel separados. Incluir esse dado simula a pressão real de diagnóstico onde informações recentes, mas sem relação causal, desviam a atenção.
- A alternativa A é incorreta porque o SKU não impõe restrições baseadas em firmware de terceiros. A alternativa D é descartada pelo próprio enunciado, que confirma que UDP 500 e 4500 estão permitidos e que o NSG não foi alterado no lado do Azure. A alternativa C confunde certificados TLS de gerenciamento com credenciais de autenticação VPN.
- Agir com base na alternativa D levaria o time a revisar NSGs desnecessariamente, consumindo tempo enquanto a incompatibilidade de IKE Phase 1 permanece sem diagnóstico.
Gabarito — Cenário 2
Resposta: B
Explicar:
- A causa está identificada e a ação necessária é clara, mas o contexto de restrições determina o caminho correto. São 15h de uma quinta-feira: executar a renovação imediatamente (alternativa A) violaria o SLA do sistema de pagamento e a janela de manutenção aprovada, pois a operação causa interrupção completa de 20 a 40 minutos em produção.
- A ação correta é ativar o failover para a VPN de backup agora, protegendo a continuidade operacional, e executar a renovação dentro da janela aprovada no sábado. Isso respeita simultaneamente o SLA, o processo de gerenciamento de mudanças e a segurança operacional.
- A alternativa C é incorreta porque a expiração de certificado no lado do peering privado do Azure é responsabilidade do time Azure, não do provedor de conectividade. A alternativa D representa o erro mais perigoso: aguardar sem ação preventiva com um certificado expirado ou prestes a expirar em um circuito crítico é aceitar risco de falha total sem controle.
- O distrator mais perigoso é a alternativa A, pois tem urgência técnica aparente. O raciocínio correto exige reconhecer que "causa identificada" não significa "agir imediatamente sem considerar restrições".
Gabarito — Cenário 3
Resposta: C
Explicar:
- A tabela de configuração revela o problema com precisão: no peering Spoke para Hub, a flag "Use Remote Gateways" está desabilitada. Essa flag é o mecanismo pelo qual o Spoke instrui o Azure a utilizar o gateway do Hub para rotear tráfego externo. Sem ela, o Spoke não delega seu roteamento ao gateway, e o gateway nunca aprende o prefixo
10.2.0.0/16como destino alcançável, portanto nunca o anuncia à rede on-premises via BGP ou rotas estáticas. - O resultado do
Get-AzVirtualNetworkGatewayLearnedRouteconfirma diretamente essa hipótese: o prefixo do Spoke simplesmente não existe na tabela de rotas aprendidas pelo gateway. - A informação sobre NSGs do Spoke permitindo
192.168.0.0/16é deliberadamente irrelevante para este diagnóstico: o problema está no plano de controle (roteamento), não no plano de segurança. O tráfego nem chega ao Spoke para ser filtrado pelo NSG. - A alternativa B representa um equívoco comum: "Use Remote Gateways" habilitado no Spoke não cria conflito quando "Allow Gateway Transit" está ativo no Hub; essa é exatamente a combinação correta e necessária. A alternativa D é descartada porque
10.2.0.0/16e10.0.0.0/16são prefixos distintos e não se sobrepõem.
Gabarito — Cenário 4
Resposta: D
Explicar:
- A sequência correta é: 2, 4, 3, 1, 5.
- O ponto de partida sempre deve ser a ferramenta de diagnóstico abrangente (passo 2: Network Watcher VPN Diagnostics), pois os logs de IKE revelam em qual fase a negociação falha e direcionam os próximos passos, evitando verificações cegas.
- Em seguida, verificar sobreposição de prefixos (passo 4) é crítico porque é uma causa de descarte silencioso que não gera erros de IKE: o túnel pode estar "Connected" enquanto o Azure descarta pacotes cujo destino conflita com o espaço de endereçamento da VNet.
- O passo 3 (prefixos do Local Network Gateway) vem a seguir porque prefixos incorretos ou incompletos explicam por que o tráfego para determinados destinos não flui mesmo com o túnel ativo.
- O passo 1 (PSK) é verificado depois porque uma divergência de PSK impediria o próprio estabelecimento do túnel; como o portal mostra "Connected", o PSK provavelmente está correto, mas deve ser confirmado.
- O passo 5 (rotas efetivas nas NICs) é o último por ser o mais granular: só faz sentido investigar a tabela de rotas de uma VM específica após confirmar que o gateway está recebendo e anunciando os prefixos corretamente.
- A alternativa A comete o erro de verificar o PSK antes de confirmar se há sobreposição de prefixos ou prefixos incorretos, pulando causas mais prováveis dado o sintoma. A alternativa B inicia pela sobreposição sem usar os logs de diagnóstico, que poderiam eliminar hipóteses inteiras antes de qualquer verificação manual.
Árvore de Troubleshooting: Diagnose and Resolve Virtual Network Gateway Connectivity Issues
Legenda:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul médio | Pergunta diagnóstica (decisão) |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Verificação intermediária ou validação |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma observado e responda cada pergunta com base no que é verificável no ambiente naquele momento. Siga o caminho que corresponde ao estado real observado, sem pular níveis. Cada ramificação elimina uma classe de causas e estreita o diagnóstico até a causa identificada ou a ação de resolução. Se uma ação de resolução for aplicada e o sintoma persistir, retorne ao nó de verificação intermediária imediatamente acima e siga o caminho alternativo.