Laboratório de Troubleshooting: Design a site-to-site VPN connection, including for high availability
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações relata que a VPN site-to-site entre a filial e o Azure parou de funcionar após uma janela de manutenção na madrugada. O engenheiro de plantão verifica o portal e observa que o status da conexão está como "Not connected". Durante a manutenção, foram realizadas duas atividades: atualização do firmware do dispositivo on-premises e renovação do certificado TLS do servidor web interno da filial.
Ao investigar, o engenheiro coleta o seguinte log do dispositivo on-premises:
[IKEv2] SA negotiation failed
Peer: 52.10.4.1 (Azure VPN Gateway)
Reason: TS_UNACCEPTABLE
Local proposal: 10.1.0.0/24
Remote proposal: 10.2.0.0/24
Phase 1: SUCCESS
Phase 2: FAILED
O engenheiro nota ainda que o IP público do gateway Azure não foi alterado e que o uptime do dispositivo on-premises mostra reinicialização às 02h14.
Qual é a causa raiz da falha?
A) A renovação do certificado TLS corrompeu o repositório de chaves do dispositivo VPN, invalidando a autenticação IKEv2.
B) O firmware atualizado redefinou os seletores de tráfego (traffic selectors) da fase 2 para valores incompatíveis com os configurados no Azure.
C) O dispositivo reiniciou durante a manutenção e perdeu as SAs IKEv2 ativas, exigindo renegociação manual pelo administrador Azure.
D) O IP público do gateway Azure sofreu alteração silenciosa após a manutenção, e o dispositivo local ainda aponta para o endereço antigo.
Cenário 2 — Decisão de Ação
A equipe de redes identificou que a conectividade VPN entre a sede e o Azure falhou completamente porque o único dispositivo VPN on-premises queimou fisicamente. A causa está confirmada. O Azure VPN Gateway está em modo Active-Active com dois IPs públicos provisionados e operacionais. Não há dispositivo reserva disponível no local imediatamente.
A aplicação crítica que depende da VPN atende clientes externos e está com SLA comprometido. O gestor autoriza qualquer ação de emergência que restaure a conectividade em até 30 minutos. A equipe possui acesso administrativo completo ao Azure e ao provedor de Internet da filial.
Qual é a ação correta a tomar neste momento?
A) Reconfigurar o Azure VPN Gateway para o modo Active-Standby, reduzindo os custos enquanto aguarda a chegada do novo hardware.
B) Provisionar uma VM no Azure com papel de Network Virtual Appliance (NVA) como gateway VPN temporário, substituindo o Azure VPN Gateway.
C) Provisionar uma Azure Point-to-Site VPN para os administradores locais como solução de contingência enquanto o hardware é substituído.
D) Provisionar um novo dispositivo VPN virtual na filial (ex.: appliance em nuvem ou VM com papel de roteador VPN) e estabelecer os túneis com os dois IPs públicos do gateway Azure existente.
Cenário 3 — Causa Raiz
Um arquiteto configurou uma solução de VPN site-to-site com BGP habilitado para conectar a filial ao Azure. Após a implantação, as VMs na VNet do Azure conseguem pingar recursos on-premises normalmente. Porém, ao testar a comunicação entre a filial e uma segunda VNet conectada via VNet Peering à VNet principal, os pacotes não chegam ao destino.
O arquiteto verifica as configurações e coleta as seguintes informações:
VNet Principal (hub): 10.0.0.0/16
VNet Secundaria (spoke): 10.1.0.0/16
VNet Peering: hub <-> spoke (configurado e status: Connected)
BGP: habilitado no gateway e na conexao
Rotas anunciadas pela filial via BGP: 192.168.10.0/24
O arquiteto verifica também que o peering entre as duas VNets foi criado há três semanas e funcionava corretamente antes da VPN ser configurada. A assinatura Azure utilizada possui cota suficiente de IPs públicos e o gateway está no SKU VpnGw2.
Qual é a causa raiz do problema?
A) O SKU VpnGw2 não suporta propagação de rotas BGP para VNets conectadas via peering.
B) O VNet Peering entre hub e spoke não está com a opção "Use Remote Gateway" habilitada no lado do spoke, impedindo o uso do gateway da VNet hub.
C) O BGP está anunciando apenas rotas da filial para o Azure, mas não redistribuindo as rotas da VNet secundária de volta para o dispositivo on-premises.
D) A cota de IPs públicos consumida pelo gateway impede a propagação de rotas para VNets adicionais.
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte chamado: "A VPN site-to-site estava funcionando ontem. Hoje de manhã os usuários da filial não conseguem acessar nenhum recurso no Azure. O status da conexão no portal Azure aparece como Connected."
O engenheiro dispõe dos seguintes passos de investigação, apresentados fora de ordem:
- Verificar as rotas efetivas (Effective Routes) da NIC das VMs no Azure para confirmar se a rota para o prefixo on-premises está presente.
- Executar o Connection troubleshoot do Network Watcher entre uma VM Azure e um IP on-premises.
- Confirmar se o status da conexão VPN no portal realmente reflete conectividade de dados, testando com um ping ICMP entre pontos finais.
- Verificar os NSGs (Network Security Groups) aplicados às subnets e NICs das VMs no Azure que os usuários tentam acessar.
- Confirmar se houve alteração recente em tabelas de rotas (UDR) associadas às subnets da VNet.
Qual é a sequência correta de investigação para este cenário?
A) 1 -> 2 -> 3 -> 5 -> 4
B) 3 -> 1 -> 5 -> 4 -> 2
C) 2 -> 4 -> 1 -> 3 -> 5
D) 3 -> 5 -> 1 -> 4 -> 2
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
O log apresenta falha na Phase 2 com a mensagem TS_UNACCEPTABLE, que em IKEv2 significa que os traffic selectors propostos pelo dispositivo local são inaceitáveis para o peer remoto. A Phase 1 foi concluída com sucesso, descartando qualquer problema de autenticação, PSK ou alcançabilidade de IP. Isso elimina diretamente as alternativas A e D.
A reinicialização do dispositivo às 02h14 é uma informação irrelevante para o diagnóstico da causa raiz: após reiniciar, o dispositivo tentou renegociar a SA normalmente, e a Phase 1 foi bem-sucedida, o que confirma que o dispositivo está funcional. O problema está na proposta enviada na Phase 2.
A alternativa C representa o erro de raciocínio mais comum: confundir a perda das SAs existentes (sintoma transitório resolvido automaticamente pelo renegociação) com a causa da falha persistente. Uma renegociação de SA não exige intervenção manual no Azure. Se a causa fosse apenas a perda das SAs, a conexão se restabeleceria sozinha em minutos.
A causa real é que a atualização de firmware redefiniu os traffic selectors da Phase 2 para valores que não correspondem aos prefixos configurados no Azure, resultando em rejeição permanente. A renovação do certificado TLS do servidor web interno é irrelevante e foi incluída propositalmente para desviar o diagnóstico.
Gabarito — Cenário 2
Resposta: D
A causa está confirmada: o dispositivo on-premises foi destruído fisicamente. O Azure VPN Gateway está operacional com dois IPs públicos. O único ponto de falha está no lado on-premises. A restrição crítica é restaurar a conectividade em até 30 minutos.
A alternativa D é a única que resolve o problema dentro da restrição: provisionar um appliance VPN virtual ou uma VM com papel de roteador VPN na filial e conectá-la aos dois IPs existentes do gateway Azure, aproveitando a infraestrutura Azure já provisionada.
A alternativa A não restaura conectividade; apenas altera o modo do gateway, que já está operacional. Isso não resolve o problema on-premises.
A alternativa B é tecnicamente válida em outros contextos, mas criar um NVA no Azure para substituir o gateway Azure existente em 30 minutos é inviável e desnecessário, pois o gateway Azure está funcionando.
A alternativa C resolve o problema de acesso para administradores individuais, mas não restaura a conectividade da aplicação que atende clientes externos, ignorando a restrição de SLA declarada no enunciado.
Gabarito — Cenário 3
Resposta: B
O sintoma é claro: a comunicação funciona entre a filial e a VNet hub, mas falha entre a filial e a VNet spoke conectada por peering. Isso indica que o problema está na propagação das rotas através do peering, não no túnel VPN em si.
Para que uma VNet spoke utilize o gateway de uma VNet hub por meio do peering, duas configurações são necessárias: no lado hub, habilitar "Allow Gateway Transit"; no lado spoke, habilitar "Use Remote Gateway". Sem a segunda opção ativa no spoke, as rotas aprendidas via BGP pelo gateway da hub não são propagadas para a VNet spoke.
A pista no enunciado é que o peering funcionava antes da VPN ser configurada: isso significa que a conectividade dentro do Azure entre hub e spoke estava funcionando, mas a configuração de gateway transit não havia sido necessária até então, e não foi habilitada no momento em que a VPN foi criada.
A alternativa A é falsa; o SKU VpnGw2 suporta propagação de rotas BGP via peering. A alternativa C descreve um problema de roteamento inverso (da Azure para a filial), mas o sintoma descrito é a falha de filial para spoke, não a falta de rotas no dispositivo on-premises. A alternativa D é tecnicamente incoerente; a cota de IPs públicos não afeta propagação de rotas.
Gabarito — Cenário 4
Resposta: B
A sequência correta é: 3 -> 1 -> 5 -> 4 -> 2.
O ponto de partida obrigatório é o passo 3: confirmar com um teste real (ping ICMP) se o status "Connected" no portal corresponde a conectividade de dados efetiva. O portal Azure pode exibir "Connected" mesmo quando a transferência de dados está bloqueada por outros controles, como NSGs ou UDRs. Avançar para qualquer análise antes dessa confirmação é um erro de método.
Com a falha de dados confirmada, o próximo passo é o passo 1: verificar as rotas efetivas da NIC das VMs. Se a rota para o prefixo on-premises não estiver presente, o problema está na camada de roteamento.
O passo 5 vem a seguir: verificar se houve alteração recente em UDRs, que podem sobrescrever rotas aprendidas via BGP e desviar o tráfego para um destino errado ou descartá-lo.
O passo 4 investiga os NSGs, que atuam na camada de filtragem após o roteamento estar correto. Verificar NSGs antes de confirmar o roteamento inverte a lógica de diagnóstico.
Por último, o passo 2 (Connection troubleshoot do Network Watcher) é útil para confirmar e documentar o problema após as hipóteses mais comuns terem sido eliminadas, pois consome tempo e recursos adicionais.
A alternativa mais perigosa é a C, que começa pelo Connection troubleshoot sem antes validar se o problema está na camada de dados ou de controle, desperdiçando tempo crítico.
Árvore de Troubleshooting: Design a site-to-site VPN connection, including for high availability
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro (quase preto) | Sintoma inicial (raiz da arvore) |
| Azul | Pergunta diagnostica |
| Laranja | Validacao ou verificacao intermediaria |
| Vermelho | Causa identificada |
| Verde | Acao recomendada ou resolucao |
Para usar esta arvore diante de um problema real, comece pelo nó raiz e responda cada pergunta com base no que pode ser observado diretamente no portal Azure, nos logs do dispositivo on-premises ou em testes de conectividade. Siga o ramo correspondente à resposta observada até chegar a um nó de causa identificada. A partir da causa, execute a ação recomendada no nó verde correspondente e valide se a conectividade foi restaurada antes de encerrar o chamado.