Fundamentação Teórica: Troubleshoot network connectivity

---

1. Intuição Inicial

Imagine que você ligou para alguém e a chamada não conectou. Para descobrir o problema, você segue uma lógica progressiva: seu telefone está com sinal? O número está correto? A linha da outra pessoa está ativa? Há bloqueio de chamadas configurado? Cada verificação elimina uma hipótese e aponta para a próxima.

Diagnosticar conectividade de rede no Azure segue exatamente esse raciocínio estruturado. Quando uma VM não consegue se comunicar com outra, quando um usuário não consegue acessar um serviço, ou quando uma aplicação está com timeout, a causa pode estar em qualquer ponto do caminho: NSG bloqueando, rota incorreta, peering desconectado, firewall descartando pacotes, DNS resolvendo para endereço errado, ou simplesmente o serviço de destino não está escutando na porta esperada.

O troubleshooting de conectividade de rede no Azure é a habilidade de usar um conjunto de ferramentas e uma metodologia sistemática para localizar exatamente onde no caminho a comunicação está sendo interrompida.

---

2. Contexto

Todos os conceitos estudados nos módulos anteriores convergem aqui: VNets, subnets, peerings, NSGs, UDRs, IPs públicos. Um problema de conectividade pode ter origem em qualquer um desses componentes.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

O Azure Network Watcher é o serviço central de diagnóstico de rede. Ele contém um conjunto de ferramentas específicas para cada tipo de problema. Entender o que cada ferramenta faz e quando usá-la é o núcleo deste módulo.

---

3. Construção dos Conceitos

3.1 O Azure Network Watcher

O Network Watcher é um serviço regional que precisa estar habilitado em cada região onde você quer usar suas ferramentas de diagnóstico. Ele é habilitado automaticamente quando você cria uma VNet em uma região, mas em algumas situações pode estar desabilitado.

Caminho: Monitor > Network Watcher ou buscar "Network Watcher" no portal.

O Network Watcher organiza suas ferramentas em categorias:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

3.2 As Ferramentas Principais e o Que Cada Uma Responde

Ferramenta	Pergunta que responde	Camada
IP Flow Verify	"Este pacote seria permitido ou bloqueado por NSG?"	L4: NSG
Next Hop	"Para onde vai este tráfego? Qual rota está sendo usada?"	L3: Roteamento
Effective Security Rules	"Quais regras NSG estão atualmente ativas nesta NIC?"	L4: NSG
Connection Troubleshoot	"Esta conexão TCP/ICMP funciona entre estes dois pontos?"	L3-L7: Ponta a ponta
VPN Troubleshoot	"Por que o VPN Gateway ou conexão VPN está com problema?"	VPN
Packet Capture	"O que exatamente está passando por esta NIC?"	L2-L7: Captura raw
NSG Flow Logs	"Que tráfego passou (ou foi bloqueado) nos últimos dias?"	L4: Histórico
Topology	"Como está a topologia de rede desta região visualmente?"	Visão geral
Connection Monitor	"Esta conexão está funcionando continuamente?"	Monitoramento contínuo

3.3 Metodologia de Diagnóstico: Do Simples ao Específico

Antes de abrir ferramentas, é importante ter uma metodologia. Investigar aleatoriamente desperdiça tempo. O modelo mais eficaz é dividir o problema em camadas:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

---

4. Visão Estrutural

O Caminho de um Pacote e Onde Pode Ser Bloqueado

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Cada seta é um ponto potencial de bloqueio. A ferramenta certa diagnostica cada ponto específico.

---

5. Funcionamento na Prática

Ferramenta 1: IP Flow Verify

O que faz: verifica se um pacote com determinados parâmetros (protocolo, porta, direção, IP de origem e destino) seria permitido ou negado pelas regras NSG aplicadas a uma NIC específica.

Caminho: Network Watcher > IP Flow Verify

Parâmetros necessários:

• VM (e sua NIC)
• Direção: Inbound ou Outbound
• Protocolo: TCP ou UDP
• IP local (da VM)
• Porta local
• IP remoto (origem ou destino)
• Porta remota

Resultado: indica "Access Allowed" ou "Access Denied", e qual regra NSG específica tomou a decisão.

