Laboratório de Troubleshooting: Implement and manage virtual network connectivity by using Azure Virtual Network Manager
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de plataforma configurou o Azure Virtual Network Manager para gerenciar conectividade entre VNets de três equipes de produto. A topologia escolhida foi Hub and Spoke, com vnet-hub como hub e vnet-app1, vnet-app2 e vnet-app3 como spokes, todas na região East US. O grupo de rede foi criado com associação estática. A configuração foi salva e implantada com sucesso na região East US, conforme confirmado no histórico de implantações do portal.
Três dias após a implantação, a equipe de vnet-app3 abre um chamado relatando que máquinas virtuais nessa VNet não conseguem alcançar nenhum recurso em vnet-hub. As equipes de vnet-app1 e vnet-app2 não relataram problemas.
O administrador executa os seguintes comandos e obtém as saídas abaixo:
# Verificação de peerings em vnet-hub
az network vnet peering list \
--resource-group rg-network \
--vnet-name vnet-hub \
--output table
Name PeeringState AllowForwardedTraffic
-------------------------------------- -------------- ---------------------
avnm-hub-to-vnet-app1-xxxxxx Connected True
avnm-hub-to-vnet-app2-xxxxxx Connected True
O administrador observa ainda que vnet-app3 foi adicionada ao grupo de rede há dois dias, após a implantação inicial. A VNet vnet-app3 foi criada recentemente a partir de um template ARM e está localizada em East US. A assinatura está dentro do escopo do Network Manager.
Qual é a causa raiz da falha de conectividade de vnet-app3?
A) A VNet vnet-app3 foi criada a partir de um template ARM, o que gera um identificador de recurso incompatível com o Azure Virtual Network Manager
B) vnet-app3 foi adicionada ao grupo de rede após a implantação da configuração; como a configuração não foi reimplantada depois dessa adição, o peering não foi criado
C) O Azure Virtual Network Manager não cria peerings automaticamente para VNets adicionadas a grupos de rede com associação estática após a implantação inicial
D) O peering entre vnet-hub e vnet-app3 foi criado, mas está em estado "Initiated" aguardando aceitação manual pela equipe responsável por vnet-app3
Cenário 2 — Decisão de Ação
A equipe de segurança identificou que uma regra de administrador de segurança criada no Azure Virtual Network Manager está bloqueando incorretamente tráfego HTTPS legítimo entre vnet-app1 e um endpoint interno em vnet-hub. A regra em questão tem prioridade 100, ação "Deny" e cobre o intervalo de portas de destino 443. A causa foi confirmada: a regra foi criada com escopo excessivamente amplo durante uma janela de configuração emergencial ocorrida na noite anterior.
O ambiente possui as seguintes restrições:
- São 14h de uma terça-feira
- O serviço afetado processa transações financeiras em produção
- A equipe de negócios reporta impacto ativo desde as 13h45
- Remover a regra exige reimplantação da configuração de segurança, o que leva entre 5 e 15 minutos
- Existe uma regra de prioridade 90 na mesma configuração de segurança que permite tráfego HTTPS de um CIDR específico; o endereço IP de origem do tráfego afetado está dentro desse CIDR
Qual é a ação correta a tomar neste momento?
A) Remover a regra de prioridade 100 imediatamente e reimplantar a configuração de segurança
B) Criar um NSG temporário na subnet de destino em vnet-hub permitindo HTTPS, como mitigação imediata enquanto a correção definitiva é preparada
C) Alterar a prioridade da regra bloqueadora de 100 para 101 para que a regra de prioridade 90 (Allow) a anteceda, e reimplantar a configuração
D) Documentar o incidente e agendar a correção para a próxima janela de manutenção para evitar impacto adicional durante horário de pico
Cenário 3 — Causa Raiz
Uma organização utiliza o Azure Virtual Network Manager com escopo em um grupo de gerenciamento que contém três assinaturas. O Network Manager foi criado na assinatura A. As VNets de produção estão distribuídas entre as assinaturas A, B e C. A configuração de conectividade do tipo Mesh foi criada e implantada com sucesso segundo o portal.
O administrador-chefe de rede informa que vnet-prod-c1 e vnet-prod-c2, ambas na assinatura C, não aparecem como membros do grupo de rede, embora vnet-prod-a1, vnet-prod-b1 e vnet-prod-b2 estejam listadas corretamente. Ele menciona que utilizou associação dinâmica com uma Azure Policy que avalia a tag env=production. Verificou que todas as VNets têm a tag correta aplicada.
O administrador júnior sugere que o problema é causado pelo fato de o Network Manager ter sido criado na assinatura A, o que limitaria sua capacidade de gerenciar VNets de outras assinaturas. O administrador-chefe descarta essa hipótese.
Logs do portal mostram:
Policy compliance scan: Last evaluated 6 hours ago
vnet-prod-c1: Tag env=production [Compliant]
vnet-prod-c2: Tag env=production [Compliant]
Assignment scope: /providers/Microsoft.Management/managementGroups/mg-corp
O administrador verifica ainda que as VNets da assinatura C foram criadas ontem à tarde.
Qual é a causa raiz do problema?
A) A Azure Policy avalia recursos de forma assíncrona; as VNets da assinatura C foram criadas recentemente e ainda não passaram por um ciclo de avaliação completo de conformidade que dispare a associação dinâmica
B) O escopo da Azure Policy está definido no grupo de gerenciamento, mas o Network Manager só processa associações dinâmicas de assinaturas onde ele foi criado
C) VNets criadas nas últimas 24 horas são colocadas em quarentena temporária pelo Azure Resource Manager e não ficam disponíveis para políticas de associação dinâmica
D) A tag env=production nas VNets da assinatura C está com capitalização diferente da condição definida na policy, causando falso positivo no relatório de conformidade
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe o seguinte relato: VMs em vnet-spoke1 e vnet-spoke2 não conseguem se comunicar diretamente entre si, embora ambas as VNets sejam spokes em uma topologia Hub and Spoke gerenciada pelo Azure Virtual Network Manager. A comunicação de cada spoke com o hub funciona normalmente. A configuração foi implantada há uma semana sem alterações desde então.
Os passos de investigação disponíveis são:
- Passo P: Verificar se a opção "Enable direct connectivity between spokes" está habilitada na configuração de conectividade
- Passo Q: Confirmar se a configuração de conectividade foi reimplantada após qualquer alteração recente
- Passo R: Verificar a existência e o estado dos peerings diretos entre
vnet-spoke1evnet-spoke2usandoaz network vnet peering list - Passo S: Verificar se há regras de administrador de segurança bloqueando tráfego entre os CIDRs dos spokes
- Passo T: Confirmar se ambas as VNets estão no mesmo grupo de rede associado à configuração de conectividade
Qual é a sequência correta de investigação?
A) T, P, R, Q, S
B) P, T, Q, R, S
C) R, P, T, S, Q
D) Q, T, P, S, R
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A saída do comando confirma que apenas dois peerings existem em vnet-hub, correspondendo a vnet-app1 e vnet-app2. O peering para vnet-app3 está ausente. A pista decisiva está na ordem cronológica: vnet-app3 foi adicionada ao grupo de rede dois dias após a implantação, e o enunciado não menciona nenhuma reimplantação subsequente.
No Azure Virtual Network Manager, a implantação de uma configuração é um ato pontual que projeta o estado desejado nas regiões selecionadas. Adicionar um membro a um grupo de rede atualiza a definição do grupo, mas não dispara automaticamente uma nova implantação. É necessário reimplantar explicitamente para que os peerings reflitam o novo membro.
A informação sobre a VNet ter sido criada a partir de um template ARM é propositalmente irrelevante: o método de criação não afeta a compatibilidade com o AVNM.
A opção C representa um equívoco conceitual importante: a limitação não está no tipo de associação (estática), mas sim na ausência de reimplantação. Associação estática com reimplantação teria criado o peering normalmente. A opção D é plausível como sintoma em peerings manuais, mas peerings gerenciados pelo AVNM não requerem aceitação manual.
O distrator mais perigoso é o C, pois leva o administrador a concluir que precisa mudar o tipo de associação para dinâmica, quando a solução real é simplesmente reimplantar.
Gabarito — Cenário 2
Resposta: C
A restrição crítica que define a resposta correta é a existência da regra de prioridade 90 com ação Allow cobrindo exatamente o CIDR do tráfego afetado. Nas security admin rules do AVNM, regras de menor número de prioridade são avaliadas primeiro. Alterar a prioridade da regra bloqueadora de 100 para 101 faz com que a regra Allow de prioridade 90 seja avaliada antes, restaurando o tráfego sem necessidade de remover nenhuma regra.
Essa abordagem é menos destrutiva que a opção A (remoção completa da regra) e igualmente eficaz dado o conjunto de restrições, além de preservar a intenção original da regra para outros escopos que possam depender dela.
A opção B (NSG temporário) é tecnicamente válida, mas representa uma camada adicional de complexidade desnecessária, já que a solução dentro do próprio AVNM é mais direta. A opção A está correta em intenção, mas é mais invasiva quando existe uma alternativa menos destrutiva disponível. A opção D ignora o impacto ativo em produção, o que é inaceitável dado o contexto descrito.
O erro de raciocínio mais comum é ir diretamente para a remoção da regra (opção A) sem analisar se a estrutura existente já oferece uma solução mais cirúrgica.
Gabarito — Cenário 3
Resposta: A
A pista decisiva está na combinação de dois fatos: as VNets da assinatura C foram criadas ontem à tarde, e o último ciclo de avaliação da policy ocorreu há 6 horas. Embora o relatório de conformidade mostre as VNets como "Compliant", isso não significa que a associação dinâmica já foi processada. A conformidade e a efetivação da associação no grupo de rede dependem do ciclo de avaliação e do processamento pelo AVNM, que pode ter latência.
O relatório de conformidade da policy marcando as VNets como "Compliant" é uma informação propositalmente distratora: ele indica que a tag foi avaliada corretamente, mas não confirma que o AVNM já processou a associação resultante.
A opção B é exatamente o equívoco que o administrador-chefe descartou com razão: o local de criação do Network Manager não limita sua capacidade de gerenciar VNets dentro do escopo definido. A opção C é tecnicamente fictícia; não existe mecanismo de quarentena de 24 horas no Azure Resource Manager. A opção D é o distrator mais perigoso: sugere investigar capitalização da tag, o que consumiria tempo sem resultado, já que o relatório mostra as VNets como "Compliant" com o valor correto.
Agir com base no distrator D levaria o administrador a editar tags em produção sem necessidade, potencialmente gerando drift de configuração.
Gabarito — Cenário 4
Resposta: A (T, P, R, Q, S)
A sequência correta segue a lógica de eliminação progressiva do mais fundamental para o mais específico:
T confirma se ambas as VNets estão no mesmo grupo de rede associado à configuração, pois sem isso nenhuma das etapas seguintes faz sentido. P verifica se a opção de conectividade direta está habilitada, pois sua ausência explica o sintoma sem necessidade de investigação adicional. R verifica se os peerings diretos foram de fato criados, confirmando ou refutando a efetividade da configuração. Q verifica se houve reimplantação após qualquer alteração, cobrindo o caso em que a configuração existe mas não foi projetada corretamente. S investiga bloqueios por regras de segurança, que são a causa mais específica e menos provável dado que a comunicação com o hub funciona.
A sequência B comete o erro de verificar a opção de conectividade (P) antes de confirmar que as VNets estão no grupo correto (T), investigando uma configuração que pode não se aplicar ao escopo do problema. A sequência C começa pela verificação de peerings (R), que é um passo de confirmação, não de diagnóstico inicial. A sequência D começa por reimplantação (Q), que é uma ação corretiva prematura antes de qualquer diagnóstico.
O princípio subjacente é: valide o escopo e a configuração antes de verificar o estado resultante, e verifique o estado resultante antes de investigar bloqueios externos.
Árvore de Troubleshooting: Implement and manage virtual network connectivity by using Azure Virtual Network Manager
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (decisão binária ou por estado) |
| 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 e responda cada pergunta com base no que é observável no ambiente, sem presumir causas. Siga o caminho correspondente à resposta obtida. Nós de validação intermediária (laranja) indicam que uma verificação prática deve ser executada antes de prosseguir. O diagnóstico termina quando você alcança um nó vermelho (causa identificada) ou verde (ação recomendada), nunca antes disso.