Laboratório de Troubleshooting: Use Azure Network Watcher and Connection Monitor
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de desenvolvimento relata que uma VM na região East US não consegue acessar um serviço interno hospedado em outra VM na mesma VNet, na sub-rede 10.2.1.0/24. A aplicação retorna timeout ao tentar conectar na porta 8080.
O administrador executa o IP Flow Verify no Network Watcher com os seguintes parâmetros:
Direção: Outbound
Protocolo: TCP
IP de origem: 10.2.0.4
Porta de origem: 5000
IP de destino: 10.2.1.10
Porta de destino: 8080
Resultado: Allow
Regra aplicada: AllowVnetOutBound
Em seguida, executa o mesmo teste na VM de destino, invertendo a direção:
Direção: Inbound
Protocolo: TCP
IP de origem: 10.2.0.4
Porta de origem: 5000
IP de destino: 10.2.1.10
Porta de destino: 8080
Resultado: Deny
Regra aplicada: DenyAllInbound
Informações adicionais do ambiente:
- A VM de destino foi criada há três dias a partir de uma imagem personalizada
- O Network Watcher está habilitado na região East US
- A conta de armazenamento usada pelo NSG Flow Logs foi criada no mesmo dia
- O sistema operacional da VM de destino é Windows Server 2022
Qual é a causa raiz do problema observado?
A. O NSG associado ao adaptador de rede da VM de destino não possui uma regra de entrada permitindo a porta 8080, e a regra padrão DenyAllInbound está sendo aplicada
B. O Network Watcher não está habilitado na sub-rede de destino, fazendo com que o IP Flow Verify retorne resultados incorretos
C. A VM de destino foi criada a partir de uma imagem personalizada que bloqueia conexões externas por padrão no nível do sistema operacional
D. O NSG Flow Logs não está coletando dados suficientes porque a conta de armazenamento foi criada recentemente, impedindo a análise correta do tráfego
Cenário 2 — Decisão de Ação
A causa de uma falha de conectividade entre dois serviços em regiões diferentes foi identificada: o Connection Monitor criado para monitorar o endpoint api.interno.contoso.com na porta 443 está retornando falha em 100% das sondagens, mas o serviço de destino está operacional e acessível de outras origens.
Ao inspecionar a configuração do Connection Monitor, o administrador observa:
Test Group: prod-api-monitor
Origem: vm-monitor-eastus (10.1.0.5)
Destino: api.interno.contoso.com:443
Protocolo: TCP
Intervalo: 30 segundos
Threshold: 5% de falha
Status da extensão na VM de origem:
NetworkWatcherAgentLinux -> ProvisioningState: Failed
AzureMonitorLinuxAgent -> ProvisioningState: Succeeded
O ambiente está em produção, com SLA ativo. O time de segurança não permite reinicializações de VMs em horário comercial sem janela de manutenção aprovada. A próxima janela disponível é em 48 horas.
Qual é a ação correta a tomar neste momento?
A. Recriar imediatamente a VM de origem, pois a extensão com falha não pode ser reparada sem substituir a VM
B. Remover e reinstalar a extensão NetworkWatcherAgentLinux via portal ou CLI sem reinicializar a VM, e verificar se o Connection Monitor volta a operar
C. Aguardar a janela de manutenção de 48 horas e reinicializar a VM para forçar a reinstalação automática de todas as extensões
D. Alterar o endpoint de origem do Connection Monitor para outra VM disponível na mesma sub-rede, como solução definitiva, sem tratar a extensão com falha
Cenário 3 — Causa Raiz
Um administrador configura o Packet Capture no Network Watcher para capturar tráfego de uma VM Linux por 10 minutos. Após aguardar o tempo definido, tenta baixar o arquivo gerado pela conta de armazenamento configurada como destino.
O arquivo não está presente na conta de armazenamento. Nenhuma mensagem de erro foi exibida durante a configuração.
Informações coletadas durante a investigação:
VM: vm-captura-prod
Extensão instalada: AzureNetworkWatcherExtension -> ProvisioningState: Succeeded
Conta de armazenamento: stcapturaprod (LRS, East US)
Container configurado: packetcaptures
Status do Packet Capture: Stopped (Completed)
Verificação adicional no portal:
Packet Capture — Detalhes:
Arquivo de destino: /var/captures/capture01.cap
Conta de armazenamento: (não configurada)
Status: Stopped
O administrador também confirma que o NSG da sub-rede permite tráfego de saída para a Internet e que a VM possui IP público associado.
Qual é a causa raiz do problema observado?
A. A extensão AzureNetworkWatcherExtension falhou silenciosamente durante a captura, pois o status Succeeded reflete apenas a instalação, não a execução
B. O Packet Capture foi configurado com destino ao sistema de arquivos local da VM, não à conta de armazenamento, por isso o arquivo está na VM e não no storage
C. A conta de armazenamento utiliza redundância LRS, que não é compatível com o Packet Capture do Network Watcher
D. O NSG da sub-rede bloqueou a gravação do arquivo na conta de armazenamento por não permitir tráfego de saída para o endpoint do Azure Storage
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe o seguinte relato: VMs em uma sub-rede específica perderam conectividade com a Internet de forma repentina. Nenhuma alteração de infraestrutura foi registrada no changelog das últimas 24 horas, mas o time de rede aplicou atualizações em tabelas de rotas na semana anterior.
Os passos de investigação disponíveis são:
[P] Executar Next Hop no Network Watcher para verificar o tipo de rota efetiva para um IP externo a partir de uma das VMs afetadas
[Q] Verificar se o NSG da sub-rede possui uma regra de saída explícita bloqueando o tráfego para a Internet
[R] Consultar a tabela de rotas efetivas da VM no portal para identificar se há uma UDR sobrepondo a rota padrão de Internet
[S] Executar IP Flow Verify com destino a um IP externo para confirmar se o bloqueio ocorre na camada de NSG
[T] Abrir um ticket com a equipe de rede solicitando revisão das alterações feitas na semana anterior
Qual é a sequência correta de investigação?
A. T, Q, S, P, R
B. P, R, S, Q, T
C. Q, S, P, R, T
D. S, Q, T, P, R
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: A
A pista definitiva está na saída do próprio IP Flow Verify executado na VM de destino: o resultado é Deny com a regra DenyAllInbound aplicada. Essa é a regra padrão de todo NSG quando nenhuma regra de entrada explícita corresponde ao fluxo avaliado. Isso indica que o NSG associado ao adaptador de rede ou à sub-rede da VM de destino não possui nenhuma regra permitindo entrada na porta 8080.
A informação sobre a VM ter sido criada a partir de uma imagem personalizada é irrelevante para o diagnóstico de rede. Imagens personalizadas podem conter configurações de firewall do sistema operacional, mas o IP Flow Verify opera na camada do NSG do Azure, não dentro do SO. Se o bloqueio fosse no firewall do Windows, o IP Flow Verify retornaria Allow, não Deny.
A alternativa B é factualmente incorreta: o Network Watcher opera no nível da região, não da sub-rede. A alternativa D confunde a finalidade dos NSG Flow Logs (que registram fluxos já decididos pelo NSG) com o IP Flow Verify (que simula a decisão do NSG). O distrator mais perigoso é a alternativa C, pois leva o administrador a investigar o sistema operacional da VM de destino sem antes corrigir a causa real no NSG, desperdiçando tempo e potencialmente criando exceções desnecessárias no firewall do SO.
Gabarito — Cenário 2
Resposta: B
A causa foi declarada explicitamente: a extensão NetworkWatcherAgentLinux está com ProvisioningState: Failed. Essa extensão é o componente que permite ao Connection Monitor executar sondagens a partir da VM de origem. Sem ela funcionando, todas as sondagens falham independentemente do estado real da conectividade.
A restrição crítica do cenário é que o ambiente está em produção com SLA ativo e não é permitida reinicialização em horário comercial. A alternativa B resolve o problema dentro dessas restrições: extensões do Azure podem ser removidas e reinstaladas via portal ou CLI (az vm extension delete seguido de az vm extension set) sem exigir reinicialização da VM.
A alternativa A é tecnicamente desnecessária e viola a restrição de impacto em produção. A alternativa C respeita a restrição de horário, mas adia desnecessariamente uma correção que pode ser feita agora sem impacto. A alternativa D é a mais perigosa: trata o sintoma ao mover a origem, mas não corrige a extensão com falha, deixando a VM em estado degradado e potencialmente gerando dados de monitoramento inconsistentes a longo prazo.
Gabarito — Cenário 3
Resposta: B
O detalhe decisivo está na seção "Packet Capture — Detalhes" do portal: o campo Conta de armazenamento aparece como (não configurada), enquanto o campo Arquivo de destino aponta para /var/captures/capture01.cap, um caminho local no sistema de arquivos da VM. Isso indica que durante a configuração, o administrador selecionou o destino local em vez da conta de armazenamento, e o arquivo foi gravado com sucesso na VM, não no storage.
A informação sobre o IP público da VM e a permissão de saída no NSG é irrelevante para o diagnóstico, pois o problema não envolve conectividade de rede para o storage. O status Stopped (Completed) confirma que a captura foi executada e concluída normalmente.
A alternativa A é um distrator que explora a desconfiança no status Succeeded, mas esse status reflete a instalação e o funcionamento da extensão, e o próprio status Completed da captura confirma que ela foi executada. A alternativa C é factualmente incorreta: o tipo de redundância da conta de armazenamento (LRS, GRS etc.) não afeta a compatibilidade com o Packet Capture. A alternativa D seria plausível se o campo de conta de armazenamento estivesse configurado, mas os detalhes mostram claramente que não estava.
Gabarito — Cenário 4
Resposta: B
A sequência correta é P, R, S, Q, T, seguindo o princípio de diagnóstico progressivo da camada de roteamento para a camada de segurança, do geral para o específico.
O raciocínio é: começar pelo Next Hop (P) para obter imediatamente o tipo de rota efetiva para um IP externo. Se o resultado for None ou VirtualAppliance inesperado, o problema está na camada de roteamento. Em seguida, consultar as rotas efetivas (R) para identificar se uma UDR está sobrepondo a rota padrão de Internet, o que é consistente com alterações feitas pela equipe de rede na semana anterior. Só após descartar ou confirmar o problema de roteamento, usar o IP Flow Verify (S) para verificar se há bloqueio no NSG. Depois, inspecionar diretamente as regras do NSG (Q) para confirmar ou descartar essa camada. Por último, acionar a equipe de rede (T) apenas quando o diagnóstico estiver completo e houver evidências concretas para apresentar.
A sequência A começa pelo escalonamento (T) antes de qualquer diagnóstico técnico, o que é ineficiente e impreciso. A sequência C começa pela inspeção manual do NSG antes de usar as ferramentas de diagnóstico automatizado, invertendo a ordem lógica. A sequência D começa pelo IP Flow Verify sem antes entender a camada de roteamento, podendo levar a uma conclusão errada caso o problema seja em uma UDR e não no NSG.
Árvore de Troubleshooting: Use Azure Network Watcher and Connection Monitor
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul médio | Pergunta diagnóstica (decisão) |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, comece sempre pelo nó raiz descrevendo o sintoma observado. A cada nó de pergunta, responda com base no que você consegue verificar diretamente no portal ou via CLI, sem presumir a resposta. Siga o caminho correspondente à sua observação até alcançar um nó de causa identificada (vermelho), que indica o que deve ser corrigido, ou um nó de ação recomendada (verde), que indica o próximo passo concreto. Nós em laranja indicam que uma verificação adicional é necessária antes de concluir o diagnóstico.