# Via CLI
az network watcher test-ip-flow \
  --direction Inbound \
  --protocol TCP \
  --local 10.0.1.4:80 \
  --remote 40.68.100.50:12345 \
  --vm /subscriptions/<sub-id>/resourceGroups/rg-producao/providers/Microsoft.Compute/virtualMachines/vm-web \
  --nic /subscriptions/<sub-id>/resourceGroups/rg-producao/providers/Microsoft.Network/networkInterfaces/nic-vm-web \
  --resource-group NetworkWatcherRG \
  --watcher-resource-group NetworkWatcherRG

Comportamento não óbvio: IP Flow Verify verifica apenas NSGs. Ele não considera Azure Firewall, UDRs, ou firewalls do sistema operacional da VM. Se a resposta for "Access Allowed" mas a conexão ainda falha, o problema está em outra camada.

Ferramenta 2: Next Hop

O que faz: para um IP de origem (VM) e um IP de destino, informa qual é o próximo salto (next hop) e qual rota está sendo usada.

az network watcher show-next-hop \
  --resource-group NetworkWatcherRG \
  --watcher-resource-group NetworkWatcherRG \
  --vm vm-app \
  --source-ip 10.0.1.4 \
  --dest-ip 8.8.8.8

Resultado típico:

{
  "nextHopIpAddress": "",
  "nextHopType": "Internet",
  "routeTableId": "System Route"
}

Se o Next Hop retorna None, o tráfego está sendo descartado por roteamento (blackhole). Se retorna um IP inesperado, uma UDR está redirecionando o tráfego para um lugar errado.

Ferramenta 3: Effective Security Rules

O que faz: exibe todas as regras NSG atualmente efetivas em uma NIC, incluindo regras do NSG da NIC e do NSG da subnet, já combinadas e ordenadas por prioridade. Mostra claramente as regras padrão do Azure e as regras criadas pelo usuário.

az network watcher show-security-group-view \
  --resource-group NetworkWatcherRG \
  --watcher-resource-group NetworkWatcherRG \
  --vm vm-web \
  --network-interfaces /subscriptions/<sub-id>/resourceGroups/rg-producao/providers/Microsoft.Network/networkInterfaces/nic-vm-web

Diferença do IP Flow Verify: Effective Security Rules mostra todas as regras (visão completa); IP Flow Verify simula um pacote específico e diz qual regra se aplica. Use Effective Security Rules para auditoria; use IP Flow Verify para diagnóstico de um fluxo específico.

Ferramenta 4: Connection Troubleshoot

O que faz: testa a conectividade ponta a ponta entre uma origem (VM Azure) e um destino (VM, URL, ou IP). Verifica se a conexão TCP ou ICMP funciona, e em caso de falha, indica o ponto do problema.

az network watcher test-connectivity \
  --resource-group NetworkWatcherRG \
  --source-resource /subscriptions/<sub-id>/resourceGroups/rg-producao/providers/Microsoft.Compute/virtualMachines/vm-app \
  --dest-address 10.0.2.4 \
  --dest-port 1433 \
  --protocol Tcp

Resultado inclui:

• connectionStatus: Reachable ou Unreachable
• avgLatencyInMs: latência média
• hops: lista de saltos com status em cada um, mostrando onde o bloqueio ocorre

# Testar conectividade para URL externa
az network watcher test-connectivity \
  --resource-group NetworkWatcherRG \
  --source-resource /subscriptions/<sub-id>/resourceGroups/rg-producao/providers/Microsoft.Compute/virtualMachines/vm-app \
  --dest-address "https://www.microsoft.com" \
  --dest-port 443 \
  --protocol Https

Limitação: Connection Troubleshoot requer que o Network Watcher Agent esteja instalado na VM de origem. Em VMs Windows, é a extensão AzureNetworkWatcherExtension. Em VMs Linux, é NetworkWatcherAgentLinux. O portal solicita a instalação automaticamente se necessário.

Ferramenta 5: VPN Troubleshoot

O que faz: diagnostica problemas em VPN Gateways e conexões VPN site-to-site. Analisa logs detalhados do gateway e retorna um relatório com o problema identificado.

az network watcher troubleshooting start \
  --resource-id /subscriptions/<sub-id>/resourceGroups/rg-networking/providers/Microsoft.Network/virtualNetworkGateways/vpn-gw-prod \
  --resource-type vnetGateway \
  --storage-account <storage-account-id> \
  --storage-path "https://minhaconta.blob.core.windows.net/diagnostics" \
  --resource-group NetworkWatcherRG

