Laboratório de Troubleshooting: Verify IP Flow
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Um administrador recebe um chamado relatando que a VM vm-app01 não consegue se comunicar com um banco de dados hospedado em outra VM (vm-db01) dentro da mesma VNet, na sub-rede 10.10.2.0/24. As duas VMs estão em sub-redes diferentes dentro de vnet-prod.
O administrador executa o Verify IP flow e obtém o seguinte resultado:
Direction: Outbound
Protocol: TCP
Local IP: 10.10.1.4
Local port: *
Remote IP: 10.10.2.10
Remote port: 1433
Access: Deny
Rule name: Deny-CrossSubnet
NSG: nsg-app-subnet
Informações adicionais coletadas durante a investigação:
- O peering entre
vnet-prodevnet-hubestá no estadoConnected - O gateway de VPN está operacional e com conexão estabelecida
- A rota efetiva para
10.10.2.0/24aponta paraVnetLocal - O NSG
nsg-db-subnetfoi atualizado ontem pela equipe de banco de dados
Qual é a causa raiz do problema observado?
A. O peering entre vnet-prod e vnet-hub está causando conflito de rota, impedindo o tráfego entre sub-redes da mesma VNet.
B. O NSG nsg-db-subnet foi atualizado recentemente e passou a bloquear conexões na porta 1433.
C. O NSG nsg-app-subnet possui uma regra customizada chamada Deny-CrossSubnet que está bloqueando o tráfego de saída para a sub-rede de banco de dados.
D. A rota efetiva apontando para VnetLocal está incorreta e o tráfego está sendo descartado antes de chegar ao destino.
Cenário 2 — Impacto Colateral
Durante uma janela de manutenção, um administrador identifica que o NSG nsg-web-subnet está bloqueando tráfego de entrada na porta 443 proveniente da internet. A regra responsável é DenyAllInbound, a regra padrão de menor prioridade. Para corrigir o problema, o administrador cria uma nova regra com as seguintes configurações:
Nome: Allow-HTTPS-Inbound
Prioridade: 100
Origem: Any
Porta de origem: *
Destino: Any
Porta de destino: 443
Protocolo: TCP
Ação: Allow
A regra é aplicada com sucesso e o tráfego HTTPS começa a fluir normalmente para as VMs da sub-rede web-subnet.
Qual consequência secundária essa ação pode causar?
A. O Verify IP flow passará a retornar resultados inconsistentes para fluxos de entrada nessa sub-rede, pois a ferramenta não reconhece regras com prioridade abaixo de 200.
B. O tráfego HTTPS de entrada passará a ser permitido a partir de qualquer origem, incluindo IPs externos não autorizados, ampliando a superfície de ataque da sub-rede.
C. A regra criada sobrescreve automaticamente todas as outras regras do NSG com prioridade superior, alterando o comportamento de fluxos já permitidos.
D. VMs adicionadas futuramente à sub-rede não herdarão a nova regra, pois regras de NSG com prioridade abaixo de 200 não se aplicam a recursos criados após a regra.
Cenário 3 — Causa Raiz
A equipe de operações relata que o tráfego de saída de vm-analytics01 para um endpoint externo na internet (20.40.10.5, porta 443) está sendo bloqueado. O ambiente tem as seguintes características:
- A VM está na sub-rede
10.30.1.0/24dentro devnet-analytics - Existe uma UDR aplicada à sub-rede que redireciona
0.0.0.0/0para um NVA (Network Virtual Appliance) com IP10.0.0.4 - O NVA está operacional e com regras de passagem configuradas para a porta 443
- O administrador executa o Verify IP flow e obtém o resultado abaixo
Direction: Outbound
Protocol: TCP
Local IP: 10.30.1.5
Local port: *
Remote IP: 20.40.10.5
Remote port: 443
Access: Allow
Rule name: AllowInternetOutBound
NSG: nsg-analytics-subnet
Após o resultado, a equipe conclui que o NSG não está causando o bloqueio, mas o tráfego ainda não chega ao destino.
Qual é a causa raiz do problema observado?
A. O Verify IP flow retornou Allow incorretamente porque a regra AllowInternetOutBound é a regra padrão e tem precedência sobre qualquer bloqueio.
B. O NVA está descartando o tráfego internamente, e o Verify IP flow confirmou que o bloqueio ocorre nessa camada.
C. O Verify IP flow avalia somente regras de NSG e não considera a UDR nem o comportamento do NVA, portanto o bloqueio pode estar ocorrendo após o pacote deixar o NSG.
D. A UDR está sobrepondo a regra AllowInternetOutBound do NSG, e o Verify IP flow não consegue avaliar fluxos em sub-redes com UDR aplicada.
Cenário 4 — Decisão de Ação
Durante uma investigação de incidente, o Verify IP flow confirma que o tráfego de entrada na porta 22 (SSH) está sendo negado para a VM vm-jump01 pela regra Block-SSH-All no NSG nsg-mgmt. A equipe de segurança implementou essa regra intencionalmente como parte da política de hardening da organização.
Um engenheiro sênior precisa acessar vm-jump01 com urgência para aplicar um patch crítico que está causando falhas intermitentes em 30% das requisições da aplicação. O ambiente possui:
- Azure Bastion implantado e funcional na VNet
- Política de Change Management ativa, exigindo aprovação para alterações em NSGs de produção
- O engenheiro tem acesso ao portal do Azure com permissões de Contributor na subscription
Qual é a ação correta a tomar neste momento?
A. Criar uma regra temporária no NSG nsg-mgmt com prioridade mais alta que Block-SSH-All, permitindo SSH a partir do IP do engenheiro, e remover a regra após o acesso.
B. Solicitar aprovação emergencial no processo de Change Management para modificar a regra Block-SSH-All e liberar o acesso SSH permanentemente.
C. Utilizar o Azure Bastion para acessar vm-jump01 via portal do Azure, sem necessidade de modificar o NSG ou abrir a porta 22.
D. Acessar vm-jump01 diretamente pelo portal do Azure usando a funcionalidade de Serial Console, que não depende de conectividade de rede.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: C
O resultado do Verify IP flow é direto e sem ambiguidade: o acesso foi negado pela regra Deny-CrossSubnet no NSG nsg-app-subnet. Esse é o NSG da sub-rede de origem, e o nome da regra descreve exatamente o comportamento observado. A causa raiz é a existência de uma regra customizada de bloqueio no NSG aplicado à sub-rede da VM de origem.
A pista confirmatória está no campo Rule name: Deny-CrossSubnet e no campo NSG: nsg-app-subnet. Esses dois campos juntos apontam inequivocamente para onde o bloqueio ocorre e qual regra é responsável.
Informações irrelevantes: O estado do peering com vnet-hub, o status do gateway de VPN e a atualização recente do nsg-db-subnet são detalhes inseridos para desviar o diagnóstico. A rota efetiva para 10.10.2.0/24 apontando para VnetLocal confirma que o roteamento está correto e descarta a alternativa D.
O erro de raciocínio central nos distratores é ignorar o resultado explícito da ferramenta e buscar a causa em componentes que o próprio output já descartou. O distrator mais perigoso é o B, que leva o administrador a investigar o nsg-db-subnet quando o bloqueio ocorre antes de o pacote sequer chegar à sub-rede de destino.
Gabarito — Cenário 2
Resposta: B
Ao configurar a origem como Any e não restringir o intervalo de IPs de origem, o administrador permitiu que qualquer endereço IP externo estabeleça conexões HTTPS com qualquer VM da sub-rede web-subnet. O problema imediato foi resolvido, mas a superfície de ataque foi ampliada desnecessariamente. A regra correta deveria restringir a origem a intervalos conhecidos, como o prefixo de serviço Internet com filtros adicionais, ou ao IP de um load balancer frontal.
A alternativa A é falsa: o Verify IP flow não tem restrições de prioridade mínima para avaliação de regras. A alternativa C é falsa: regras de NSG não sobrescrevem outras regras automaticamente, elas são avaliadas por prioridade numérica. A alternativa D é falsa: regras de NSG se aplicam a todos os recursos da sub-rede independentemente de quando foram criados ou da prioridade da regra.
O impacto colateral real aqui não é técnico no sentido de quebrar algo, mas de introduzir um risco de segurança que pode não ser percebido imediatamente, tornando-o o tipo de consequência mais difícil de detectar em produção.
Gabarito — Cenário 3
Resposta: C
O Verify IP flow retornou Allow e esse resultado é válido: nenhuma regra de NSG está bloqueando o fluxo. A ferramenta funciona corretamente dentro do seu escopo, que se limita exclusivamente à avaliação das regras de NSG associadas à interface de rede e à sub-rede da VM. Ela não tem visibilidade sobre UDRs, NVAs, Azure Firewall, tabelas de rota ou qualquer outro mecanismo de filtragem fora da camada de NSG.
O tráfego pode estar sendo bloqueado no NVA, por uma regra de firewall interna a ele, por um problema de IP forwarding desabilitado na NIC do NVA, ou por qualquer outra camada posterior ao NSG. O Verify IP flow não pode confirmar nem descartar nenhuma dessas hipóteses.
Informação irrelevante: O fato de o NVA estar operacional e com regras configuradas é uma informação de contexto que não invalida a necessidade de investigação adicional nessa camada.
O distrator mais perigoso é o B, que interpreta o resultado Allow do Verify IP flow como uma confirmação de que o bloqueio está no NVA. A ferramenta não faz essa afirmação: ela apenas informa que o NSG não bloqueia. Concluir que o bloqueio está no NVA a partir disso é uma inferência correta de diagnóstico, mas não uma confirmação da ferramenta.
Gabarito — Cenário 4
Resposta: C
O Azure Bastion resolve o problema imediatamente sem exigir nenhuma alteração na infraestrutura de rede ou no NSG. Ele fornece acesso RDP e SSH via HTTPS pelo portal do Azure, tornando desnecessária a abertura da porta 22 ou qualquer modificação em regras de NSG. Essa é exatamente a situação para a qual o Bastion foi projetado.
A alternativa A viola a política de Change Management, mesmo sendo uma alteração temporária. A política exige aprovação formal para qualquer mudança em NSGs de produção, e criar uma regra sem aprovação é uma violação independentemente da intenção. A alternativa B resolveria o acesso, mas de forma permanente e com o processo de aprovação, o que não atende à urgência e introduz uma abertura de segurança desnecessária. A alternativa D é tecnicamente plausível para diagnóstico de problemas de boot ou sistema operacional, mas o Serial Console não oferece acesso de shell completo equivalente ao SSH para aplicação de patches.
O erro de raciocínio nos distratores A e B é tratar a modificação do NSG como caminho obrigatório, ignorando que o ambiente já possui uma solução de acesso alternativo implantada e funcional.
Árvore de Troubleshooting: Verify IP Flow
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (raiz) |
| Azul | Pergunta diagnóstica |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Para usar a árvore diante de um problema real, comece pelo nó raiz e responda cada pergunta com base no que você observa no ambiente. O primeiro passo é sempre verificar se existe um NSG associado antes de executar o teste. Em seguida, confirme que os parâmetros do Verify IP flow estão corretos, especialmente a direção do fluxo. Leia o resultado e siga o caminho correspondente: se Deny, identifique se é uma regra padrão ou customizada; se Allow mas o problema persiste, siga para a investigação de camadas além do NSG. Cada caminho termina em uma causa nomeada ou em uma ação concreta a executar.