Laboratório de Troubleshooting: Create and configure a local network gateway
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Um engenheiro de redes relata que a conexão VPN Site-to-Site entre o Azure e a filial de São Paulo foi estabelecida com sucesso há três semanas e operava normalmente. Após uma manutenção realizada pela operadora de telecomunicações no último fim de semana, a conexão passou a exibir o status Connected no portal do Azure, mas o tráfego entre as VMs na VNet Azure e os servidores on-premises não flui mais em nenhuma direção.
Durante a investigação, o engenheiro coleta as seguintes informações:
Virtual Network Gateway:
SKU: VpnGw1
Gateway type: Vpn
VPN type: Route-based
Status: Running
Connection:
Status: Connected
Shared Key: (configurada e não alterada)
IKE Protocol: IKEv2
Local Network Gateway:
IP address: 177.23.45.10
Address space: 10.50.0.0/16
Dispositivo VPN on-premises (após manutenção da operadora):
IP público atual: 177.23.45.88
Prefixo gerenciado: 10.50.0.0/16
O engenheiro também verifica que o firewall on-premises não foi alterado durante a manutenção e que a regra de permissão para IKE (UDP 500 e 4500) continua ativa.
Qual é a causa raiz do problema?
A) A SKU VpnGw1 não suporta reconexão automática após mudança de IP do peer remoto, sendo necessário fazer upgrade para VpnGw2.
B) O endereço IP público registrado no local network gateway não corresponde ao IP público atual do dispositivo VPN on-premises após a manutenção da operadora.
C) O protocolo IKEv2 perdeu compatibilidade com o dispositivo on-premises após a manutenção, e a conexão deve ser reconfigurada para IKEv1.
D) A shared key foi invalidada pelo Azure após o período de inatividade durante a manutenção da operadora.
Cenário 2 — Decisão de Ação
A equipe de infraestrutura identificou que o local network gateway de uma conexão VPN Site-to-Site em produção está configurado com o prefixo 172.16.0.0/12, que representa toda a faixa de endereçamento privado RFC 1918 utilizada por aquela empresa. Isso foi feito originalmente para simplificar a configuração.
Recentemente, a empresa criou um novo ambiente de desenvolvimento no Azure com a VNet 172.20.0.0/16. As VMs nessa VNet não conseguem se comunicar com outros recursos na mesma VNet quando o gateway VPN está ativo na VNet de produção.
A causa foi confirmada: o prefixo 172.16.0.0/12 configurado no local network gateway abrange o range 172.20.0.0/16, fazendo com que o Azure roteie o tráfego destinado à nova VNet pelo túnel VPN em vez de mantê-lo local.
A conexão VPN de produção não pode ser interrompida. A equipe tem permissão para editar recursos de rede, mas não pode causar downtime na aplicação que depende da VPN.
Qual é a ação correta a tomar neste momento?
A) Excluir o local network gateway atual e recriar com os prefixos corretos e específicos, já que prefixos genéricos não podem ser substituídos por prefixos específicos em um recurso existente.
B) Adicionar um peering entre a VNet de produção e a VNet de desenvolvimento para contornar o problema de roteamento sem alterar o local network gateway.
C) Editar o address space do local network gateway existente, substituindo 172.16.0.0/12 pelos prefixos específicos reais da rede on-premises, sem recriar o recurso ou a conexão.
D) Criar uma UDR (User Defined Route) na subnet da VNet de desenvolvimento apontando 172.20.0.0/16 para o Internet next hop, forçando o tráfego a ignorar o gateway VPN.
Cenário 3 — Causa Raiz
Um administrador configura uma nova conexão VPN Site-to-Site com BGP habilitado. Ele cria o local network gateway com as seguintes configurações:
Local Network Gateway:
Name: lng-filial-rj
IP address: 200.100.50.25
Address space: 10.100.0.0/24
BGP settings:
ASN: 65001
BGP peer IP address: 10.100.0.1
O virtual network gateway foi criado com ASN 65515. A conexão é estabelecida e o status exibe Connected. No entanto, as rotas da rede on-premises não aparecem na tabela de rotas efetivas das VMs na VNet Azure, mesmo após aguardar 15 minutos.
O administrador verifica que o dispositivo VPN on-premises está anunciando os prefixos corretamente via BGP e que o túnel IPsec está ativo. A shared key está correta em ambos os lados. O SKU do virtual network gateway é VpnGw1.
Saída parcial do dispositivo on-premises:
BGP session state: Active (tentando estabelecer)
Peer address configured: 10.100.0.1
Local BGP IP: 10.100.0.1
Qual é a causa raiz da falha na troca de rotas BGP?
A) O SKU VpnGw1 não suporta BGP, sendo necessário utilizar pelo menos VpnGw2 para habilitar essa funcionalidade.
B) O address space 10.100.0.0/24 configurado no local network gateway conflita com o endereço do BGP peer e impede o estabelecimento da sessão BGP.
C) O endereço IP do BGP peer on-premises (10.100.0.1) foi configurado igual ao IP de origem da sessão BGP no dispositivo on-premises, fazendo com que o dispositivo tente abrir sessão BGP consigo mesmo.
D) O virtual network gateway e o local network gateway estão usando ASNs diferentes, e o BGP exige que ambos os lados utilizem o mesmo ASN para estabelecer a sessão.
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o chamado: "A VPN Site-to-Site está com status Disconnected desde esta manhã. Ontem funcionava normalmente."
Nenhuma alteração foi registrada no lado Azure. O engenheiro tem acesso ao portal do Azure e ao dispositivo VPN on-premises.
Os passos de investigação disponíveis são:
[P] Verificar se o IP público do dispositivo VPN on-premises mudou
[Q] Verificar o status da conexão no portal do Azure e coletar logs de diagnóstico
[R] Confirmar se a shared key está idêntica em ambos os lados
[S] Verificar se o IP registrado no local network gateway corresponde ao IP atual do dispositivo
[T] Tentar recriar a conexão VPN no portal do Azure
Qual é a sequência correta de diagnóstico progressivo?
A) T, Q, P, S, R
B) Q, P, S, R, T
C) S, P, Q, R, T
D) P, R, S, Q, T
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista determinante está nos dados coletados: o IP público atual do dispositivo VPN on-premises após a manutenção da operadora é 177.23.45.88, mas o local network gateway ainda registra 177.23.45.10. O Azure usa o endereço IP do local network gateway para identificar o peer remoto da negociação IKE. Quando o IP real do dispositivo não corresponde ao registrado, o Azure não reconhece os pacotes IKE originados do novo endereço, e a sessão não pode ser renegociada corretamente.
O status Connected que permanece no portal é um estado residual do túnel anterior, que ainda não expirou por timeout. Esse detalhe é propositalmente enganoso e representa o erro de diagnóstico mais comum neste cenário: concluir que a conexão está ativa porque o portal não exibiu Disconnected imediatamente.
A informação sobre o firewall on-premises (UDP 500 e 4500 liberados) é irrelevante para este diagnóstico: o problema não é de bloqueio de tráfego, mas de identidade de peer.
A alternativa A é incorreta porque a SKU do gateway não tem relação com reconexão após mudança de IP. A alternativa C não tem fundamento técnico no cenário: nada indica incompatibilidade de protocolo. A alternativa D é incorreta porque o Azure não invalida shared keys por inatividade.
Agir com base na alternativa C seria o erro mais perigoso: reconfigurar o protocolo IKE em uma conexão ativa de produção introduziria downtime desnecessário sem resolver o problema real.
Gabarito — Cenário 2
Resposta: C
O address space do local network gateway é um campo editável a qualquer momento, sem necessidade de recriar o recurso ou a conexão. A ação correta é substituir o prefixo genérico 172.16.0.0/12 pelos prefixos específicos reais da rede on-premises, corrigindo o roteamento indevido sem causar downtime.
A restrição crítica do cenário é que a conexão VPN de produção não pode ser interrompida. Isso elimina a alternativa A, que exige exclusão e recriação do local network gateway (operação que derruba a conexão). A premissa de que prefixos genéricos não podem ser substituídos por prefixos específicos é tecnicamente falsa.
A alternativa B contorna o problema mas não o resolve: o peering entre VNets não corrige a rota incorreta aprendida pelo gateway e pode introduzir complexidade desnecessária. A alternativa D é perigosa: redirecionar 172.20.0.0/16 para Internet como next hop quebraria a conectividade das VMs de desenvolvimento com o Azure, não apenas com a VPN.
Gabarito — Cenário 3
Resposta: C
A saída do dispositivo on-premises revela que o BGP peer address configurado é 10.100.0.1 e o local BGP IP também é 10.100.0.1. Ou seja, o dispositivo foi configurado para abrir sessão BGP com ele mesmo. A sessão permanece no estado Active (tentando estabelecer) porque nunca encontra um peer externo para responder.
A causa raiz está em uma configuração incorreta no dispositivo on-premises: o endereço IP do peer BGP deveria ser o endereço IP do BGP peer do Azure (obtido nas configurações do virtual network gateway), não o próprio endereço local do dispositivo.
O address space 10.100.0.0/24 configurado no local network gateway (alternativa B) não interfere no estabelecimento da sessão BGP. Quando BGP está ativo, a recomendação é usar o IP do peer como /32 no address space, mas isso afeta apenas o roteamento estático inicial, não a sessão BGP em si.
A alternativa A é incorreta: VpnGw1 suporta BGP plenamente. A alternativa D revela um equívoco comum: BGP é um protocolo de roteamento entre sistemas autônomos diferentes (eBGP neste contexto), portanto ASNs diferentes são esperados e corretos.
A informação de que o túnel IPsec está ativo e a shared key está correta é irrelevante para a falha BGP: IPsec e BGP são camadas independentes. O túnel pode estar ativo sem que a sessão de controle BGP esteja estabelecida.
Gabarito — Cenário 4
Resposta: B
A sequência correta é: Q, P, S, R, T.
O raciocínio diagnóstico progressivo parte sempre do mais amplo para o mais específico, evitando ações destrutivas antes de validar o diagnóstico.
Q vem primeiro porque coletar o status da conexão e os logs de diagnóstico no portal é o ponto de partida: define se o problema é de tunelamento IPsec, autenticação ou roteamento, e orienta todas as etapas seguintes.
P vem em segundo porque mudança de IP público on-premises é a causa mais frequente de desconexão súbita sem alteração no lado Azure. Verificar isso cedo elimina ou confirma a hipótese principal.
S vem em terceiro como consequência direta de P: se o IP mudou, o local network gateway precisa ser atualizado. Esta etapa só faz sentido após confirmar o IP atual (P).
R vem em quarto porque a shared key raramente muda sozinha, e verificá-la antes de confirmar o IP seria deslocar o foco para uma causa menos provável. Mas deve ser verificada antes de qualquer ação corretiva.
T vem por último porque recriar a conexão é uma ação corretiva que só deve ocorrer após esgotar as causas identificáveis. Recriar antes de diagnosticar pode mascarar a causa real e introduzir downtime desnecessário.
Árvore de Troubleshooting: Create and configure a local network gateway
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro (quase preto) | Sintoma inicial ou ponto de entrada |
| Azul | Pergunta diagnóstica ou ponto de decisão |
| Vermelho | Causa identificada ou estado de falha confirmado |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação intermediária ou ponto de verificação |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma observado e siga as ramificações respondendo cada pergunta com base no que você pode verificar diretamente no portal do Azure ou no dispositivo on-premises. Cada bifurcação elimina uma hipótese e estreita o diagnóstico. Nunca avance para uma ação corretiva (nó verde) sem ter percorrido todos os nós de decisão do caminho correspondente.