O diagnóstico de VPN salva os resultados em um Storage Account (obrigatório) e pode levar vários minutos. O resultado inclui um status (Healthy, NotConnected, Unknown) e detalhes do problema.

Ferramenta 6: Packet Capture

O que faz: captura tráfego de rede em uma NIC de VM e salva em um arquivo .pcap (compatível com Wireshark). É a ferramenta de última resort quando outras não identificaram o problema.

az network watcher packet-capture create \
  --resource-group NetworkWatcherRG \
  --vm vm-web \
  --name capture-vm-web-01 \
  --storage-account /subscriptions/<sub-id>/resourceGroups/rg-monitoring/providers/Microsoft.Storage/storageAccounts/diagnosticstore \
  --file-path /var/captures/capture-vm-web-01.cap \
  --time-limit 120 \
  --filters '[{"protocol": "TCP", "remotePort": "80"}]'

Pontos de atenção:

• Requer o Network Watcher Agent na VM
• Captura no nível da NIC virtual Azure, não dentro do SO da VM
• Pode ser filtrada por protocolo, porta, IP para reduzir volume
• Limite de tempo ou de tamanho de arquivo encerra a captura automaticamente

Ferramenta 7: NSG Flow Logs

O que faz: registra todo o tráfego (permitido e negado) que passa por um NSG, com timestamps, IPs, portas, protocolo e decisão. É um log histórico, não uma ferramenta de diagnóstico em tempo real.

Versões:

• Version 1: registra fluxo básico (permitido/negado, IPs, portas)
• Version 2: adiciona informações de bytes e pacotes por fluxo

Os logs são salvos em um Storage Account em formato JSON e podem ser integrados ao Traffic Analytics (Log Analytics) para visualização e queries KQL.

# Habilitar NSG Flow Logs version 2
az network watcher flow-log create \
  --resource-group NetworkWatcherRG \
  --name flow-log-nsg-backend \
  --nsg /subscriptions/<sub-id>/resourceGroups/rg-producao/providers/Microsoft.Network/networkSecurityGroups/nsg-subnet-backend \
  --storage-account /subscriptions/<sub-id>/resourceGroups/rg-monitoring/providers/Microsoft.Storage/storageAccounts/flowlogstore \
  --enabled true \
  --format JSON \
  --log-version 2 \
  --retention 30 \
  --traffic-analytics true \
  --workspace /subscriptions/<sub-id>/resourceGroups/rg-monitoring/providers/Microsoft.OperationalInsights/workspaces/law-monitoring \
  --interval 10

Ferramenta 8: Connection Monitor

O que faz: monitora conexões de forma contínua e periódica, com alertas quando a conectividade muda. Diferente do Connection Troubleshoot (pontual), o Connection Monitor executa testes em intervalos regulares.

Casos de uso:

• Monitorar continuamente conectividade entre camadas de uma aplicação
• Detectar problemas intermitentes que não aparecem em testes pontuais
• Medir latência ao longo do tempo para SLAs

---

6. Formas de Implementação

6.1 Portal do Azure

Quando usar: diagnóstico interativo, investigação exploratória, casos onde a CLI é menos conveniente.

O portal oferece todas as ferramentas do Network Watcher com interface visual e feedback imediato. A ferramenta de Topology gera um diagrama interativo da rede que é exclusiva do portal (não tem equivalente funcional na CLI).

Vantagem do portal para Topology: mostra visualmente como VNets, subnets, VMs, NSGs e peerings estão conectados na região, facilitando a compreensão da topologia antes de diagnosticar.

6.2 Azure CLI

Quando usar: scripts de diagnóstico automatizados, ambientes sem acesso a portal, integração com pipelines.

A CLI cobre todas as ferramentas do Network Watcher com saída em JSON que pode ser processada por scripts. É a abordagem mais eficiente para diagnóstico em lote ou automação.

Verificar se Network Watcher está habilitado em uma região:

az network watcher list --output table

Habilitar Network Watcher em uma região:

az network watcher configure \
  --resource-group NetworkWatcherRG \
  --locations brazilsouth \
  --enabled true

6.3 PowerShell

