Laboratório de Troubleshooting: Implement Azure Extended Network
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações reporta que, após a implantação do Azure Extended Network, as VMs no Azure com IPs estendidos conseguem iniciar conexões com servidores on-premises sem problemas. Contudo, quando um servidor on-premises tenta iniciar uma conexão com uma dessas VMs no Azure, a conexão expira sem resposta.
O engenheiro responsável verificou os seguintes itens e confirmou que estão corretos:
- O NSG associado à sub-rede da VNet no Azure permite tráfego de entrada da faixa
10.10.5.0/24(sub-rede on-premises) - O appliance do Azure Extended Network no Azure está em estado
Runningno portal - O firewall do Windows nas VMs de destino está desabilitado para fins de teste
- A versão do sistema operacional do appliance on-premises é Windows Server 2019
O engenheiro também coletou a saída do comando route print no servidor on-premises que tenta iniciar a conexão:
IPv4 Route Table
Active Routes:
Network Destination Netmask Gateway Interface
0.0.0.0 0.0.0.0 10.10.5.1 10.10.5.20
10.10.5.0 255.255.255.0 On-link 10.10.5.20
127.0.0.0 255.0.0.0 On-link 127.0.0.1
Qual é a causa raiz do problema observado?
A) O NSG está configurado incorretamente; a regra de entrada precisa referenciar a tag de serviço VirtualNetwork em vez do prefixo IP específico.
B) O servidor on-premises não possui uma rota para o prefixo da sub-rede estendida apontando para o appliance local do Azure Extended Network, fazendo com que o tráfego siga o gateway padrão.
C) O appliance on-premises está com o serviço de extensão de rede parado; o estado Running visível no portal reflete apenas o appliance do lado Azure.
D) A versão Windows Server 2019 do appliance on-premises é incompatível com a versão atual do Azure Extended Network, exigindo atualização para Windows Server 2022.
Cenário 2 — Decisão de Ação
A equipe de infraestrutura identificou que o appliance do Azure Extended Network no lado do Azure apresentou falha de hardware na VM subjacente e foi desalocado pela plataforma. Como consequência, toda a comunicação Layer 2 estendida entre on-premises e Azure está interrompida, afetando 14 VMs em produção que dependem da sub-rede estendida.
A causa foi confirmada: a VM do appliance primário no Azure foi desalocada e não reiniciou automaticamente.
O ambiente possui as seguintes características:
- Existe um appliance secundário do Azure Extended Network já provisionado no Azure, configurado previamente como endpoint de failover
- O appliance on-premises já está configurado com os dois endpoints (primário e secundário)
- A equipe tem permissão total de contribuidor sobre a subscription
- O processo de recriar e reconfigurar um novo appliance primário levaria aproximadamente 45 minutos
- O time de negócio está reportando impacto crítico em produção há 12 minutos
Qual é a ação correta a tomar neste momento?
A) Iniciar imediatamente a recriação do appliance primário do zero, pois ele é o endpoint configurado originalmente e restaurá-lo garante que o ambiente retorne ao estado desejado documentado.
B) Verificar o estado do appliance secundário no Azure e, se estiver operacional, forçar o appliance on-premises a apontar ativamente para o endpoint secundário para restaurar a comunicação imediatamente.
C) Abrir um chamado de suporte na Microsoft para solicitar a restauração da VM do appliance primário, pois a falha foi na infraestrutura da plataforma Azure.
D) Reiniciar todas as 14 VMs de produção na sub-rede estendida para forçar o reestabelecimento das sessões TCP pelo caminho secundário assim que o failover ocorrer automaticamente.
Cenário 3 — Causa Raiz
Uma organização concluiu a configuração do Azure Extended Network há três dias e o ambiente funcionava corretamente. Nesta manhã, os usuários reportam que as VMs com IPs estendidos no Azure estão inacessíveis a partir do ambiente on-premises. O engenheiro de plantão coletou as seguintes informações:
O log de eventos do appliance on-premises (Windows Admin Center) exibe:
[2025-06-10 07:14:32] ExtendedNetwork: VXLAN tunnel to remote endpoint 10.0.1.4 - Status: UNREACHABLE
[2025-06-10 07:14:32] ExtendedNetwork: Last successful heartbeat: 2025-06-10 02:58:17
[2025-06-10 07:14:33] ExtendedNetwork: Attempting reconnect to primary endpoint...
[2025-06-10 07:14:33] ExtendedNetwork: Reconnect failed - no route to host
O engenheiro verificou os seguintes itens adicionais:
- O serviço VPN site-to-site entre on-premises e Azure está ativo e com tráfego normal conforme o painel do gateway de VPN no portal Azure
- O appliance do Azure Extended Network no Azure (
10.0.1.4) está com statusRunningno portal - Uma nova política de segurança foi aplicada no firewall perimetral on-premises na madrugada do mesmo dia, às 03:05
- O número de VMs ativas na VNet não mudou
Qual é a causa raiz da falha observada?
A) O gateway de VPN site-to-site entrou em estado de degradação mesmo exibindo tráfego normal; a falha do túnel VXLAN é consequência da perda intermitente de pacotes UDP na VPN.
B) O appliance do Azure Extended Network no Azure teve sua interface de rede desconectada da sub-rede, fazendo com que o IP 10.0.1.4 ficasse inativo apesar do status Running da VM.
C) A nova política de firewall aplicada on-premises está bloqueando o tráfego UDP necessário para o encapsulamento VXLAN entre o appliance local e o endpoint Azure, impedindo o estabelecimento do túnel.
D) O appliance on-premises perdeu o registro DNS do endpoint Azure após a aplicação da política de firewall, impedindo a resolução do IP 10.0.1.4.
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe um alerta: VMs com IPs estendidos no Azure não estão respondendo a pings vindos de servidores on-premises. O ambiente usa VPN site-to-site como conectividade subjacente. O engenheiro precisa diagnosticar o problema de forma sistemática.
Os passos de investigação disponíveis são:
P — Verificar se a VPN site-to-site entre on-premises e Azure está ativa e passando tráfego, confirmando que a conectividade Layer 3 subjacente está funcional.
Q — Verificar no log do appliance on-premises se o túnel VXLAN está estabelecido e se há heartbeats recentes com o endpoint Azure.
R — Testar conectividade direta (ping ou traceroute) do appliance on-premises para o IP do appliance Azure (10.0.1.x) usando a interface de gestão.
S — Confirmar que as VMs de destino no Azure estão em execução e que seus NSGs permitem ICMP ou a porta testada a partir da sub-rede on-premises.
T — Verificar se o serviço de Extended Network está ativo no appliance on-premises por meio do Windows Admin Center.
Qual é a sequência correta de diagnóstico?
A) T, Q, P, R, S
B) P, T, Q, R, S
C) Q, P, T, S, R
D) S, P, Q, T, R
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista definitiva está na saída do route print: a tabela de rotas do servidor on-premises contém apenas a rota local 10.10.5.0/24 e o gateway padrão 0.0.0.0. Não há nenhuma rota específica para o prefixo da sub-rede estendida apontando para o appliance local do Azure Extended Network.
Quando o servidor tenta iniciar uma conexão com uma VM no Azure cujo IP pertence à sub-rede estendida, o sistema operacional não encontra uma rota mais específica e encaminha o pacote para o gateway padrão (10.10.5.1), que não sabe como encaminhar o tráfego pelo túnel VXLAN. O pacote nunca chega ao appliance de extensão.
A informação sobre o NSG (alternativa A) é irrelevante para este diagnóstico: o problema ocorre antes mesmo de o tráfego chegar ao Azure. A alternativa C é descartada porque o enunciado confirma que o tráfego iniciado pelas VMs Azure chega corretamente ao on-premises, o que prova que o appliance on-premises está funcional. A alternativa D é um distrator baseado em versão de SO sem nenhuma evidência no cenário; a correlação entre Windows Server 2019 e o problema não existe na documentação da solução.
O erro mais perigoso seria agir sobre o NSG (alternativa A) sem primeiro validar a tabela de rotas, desperdiçando tempo em produção sem endereçar a causa real.
Gabarito — Cenário 2
Resposta: B
O ambiente já possui todos os pré-requisitos para usar o appliance secundário imediatamente: ele está provisionado, o appliance on-premises já conhece ambos os endpoints e a equipe tem permissão para agir. Com impacto crítico em produção há mais de 10 minutos, a prioridade é restaurar o serviço pelo caminho mais rápido disponível.
A alternativa A é a mais perigosa: recriar o appliance primário é a ação de recuperação correta a longo prazo, mas levar 45 minutos para isso quando um secundário operacional já existe é tecnicamente injustificável sob restrição de impacto em produção. A alternativa C delega à Microsoft uma ação que a equipe pode e deve executar autonomamente com as permissões disponíveis. A alternativa D é incorreta porque as sessões TCP não migram automaticamente pelo simples reinício das VMs de destino; o failover depende do appliance on-premises apontar ativamente para o endpoint secundário.
A restrição decisiva neste cenário é o tempo: todas as alternativas exceto a B ignoram que um caminho de recuperação imediato já está disponível e operacional.
Gabarito — Cenário 3
Resposta: C
A correlação temporal é a pista central: o último heartbeat bem-sucedido foi às 02:58:17 e a nova política de firewall foi aplicada às 03:05. O túnel VXLAN falhou imediatamente após a mudança no firewall perimetral on-premises, não antes.
O VXLAN opera sobre UDP, tipicamente na porta 4789. Se a nova política de firewall bloqueou esse tráfego UDP saindo do appliance on-premises em direção ao Azure, o túnel não consegue mais ser estabelecido ou mantido, mesmo que a VPN Layer 3 subjacente permaneça ativa. Essa é exatamente a situação descrita: a VPN está funcional (tráfego normal no painel do gateway), mas o VXLAN que trafega sobre ela está bloqueado.
A informação sobre o número de VMs ativas na VNet é irrelevante e foi incluída propositalmente para distrair.
A alternativa A é o distrator mais perigoso: o VPN ativo com tráfego normal descarta a hipótese de degradação do gateway. A alternativa B é descartada porque o appliance Azure está em estado Running e o IP seria inválido nesse caso. A alternativa D é tecnicamente implausível: o appliance usa o IP diretamente nos logs, não resolução DNS, e a mensagem de erro no route to host confirma problema de tráfego UDP, não de resolução de nome.
Gabarito — Cenário 4
Resposta: B — P, T, Q, R, S
O raciocínio diagnóstico correto parte da camada mais fundamental para a mais específica, eliminando hipóteses progressivamente.
O primeiro passo é confirmar que a conectividade Layer 3 subjacente (VPN) está ativa (P), pois sem ela nenhuma outra verificação faz sentido: o VXLAN não pode existir sem o canal que o transporta.
Com a VPN confirmada, o próximo passo é verificar se o serviço de Extended Network está ativo no appliance on-premises (T), pois um serviço parado explicaria a falha sem nenhuma evidência de problema de rede.
Em seguida, verifica-se o estado do túnel VXLAN nos logs do appliance (Q) para determinar se o túnel está estabelecido ou em tentativa de reconexão.
Com evidência de problema no túnel, o quarto passo é testar a conectividade Layer 3 direta entre os dois appliances (R), isolando se o problema é no caminho de rede entre eles.
Por último, com toda a cadeia de tunelamento validada, verifica-se o estado das VMs de destino e seus NSGs (S), que representam a camada de aplicação e controle de acesso, não o mecanismo de transporte.
A sequência A (T, Q, P, R, S) é próxima da correta mas verifica o serviço local antes de confirmar a infraestrutura subjacente, o que pode levar a conclusões prematuras se a VPN estiver degradada. As sequências C e D iniciam por componentes intermediários ou de destino, violando o princípio de diagnóstico da camada mais fundamental para a mais específica.
Árvore de Troubleshooting: Implement Azure Extended Network
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 |
| Verde | Ação recomendada ou resolução |
| Laranja | Verificação ou validação intermediária |
Diante de um problema real, comece pelo nó raiz (sintoma observado) e responda cada pergunta diagnóstica com base no que é verificável imediatamente no ambiente. Siga o ramo correspondente à resposta obtida. Os nós laranja indicam pontos onde uma verificação adicional é necessária antes de concluir o diagnóstico. Ao atingir um nó vermelho, a causa está identificada; o nó verde imediatamente conectado indica a ação corretiva recomendada. Nunca salte etapas: a árvore foi construída para eliminar hipóteses da camada mais fundamental para a mais específica, evitando ações corretivas baseadas em suposições.