Laboratório de Troubleshooting: Create and configure virtual network peering
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações reporta que duas máquinas virtuais, vm-app (em VNet-East, região East US) e vm-db (em VNet-West, região West US), perderam conectividade entre si após uma janela de manutenção realizada na noite anterior.
O administrador responsável pela manutenção informa que as atividades realizadas foram:
- Atualização das regras de NSG da subnet onde vm-db está alocada
- Adição de um novo espaço de endereço
10.2.128.0/18à VNet-West - Reinicialização da vm-db para aplicação de patches do sistema operacional
O peering East-to-West existia antes da manutenção e não foi tocado diretamente. Ao verificar o estado atual no portal, o administrador observa:
Peering: East-to-West
Status: Disconnected
Peering: West-to-East
Status: Connected
A vm-app consegue resolver o DNS da vm-db normalmente. O ping entre as VMs não retorna resposta.
Qual é a causa raiz da perda de conectividade?
A) As regras de NSG atualizadas na subnet de vm-db estão bloqueando o tráfego ICMP proveniente da VNet-East.
B) A adição de um novo espaço de endereço à VNet-West colocou o peering East-to-West no estado Disconnected, exigindo ressincronização manual.
C) O peering global entre regiões diferentes requer que ambos os lados estejam no estado Connected simultaneamente; como um lado está Disconnected, o tráfego é bloqueado nos dois sentidos.
D) A reinicialização da vm-db durante a janela de manutenção corrompeu a tabela de rotas efetivas associada ao peering, bloqueando o tráfego de entrada.
Cenário 2 — Decisão de Ação
A causa de um incidente foi identificada: o peering entre VNet-Hub e VNet-Spoke3 está com o estado Initiated no lado do hub e sem peering correspondente no lado do spoke. A investigação revelou que um engenheiro júnior criou apenas metade do peering durante um procedimento de expansão de rede.
O ambiente é de produção. Ambas as redes estão na mesma assinatura e região. Atualmente, nenhum recurso em VNet-Spoke3 possui conectividade com o hub. O time de negócios aguarda a normalização para retomar operações de um sistema de pagamentos que depende de acesso a um serviço hospedado no hub.
As restrições em vigor são:
- Não é permitido alterar o espaço de endereço de nenhuma VNet neste momento
- A janela de manutenção oficial só abre às 22h, mas a situação é classificada como incidente crítico com autorização para ação imediata
- O administrador possui a função Network Contributor em ambas as VNets
Qual é a ação correta a tomar neste momento?
A) Excluir o peering incompleto no lado do hub e recriar os dois lados do peering dentro da janela de manutenção às 22h para garantir consistência.
B) Criar o peering correspondente no lado de VNet-Spoke3 apontando para VNet-Hub, completando o par e colocando ambos os lados em estado Connected.
C) Aguardar a janela de manutenção e recriar o peering completo nos dois lados simultaneamente, pois um peering criado de forma assíncrona pode causar instabilidade.
D) Escalar para um administrador com a função Owner na assinatura, pois completar um peering em estado Initiated exige permissões elevadas além do Network Contributor.
Cenário 3 — Causa Raiz
Uma empresa opera uma topologia hub-and-spoke com três redes: VNet-Hub, VNet-A e VNet-B. O peering entre VNet-Hub e VNet-A, e entre VNet-Hub e VNet-B, está ativo e com estado Connected em todos os lados.
O administrador recebe uma reclamação: recursos em VNet-A não conseguem se comunicar com recursos em VNet-B. A equipe de infraestrutura confirma que nenhum NSG está bloqueando o tráfego entre os dois spokes e que as tabelas de rotas das subnets envolvidas não possuem rotas customizadas.
O administrador executa o seguinte comando e obtém a saída abaixo:
az network nic show-effective-route-table \
--resource-group rg-prod \
--name nic-vm-spoke-a \
--output table
Source State Address Prefix Next Hop Type Next Hop IP
-------- ------- ---------------- ----------------- -----------
Default Active 10.0.0.0/16 VnetLocal -
Default Active 10.1.0.0/16 VNetPeering -
Default Active 10.2.0.0/16 VNetPeering -
Default Active 0.0.0.0/0 Internet -
O espaço de endereço de VNet-B é 10.2.0.0/16. A rota para VNet-B aparece na tabela efetiva da VM em VNet-A.
Qual é a causa raiz da falha de comunicação entre os spokes?
A) As rotas efetivas mostram o next hop como VNetPeering, mas o tráfego entre spokes exige que o next hop seja um endereço IP de NVA ou gateway; portanto, as rotas estão configuradas incorretamente.
B) A rota para VNet-B na tabela efetiva da VM em VNet-A indica que o peering está ativo, mas o peering no Azure não é transitivo; sem um mecanismo de roteamento no hub (NVA ou Azure Route Server), o tráfego não será encaminhado de VNet-A para VNet-B através do hub.
C) O NSG da subnet de destino em VNet-B está bloqueando o tráfego, pois a ausência de regras customizadas não significa que as regras padrão permitam tráfego de peering entre spokes diferentes.
D) O fato de a tabela efetiva mostrar rotas para ambos os spokes indica que há um conflito de rotas no hub, que precisa ser resolvido com uma UDR explícita antes que a comunicação seja possível.
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe o seguinte relato: "A VM vm-finance, localizada em VNet-Finance, não consegue acessar um servidor de arquivos hospedado em VNet-Core. O peering entre as duas redes foi criado há duas semanas e funcionava normalmente até ontem."
O administrador dispõe dos seguintes passos de investigação, listados fora de ordem:
- Verificar o estado do peering (Connected ou Disconnected) nos dois lados no portal ou via CLI
- Analisar as regras de NSG na subnet de destino em VNet-Core para identificar bloqueios de entrada
- Verificar se houve alteração no espaço de endereço de qualquer uma das duas VNets desde a última vez em que a conexão funcionava
- Executar
az network nic show-effective-route-tablena NIC de vm-finance para confirmar se a rota para VNet-Core está presente e ativa - Testar conectividade com
Test-NetConnectionoupinga partir de vm-finance para confirmar o escopo exato da falha
Qual sequência de diagnóstico representa a abordagem mais lógica e eficiente?
A) 5 → 1 → 3 → 4 → 2
B) 1 → 4 → 3 → 5 → 2
C) 3 → 1 → 5 → 4 → 2
D) 5 → 3 → 1 → 4 → 2
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva no enunciado é o estado assimétrico do peering: East-to-West em Disconnected enquanto West-to-East permanece Connected. Esse estado assimétrico é exatamente o comportamento esperado quando o espaço de endereço de uma VNet é modificado após o estabelecimento do peering. O Azure invalida o lado do peering que pertence à rede que não sofreu a mudança, pois ela precisa ser ressincronizada para reconhecer o novo prefixo. A ressincronização manual via portal (botão Sync) ou via CLI é o único caminho para restaurar o estado Connected.
A informação sobre a reinicialização da vm-db é propositalmente irrelevante e representa uma armadilha comum: atribuir a falha de rede a uma ação que afeta apenas o sistema operacional da VM, não a infraestrutura de roteamento do Azure.
As atualizações de NSG são um distrator plausível, mas o NSG explicaria bloqueio de tráfego com peering Connected, não o estado Disconnected do peering em si. O distrator mais perigoso é a alternativa C, pois mistura corretamente a observação de assimetria com uma conclusão errada: o estado de um lado não bloqueia o outro de forma bidirecional por regra de plataforma; o bloqueio ocorre porque o roteamento está quebrado por ausência de ressincronização.
Gabarito — Cenário 2
Resposta: B
O peering em estado Initiated significa que apenas um dos dois lados foi criado. A solução técnica é criar o peering complementar no lado que está faltando, o que colocará ambos os lados em Connected imediatamente. Isso não requer nenhuma alteração de espaço de endereço, o que elimina qualquer risco relacionado à restrição declarada no enunciado.
O cenário é classificado como incidente crítico com autorização explícita para ação imediata, o que invalida diretamente as alternativas A e C, que propõem aguardar a janela das 22h. Aguardar seria a decisão correta em um contexto de manutenção planejada, mas não em um incidente com autorização em vigor.
A alternativa D é o distrator mais perigoso: a função Network Contributor possui a permissão Microsoft.Network/virtualNetworks/peer/action, que é exatamente o que se precisa para criar um peering. Escalar para um Owner seria desnecessário e introduziria atraso em um incidente crítico sem nenhum benefício técnico.
Gabarito — Cenário 3
Resposta: B
A tabela de rotas efetivas confirma que a vm-finance em VNet-A possui uma rota ativa para o prefixo de VNet-B com next hop VNetPeering. Isso significa que o plano de controle está correto: o Azure sabe que VNet-B existe e que o caminho passa pelo peering. O problema está no plano de encaminhamento: o peering do Azure não é transitivo. O pacote chega ao hub, mas o hub não possui nenhum mecanismo para reencaminhá-lo para o spoke de destino. Sem um NVA com IP forwarding habilitado ou um Azure Route Server configurado, o tráfego entre spokes é descartado silenciosamente no hub.
A informação sobre ausência de NSGs e UDRs é relevante porque elimina hipóteses concorrentes, mas também serve para induzir o leitor a concluir que "se não há bloqueio, deveria funcionar", o que é um raciocínio incorreto: a ausência de bloqueio não substitui a ausência de roteamento ativo.
A alternativa A representa um equívoco técnico grave: o next hop VNetPeering é exatamente o valor correto e esperado para rotas injetadas por peering. Agir com base nesse distrator levaria o administrador a criar UDRs desnecessárias e potencialmente disruptivas.
Gabarito — Cenário 4
Resposta: A
A sequência correta é 5 → 1 → 3 → 4 → 2.
O raciocínio diagnóstico deve partir do sintoma concreto e progredir do mais superficial para o mais granular:
- Passo 5 confirma o escopo real da falha antes de qualquer investigação de infraestrutura. Sem isso, o administrador pode investigar uma hipótese errada.
- Passo 1 verifica se a infraestrutura de peering está íntegra. Um peering Disconnected encerra a investigação de roteamento e aponta diretamente para a causa.
- Passo 3 investiga se houve mudança de espaço de endereço, que é a causa mais comum de um peering saudável entrar em Disconnected repentinamente.
- Passo 4 examina as rotas efetivas para confirmar se o plano de encaminhamento está correto, mesmo com o peering Connected.
- Passo 2 analisa os NSGs apenas depois de confirmar que roteamento e peering estão corretos, pois NSG é um controle de segurança que opera sobre tráfego que já chegaria ao destino.
Iniciar pela análise de NSG (alternativas B e D em diferentes posições) é o erro de diagnóstico mais comum: o administrador parte do bloqueio mais visível sem verificar antes se o caminho de rede sequer existe.
Árvore de Troubleshooting: Create and configure virtual network peering
Legenda:
- Azul escuro: sintoma inicial ou ponto de entrada
- Azul: pergunta de diagnóstico com resposta verificável
- Vermelho: causa identificada
- Verde: ação recomendada ou resolução
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma de conectividade ausente. Responda cada pergunta de diagnóstico com base no que você consegue observar diretamente no portal ou via CLI, sem presumir a causa. Siga o caminho indicado pela sua resposta até alcançar um nó vermelho de causa identificada, depois aplique a ação verde correspondente. Se a ação não resolver o problema, retorne ao último nó de pergunta e reavalie a resposta dada.