# IP Flow Verify
Test-AzNetworkWatcherIPFlow `
  -NetworkWatcher (Get-AzNetworkWatcher -Location "brazilsouth") `
  -TargetVirtualMachineId (Get-AzVM -Name "vm-web" -ResourceGroupName "rg-producao").Id `
  -Direction "Inbound" `
  -Protocol "TCP" `
  -RemoteIPAddress "40.68.100.50" `
  -LocalIPAddress "10.0.1.4" `
  -LocalPort "80" `
  -RemotePort "54321"

# Next Hop
Get-AzNetworkWatcherNextHop `
  -NetworkWatcher (Get-AzNetworkWatcher -Location "brazilsouth") `
  -TargetVirtualMachineId (Get-AzVM -Name "vm-app" -ResourceGroupName "rg-producao").Id `
  -SourceIPAddress "10.0.1.4" `
  -DestinationIPAddress "8.8.8.8"

---

7. Controle e Segurança

Permissões Necessárias para Network Watcher

Operação	Permissão mínima
Usar IP Flow Verify, Next Hop, Effective Security Rules	Network Contributor na VM e nos recursos de rede
Packet Capture	Network Contributor + acesso ao Storage Account
NSG Flow Logs	Network Contributor + Storage Blob Contributor no Storage
Connection Troubleshoot	Network Contributor + acesso à VM de origem
VPN Troubleshoot	Network Contributor no Gateway + Storage

NSG Flow Logs e Dados Sensíveis

Os NSG Flow Logs registram endereços IP de origem e destino de todo o tráfego. Em ambientes que processam dados pessoais (LGPD/GDPR), esses logs podem conter informações sensíveis. Considere:

• Retenção mínima necessária (configurável, recomendado 90 dias para análise)
• Criptografia do Storage Account
• Acesso restrito via RBAC ao Storage que contém os logs

---

8. Tomada de Decisão

Qual ferramenta usar para cada sintoma?

Sintoma	Ferramenta inicial	Próximo passo se não resolver
VM não responde na porta X	IP Flow Verify (verifica NSG)	Connection Troubleshoot (verifica caminho completo)
Tráfego vai para lugar errado	Next Hop (verifica rota)	Effective Security Rules (verifica se NSG interfere)
"Funciona às vezes, não sempre"	Connection Monitor (monitoramento contínuo)	NSG Flow Logs (histórico de fluxos)
VPN não conecta	VPN Troubleshoot	Verificar configuração IKE/IPSec
Quero ver o que está passando	Packet Capture	Analisar .pcap no Wireshark
Auditoria de segurança de tráfego	NSG Flow Logs + Traffic Analytics	Queries KQL no Log Analytics
Não sei por onde começar	Topology (visão geral)	IP Flow Verify + Next Hop em sequência

Quando o problema está no SO vs. na rede Azure?

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

---

9. Boas Práticas

Habilite NSG Flow Logs em todos os NSGs de produção desde o início: logs históricos são inestimáveis para diagnóstico retroativo. Quando um problema é reportado "aconteceu ontem às 14h", sem Flow Logs é impossível ver o que ocorreu. O custo de armazenamento dos logs é baixo comparado ao valor do diagnóstico.

Use Traffic Analytics para visualização de padrões: os NSG Flow Logs em formato raw são difíceis de analisar. Integrado ao Log Analytics com Traffic Analytics habilitado, você tem dashboards visuais de fluxos e pode escrever queries KQL para investigar padrões específicos.

Crie uma estrutura de diagnóstico de rede como código: scripts padronizados de diagnóstico que executam IP Flow Verify, Next Hop e Connection Troubleshoot em sequência para um par de IPs reduzem o tempo de diagnóstico e garantem que nada seja esquecido.

Instale o Network Watcher Agent em todas as VMs de produção: sem o agente, Connection Troubleshoot e Packet Capture não funcionam. Instale o agente no momento da criação da VM via extensão, não espere precisar.

Documente a topologia de rede esperada: ter um diagrama de referência da topologia esperada facilita identificar quando o Next Hop retorna um valor inesperado. Sem referência, é difícil saber se um next hop específico está correto ou errado.

---

10. Erros Comuns

Usar IP Flow Verify e concluir que "NSG está ok" sem verificar outras camadas

