Laboratório de Troubleshooting: Implement a site-to-site VPN connection
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações relata que a conexão site-to-site VPN entre o data center principal e a VNet do Azure ficou inativa após uma manutenção realizada na madrugada. O engenheiro de plantão verifica o portal do Azure e observa o status "Not Connected" na conexão. O túnel não se reestabelece automaticamente após 40 minutos.
Durante a investigação, o engenheiro coleta as seguintes informações:
Virtual Network Gateway
SKU: VpnGw2
VPN Type: Route-Based
BGP: Disabled
Active-Active: Disabled
Local Network Gateway
IP Address: 198.51.100.45
Address Space: 172.16.0.0/12
Connection
Shared Key (PSK): Az700Lab#2024
Status: Not Connected
Last connected: 03/26/2026 02:14 UTC
O engenheiro confirma com a equipe de infraestrutura on-premises que, durante a manutenção, o firewall de borda foi substituído por um novo appliance. O novo equipamento está online e responde a pings na rede interna. O SKU do gateway não foi alterado. O certificado TLS do portal do Azure foi renovado na mesma noite.
Qual é a causa raiz da falha na conexão VPN?
A) A renovação do certificado TLS do portal do Azure corrompeu a configuração da conexão existente.
B) O novo appliance de firewall assumiu um IP público diferente do que estava configurado no Local Network Gateway.
C) A desativação do BGP impediu o regate automático do túnel após a interrupção.
D) O SKU VpnGw2 perdeu o estado da conexão por restart do gateway durante a janela de manutenção do Azure.
Cenário 2 — Decisão de Ação
A equipe de redes identificou que a conexão site-to-site VPN de uma filial está inativa porque o Shared Key (PSK) configurado no dispositivo VPN on-premises não corresponde ao PSK registrado no Azure. A causa está confirmada por log do dispositivo VPN local.
O contexto operacional é o seguinte:
- A conexão é a única via de acesso da filial aos sistemas ERP hospedados na VNet do Azure
- São 14h30 de uma sexta-feira e o ERP está em uso ativo por 37 usuários da filial
- A alteração do PSK no Azure requer que a conexão seja derrubada e reestabelecida, causando interrupção de aproximadamente 3 a 5 minutos
- A equipe local da filial tem acesso ao painel do dispositivo VPN e pode aplicar a alteração no lado on-premises imediatamente
- Existe uma janela de manutenção programada para domingo às 02h00
Qual é a ação correta a tomar neste momento?
A) Corrigir o PSK imediatamente no Azure e solicitar à equipe da filial que atualize o dispositivo VPN em paralelo, aceitando a interrupção de 3 a 5 minutos.
B) Aguardar a janela de manutenção de domingo para corrigir o PSK, pois a interrupção durante horário de produção impactará os 37 usuários ativos.
C) Solicitar à equipe da filial que corrija apenas o lado on-premises para tentar reestabelecer a conexão sem alterar o Azure.
D) Criar uma nova conexão VPN com o PSK correto em paralelo e remover a conexão antiga após a sincronização.
Cenário 3 — Causa Raiz
Um engenheiro recebe um chamado relatando que VMs na VNet do Azure conseguem pingar servidores on-premises, mas conexões TCP na porta 1433 para o servidor de banco de dados on-premises falham consistentemente. O engenheiro verifica o status da conexão VPN no portal:
Connection Status: Connected
Data In: 142.7 MB
Data Out: 98.3 MB
O engenheiro então executa um teste de conectividade a partir de uma VM na VNet:
# Teste ICMP
ping 10.20.5.10
# Resultado: 4 pacotes enviados, 4 recebidos, 0% perda
# Teste TCP
Test-NetConnection -ComputerName 10.20.5.10 -Port 1433
# TcpTestSucceeded : False
# PingSucceeded : True
O engenheiro verifica que o NSG associado à subnet das VMs no Azure não possui regras bloqueando saída para a porta 1433. O servidor de banco de dados on-premises está em execução e aceita conexões de outros hosts na mesma rede local. O gateway VPN foi provisionado há 6 meses sem alterações.
Qual é a causa raiz da falha nas conexões TCP na porta 1433?
A) O NSG da subnet das VMs no Azure está bloqueando o tráfego de saída para a porta 1433, mas a regra não aparece no portal por delay de propagação.
B) O firewall ou ACL no lado on-premises está bloqueando conexões TCP na porta 1433 originadas do range de IP da VNet do Azure.
C) O túnel VPN não suporta tráfego TCP em portas acima de 1024 sem configuração adicional de política.
D) O gateway VPN está operando em modo Policy-Based, que restringe os protocolos permitidos pelo túnel.
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte relato: a conexão site-to-site VPN está com status "Connected" no portal do Azure, mas nenhum tráfego de aplicação flui entre a rede on-premises e as VMs na VNet. O problema começou após uma reconfiguração de endereçamento IP realizada na filial.
Os seguintes passos de investigação estão disponíveis, fora de ordem:
- Verificar se o espaço de endereços do Local Network Gateway reflete os novos ranges de IP da rede on-premises
- Confirmar que o status da conexão no portal do Azure é "Connected"
- Executar um teste de ping de uma VM no Azure para um host on-premises usando o novo IP
- Verificar se as rotas efetivas na NIC das VMs incluem os prefixos da rede on-premises
- Confirmar com a equipe da filial quais ranges de IP foram alterados e quais são os novos valores
Qual é a sequência correta de investigação para esse cenário?
A) 2 -> 1 -> 5 -> 4 -> 3
B) 2 -> 5 -> 1 -> 4 -> 3
C) 5 -> 2 -> 1 -> 3 -> 4
D) 1 -> 5 -> 2 -> 4 -> 3
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista determinante no enunciado é a substituição do appliance de firewall on-premises. Dispositivos de borda frequentemente obtêm um novo IP público ao serem substituídos, seja por configuração manual diferente ou por nova concessão do provedor de internet. O Local Network Gateway no Azure armazena o IP público do dispositivo VPN on-premises como referência fixa. Se esse IP mudou e o Local Network Gateway não foi atualizado, o Azure tentará estabelecer o túnel IKE para um endpoint inexistente ou incorreto, resultando em status "Not Connected" permanente.
A informação sobre renovação do certificado TLS do portal é deliberadamente irrelevante: certificados TLS do portal não têm qualquer relação com o plano de dados da VPN. O BGP desativado e o SKU do gateway também são irrelevantes, pois nenhum desses fatores sofreu alteração e nenhum causa falha de túnel por si só nesse contexto.
O distrator mais perigoso é a alternativa D, pois reinicializações de gateway são eventos reais, mas o Azure reestabelece conexões automaticamente após restarts e o enunciado descreve uma falha persistente de 40 minutos com causa operacional clara no lado on-premises.
Gabarito — Cenário 2
Resposta: B
A causa está confirmada e a solução técnica é conhecida. O que determina a resposta correta são as restrições do cenário: 37 usuários ativos em sistema ERP crítico em horário de produção, com uma janela de manutenção programada disponível em menos de 48 horas.
A interrupção de 3 a 5 minutos em um ERP em uso ativo pode causar perda de transações em andamento, corrompimento de dados não confirmados e impacto direto ao negócio. A janela de domingo às 02h00 existe exatamente para absorver esse tipo de intervenção.
A alternativa C representa o equívoco mais comum: alterar apenas o lado on-premises não resolve o problema porque o PSK é comparado bilateralmente durante o handshake IKE. Se os dois lados não concordam, o túnel não sobe, independentemente de qual lado foi corrigido.
A alternativa D é tecnicamente inviável nesse contexto: não é possível ter duas conexões ativas simultaneamente para o mesmo endpoint on-premises no mesmo gateway sem configuração específica, e o processo não eliminaria a interrupção.
Gabarito — Cenário 3
Resposta: B
O conjunto de evidências aponta diretamente para uma regra de firewall ou ACL no lado on-premises. O raciocínio de eliminação é o seguinte: o túnel VPN está ativo e transportando dados (evidenciado pelo Data In/Out), ICMP funciona em ambas as direções, e o NSG no Azure foi verificado e não bloqueia a porta 1433 na saída. O servidor de banco de dados está operacional e aceita conexões locais.
O único elemento não verificado explicitamente é o firewall on-premises. É comum que firewalls on-premises permitam tráfego entre hosts internos mas bloqueiem conexões originadas de ranges externos, mesmo que esses ranges cheguem pelo túnel VPN. Para o firewall on-premises, o tráfego vindo do Azure aparece com IPs do range da VNet, que podem não estar na lista de origens permitidas para a porta 1433.
A alternativa A está descartada pelo próprio enunciado: o NSG foi verificado sem regras de bloqueio. A alternativa C é tecnicamente incorreta: túneis VPN no Azure são transparentes ao protocolo de camada 4 e não impõem restrições por porta. A alternativa D está descartada porque o gateway Route-Based não restringe protocolos pelo túnel.
Gabarito — Cenário 4
Resposta: B
A sequência correta segue a lógica de diagnóstico progressivo: partir do estado atual observável, coletar a informação de referência, comparar configuração com realidade, verificar propagação e validar com teste funcional.
O passo 2 vem primeiro porque confirma que o túnel em si está ativo, separando o problema de conectividade de aplicação de um possível problema de VPN em si. O passo 5 vem em seguida porque sem saber os novos ranges reais não é possível avaliar se qualquer configuração está correta. O passo 1 compara o Local Network Gateway com os valores obtidos no passo 5. O passo 4 verifica se as rotas efetivas nas VMs refletem os prefixos corretos. O passo 3 é o teste funcional final, executado apenas após confirmar que a configuração está correta.
A alternativa A erra ao colocar a verificação do Local Network Gateway antes de confirmar os novos ranges com a equipe da filial, o que pode levar o engenheiro a validar incorretamente uma configuração com base em informação desatualizada. A alternativa D erra ao começar pelo Local Network Gateway sem primeiro confirmar o estado da conexão e os valores reais dos novos IPs.
Árvore de Troubleshooting: Implement a site-to-site VPN connection
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica |
| Laranja | Verificação ou validação intermediária |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
Diante de um problema real, inicie pelo nó raiz e responda cada pergunta com base no que é diretamente observável: status no portal, testes de conectividade, confirmações com a equipe on-premises. A cada bifurcação, escolha apenas o caminho sustentado por evidência coletada, não por suposição. Nós de validação intermediária indicam que é necessário coletar mais informação antes de avançar para uma causa. Chegando a um nó de causa identificada, a ação recomendada correspondente resolve especificamente aquela causa, sem efeitos colaterais sobre outras partes da configuração.