IP Flow Verify diz que o pacote seria permitido pelo NSG. O administrador conclui que o problema não é na rede Azure. Mas a conexão ainda falha porque há um Azure Firewall no caminho (UDR redireciona para o Firewall) com uma regra bloqueando o tráfego. IP Flow Verify não analisa Azure Firewall, apenas NSGs. A sequência completa deve incluir Next Hop para verificar se há NVA/Firewall no caminho.

Não verificar a direção correta no IP Flow Verify

O administrador verifica o IP Flow Verify na direção Inbound para a VM de destino e encontra "Allowed". Mas o problema é no tráfego Outbound da VM de origem (um NSG na subnet de origem está bloqueando a saída). É necessário verificar ambas as direções: Outbound na origem E Inbound no destino.

Testar com Connection Troubleshoot sem Network Watcher Agent instalado

A ferramenta retorna um erro de "agent not found" ou falha silenciosamente. O administrador interpreta como problema de rede quando na verdade é ausência do agente. Sempre confirme que o agente está instalado antes de usar Connection Troubleshoot.

Confundir "Access Allowed" no IP Flow Verify com "conexão funciona"

"Access Allowed" significa que o NSG permitiria o tráfego. Não significa que a conexão vai funcionar: pode haver uma UDR redirecionando para um Firewall que bloqueia, pode haver um blackhole de roteamento, pode haver o Windows Firewall da VM bloqueando. IP Flow Verify é apenas uma peça do diagnóstico.

Analisar NSG Flow Logs sem considerar que o log é amostrado

Em períodos de alto tráfego, o NSG Flow Logs pode não registrar 100% dos fluxos. Ele usa amostragem. Para análise forense de segurança onde cada fluxo importa, considere Packet Capture em conjunto com Flow Logs.

---

11. Operação e Manutenção

Queries KQL para Traffic Analytics

Com NSG Flow Logs e Traffic Analytics habilitados, queries no Log Analytics revelam padrões:

Tráfego bloqueado por NSG nas últimas 24 horas:

AzureNetworkAnalytics_CL
| where TimeGenerated > ago(24h)
| where FlowStatus_s == "D"  // D = Denied
| summarize count() by NSGName_s, NSGRuleNumber_d, DestIP_s, DestPort_d
| sort by count_ desc
| top 20 by count_

Top 10 origens de tráfego para uma VM específica:

AzureNetworkAnalytics_CL
| where TimeGenerated > ago(1h)
| where DestIP_s == "10.0.1.4"
| summarize Bytes = sum(OutboundBytes_d) by SrcIP_s
| sort by Bytes desc
| top 10 by Bytes

Conexões bloqueadas por IP específico (investigação de incidente):

AzureNetworkAnalytics_CL
| where TimeGenerated between (datetime(2024-03-01) .. datetime(2024-03-02))
| where SrcIP_s == "203.0.113.50"
| project TimeGenerated, SrcIP_s, SrcPort_d, DestIP_s, DestPort_d, FlowStatus_s, NSGName_s
| sort by TimeGenerated asc

Diagnóstico de Latência entre Regiões

Para problemas de latência entre VMs em regiões diferentes (Global VNet Peering), o Connection Monitor com medição contínua é a ferramenta mais adequada:

# Criar Connection Monitor entre VMs em regiões diferentes
az network watcher connection-monitor create \
  --name cm-prod-dr-connectivity \
  --resource-group NetworkWatcherRG \
  --location brazilsouth \
  --source-resource /subscriptions/<sub-id>/resourceGroups/rg-producao/providers/Microsoft.Compute/virtualMachines/vm-prod \
  --dest-resource /subscriptions/<sub-id>/resourceGroups/rg-dr/providers/Microsoft.Compute/virtualMachines/vm-dr \
  --dest-port 443 \
  --monitoring-interval 30

Limites Importantes

Item	Limite
Packet Capture ativo por região	10 simultâneos
Duração máxima de Packet Capture	5 horas
Tamanho máximo de arquivo Packet Capture	1 GB
NSG Flow Logs retenção máxima	365 dias
Connection Monitor: intervalos mínimos	30 segundos

---

12. Integração e Automação

Diagnóstico Automatizado com Azure Functions

Para ambientes onde problemas de conectividade são frequentes, uma Azure Function pode executar diagnósticos automaticamente em resposta a alertas:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Isso transforma o diagnóstico manual de 20-30 minutos em um relatório automático gerado em segundos quando um alerta é disparado.

Integration com Microsoft Sentinel

NSG Flow Logs enviados para Log Analytics podem ser conectados ao Microsoft Sentinel para análise de segurança e detecção de anomalias:

// Detectar varredura de portas (muitas portas diferentes de um mesmo IP)
AzureNetworkAnalytics_CL
| where TimeGenerated > ago(1h)
| where FlowStatus_s == "D"
| summarize PortsAttempted = dcount(DestPort_d) by SrcIP_s
| where PortsAttempted > 20
| sort by PortsAttempted desc

Script de Diagnóstico Sistemático

Um script que executa a sequência completa de diagnóstico para um par origem-destino:

#!/bin/bash
SOURCE_VM="vm-app"
SOURCE_IP="10.0.1.4"
DEST_IP="10.0.2.4"
DEST_PORT="1433"
RG="rg-producao"
NW_RG="NetworkWatcherRG"
SOURCE_VM_ID=$(az vm show --name $SOURCE_VM --resource-group $RG --query id -o tsv)
SOURCE_NIC=$(az vm show --name $SOURCE_VM --resource-group $RG \
  --query "networkProfile.networkInterfaces[0].id" -o tsv)

echo "=== 1. IP Flow Verify (Outbound da origem) ==="
az network watcher test-ip-flow \
  --direction Outbound \
  --protocol TCP \
  --local $SOURCE_IP:12345 \
  --remote $DEST_IP:$DEST_PORT \
  --vm $SOURCE_VM_ID \
  --nic $SOURCE_NIC \
  --resource-group $NW_RG \
  --watcher-resource-group $NW_RG

echo "=== 2. Next Hop da origem para destino ==="
az network watcher show-next-hop \
  --resource-group $NW_RG \
  --vm $SOURCE_VM \
  --source-ip $SOURCE_IP \
  --dest-ip $DEST_IP \
  --watcher-resource-group $NW_RG

echo "=== 3. Connection Troubleshoot ==="
az network watcher test-connectivity \
  --source-resource $SOURCE_VM_ID \
  --dest-address $DEST_IP \
  --dest-port $DEST_PORT \
  --protocol Tcp \
  --resource-group $NW_RG \
  --watcher-resource-group $NW_RG

---

13. Resumo Final

Pontos essenciais:

• Network Watcher é o serviço central de diagnóstico de rede no Azure. Precisa estar habilitado por região.
• Cada ferramenta diagnostica uma camada específica: IP Flow Verify (NSG), Next Hop (roteamento), Connection Troubleshoot (ponta a ponta), Packet Capture (raw), NSG Flow Logs (histórico).
• A metodologia correta é progressiva: verificar NSG, depois roteamento, depois firewall/NVA, depois SO da VM de destino.
• NSG Flow Logs é uma ferramenta de monitoramento histórico, não de diagnóstico em tempo real. Habilite preventivamente.

Diferenças críticas:

• IP Flow Verify verifica apenas NSGs. Não analisa Azure Firewall, UDRs ou firewalls do SO. "Allowed" não significa que a conexão funciona.
• Connection Troubleshoot vs. Connection Monitor: Troubleshoot é pontual (executa uma vez); Monitor é contínuo (executa periodicamente com alertas).
• Effective Security Rules vs. IP Flow Verify: Effective Security Rules mostra todas as regras ativas (visão completa); IP Flow Verify simula um pacote específico e diz qual regra decide.
• Next hop "None" significa blackhole (tráfego descartado por roteamento), não ausência de rota. É diferente de rota não encontrada.

O que precisa ser lembrado:

• Connection Troubleshoot e Packet Capture requerem o Network Watcher Agent instalado na VM. Instale como extensão no provisionamento.
• A ordem de diagnóstico mais eficiente: IP Flow Verify → Next Hop → Connection Troubleshoot → Packet Capture.
• NSG Flow Logs salvam em Storage Account e podem ser integrados ao Log Analytics via Traffic Analytics para queries KQL.
• VPN Troubleshoot salva resultados em Storage Account (obrigatório) e pode levar vários minutos para completar a análise.
• Para problemas intermitentes, Connection Monitor com monitoramento contínuo é muito mais eficaz do que testes pontuais.
• IP Flow Verify verifica as duas direções de forma independente: sempre teste Outbound na origem E Inbound no destino.