Pular para o conteúdo principal

Laboratório de Troubleshooting: Associate a NSG to a Resource

Cenários de Diagnóstico​

Cenário 1 — Causa Raiz​

A equipe de operações relata que uma VM chamada vm-web-prod parou de responder a requisições HTTP na porta 80, mas continua acessível via SSH na porta 22. A VM está em execução, o serviço web está ativo no sistema operacional e os logs da aplicação não mostram erros. A VM está na sub-rede snet-frontend, que pertence à VNet vnet-prod na região eastus2.

Durante a investigação, um analista observou que o endereço IP público da VM foi atualizado ontem devido a uma realocação. Além disso, a VM tem uma única NIC chamada nic-web-prod.

O administrador executa o seguinte comando e obtém esta saída:

az network nic show \
  --name nic-web-prod \
  --resource-group rg-prod \
  --query "networkSecurityGroup"
null

Em seguida, verifica o NSG da sub-rede:

az network vnet subnet show \
  --name snet-frontend \
  --vnet-name vnet-prod \
  --resource-group rg-prod \
  --query "networkSecurityGroup"
{
  "id": "/subscriptions/.../networkSecurityGroups/nsg-frontend"
}

As regras do nsg-frontend são:

Inbound Rules:
Prioridade 100 | TCP | Porta 22 | Allow
Prioridade 200 | TCP | Porta 443 | Allow
Prioridade 65500 | Any | Any | Deny (DenyAllInBound)

Qual é a causa raiz da falha no acesso à porta 80?

A) O endereço IP público foi realocado e o DNS ainda não propagou a atualização, impedindo requisições externas de chegar à VM.

B) O NSG associado à sub-rede não possui regra de entrada permitindo tráfego na porta 80, e nenhum NSG está associado à NIC.

C) A NIC nic-web-prod não está associada a nenhum NSG, portanto todo o tráfego de entrada está sendo bloqueado por padrão.

D) A regra de prioridade 65500 do nsg-frontend está bloqueando especificamente a porta 80, pois ela tem precedência sobre regras implícitas.

Cenário 2 — Decisão de Ação​

A causa do problema a seguir já foi identificada pela equipe: um NSG chamado nsg-api foi associado acidentalmente à sub-rede snet-shared, que hospeda tanto a camada de API quanto um serviço de monitoramento interno crítico. O nsg-api possui uma regra de entrada que bloqueia todo o tráfego na porta 9090, utilizada exclusivamente pelo agente de monitoramento. O ambiente está em produção com SLA ativo, e qualquer interrupção de serviço deve ser evitada. A equipe tem permissão de Contributor no grupo de recursos, mas não tem acesso ao recurso de Policy do tenant.

O gerente solicita que o problema seja resolvido sem remover o nsg-api da sub-rede, pois ele também protege as APIs com regras de bloqueio que levaram semanas para ser auditadas e aprovadas.

Qual é a ação correta a tomar neste momento?

A) Remover o nsg-api da sub-rede, aplicar um novo NSG apenas às NICs das VMs de API, e recriar todas as regras auditadas no novo NSG.

B) Adicionar uma nova regra de entrada no nsg-api permitindo tráfego na porta 9090 com prioridade mais alta do que qualquer regra de bloqueio existente.

C) Criar um novo NSG exclusivo para o agente de monitoramento, desassociar o nsg-api da sub-rede e associar ambos os NSGs simultaneamente à sub-rede.

D) Associar um segundo NSG à NIC da VM do agente de monitoramento, com uma regra Allow na porta 9090 de prioridade mais alta do que as regras do nsg-api.

Cenário 3 — Causa Raiz​

Uma VM chamada vm-db-01 está na sub-rede snet-data e possui duas NICs: nic-primary (conectada à snet-data) e nic-mgmt (conectada à sub-rede snet-mgmt). O time de DBA relata que conexões ao banco de dados na porta 1433 estão falhando a partir de VMs na snet-app, mas funcionam normalmente quando testadas a partir da snet-mgmt.

O administrador coleta as seguintes informações:

NSG associado à snet-data: nsg-data
NSG associado à snet-app: nsg-app
NSG associado à nic-primary: nenhum
NSG associado à nic-mgmt: nsg-mgmt

Regras de entrada do nsg-data:

Prioridade 100 | TCP | Porta 1433 | Source: VirtualNetwork | Allow
Prioridade 200 | TCP | Porta 22   | Source: 10.2.0.0/24   | Allow
Prioridade 65500 | Any | Any | Deny

Regras de saída do nsg-app:

Prioridade 100 | TCP | Porta 1433 | Destination: 10.3.0.0/24 | Allow
Prioridade 65500 | Any | Any | Deny

A tag VirtualNetwork abrange endereços de todas as VNets conectadas por peering. A snet-app está em uma VNet diferente da snet-data, e as duas VNets estão conectadas via peering configurado corretamente. O time afirma que a falha começou após uma mudança de configuração de rede realizada na semana passada.

Qual é a causa raiz mais provável?

A) O peering entre as VNets não foi configurado corretamente, impedindo que o tráfego da snet-app alcance a snet-data.

B) A regra de saída do nsg-app usa um prefixo de destino incorreto, bloqueando o tráfego antes de sair das VMs de aplicação.

C) A tag VirtualNetwork no nsg-data não abrange endereços de VNets em peering quando o peering foi configurado após a criação do NSG, fazendo com que o tráfego seja bloqueado pela regra Deny.

D) O nsg-app possui uma regra de saída que permite tráfego na porta 1433, mas não existe uma regra de entrada correspondente no nsg-data para o range de IP da snet-app de forma explícita.

Cenário 4 — Sequência de Diagnóstico​

Um analista recebe o seguinte relato: "VMs na sub-rede snet-backend não conseguem se comunicar com um serviço externo na porta 443. O tráfego de saída parece estar bloqueado."

Os passos de investigação disponíveis são:

  1. Verificar se existe uma regra de saída Allow para a porta 443 no NSG associado à sub-rede.
  2. Confirmar se há um NSG associado à sub-rede snet-backend usando az network vnet subnet show.
  3. Verificar se existe uma regra de saída Allow para a porta 443 nos NSGs associados às NICs das VMs afetadas.
  4. Usar o recurso Network Watcher IP Flow Verify para confirmar qual NSG e qual regra está bloqueando o tráfego.
  5. Verificar se a rota padrão da sub-rede aponta para um NVA ou firewall que possa estar descartando o tráfego antes do NSG.

Qual é a sequência correta de diagnóstico progressivo?

A) 2 → 1 → 3 → 4 → 5

B) 4 → 2 → 1 → 3 → 5

C) 1 → 2 → 4 → 3 → 5

D) 2 → 3 → 1 → 5 → 4

Gabarito e Explicações​

Gabarito — Cenário 1​

Resposta: B

Explicação:

  • A saída do comando confirma que a NIC não tem NSG associado. Portanto, o único NSG avaliado para tráfego de entrada é o da sub-rede snet-frontend. As regras desse NSG permitem explicitamente apenas as portas 22 e 443. Como não há regra Allow para a porta 80, a regra padrão DenyAllInBound (prioridade 65500) bloqueia esse tráfego.
  • A pista determinante está nas regras do nsg-frontend: porta 80 simplesmente não existe como entrada permitida.
  • A informação irrelevante é a realocação do IP público. Ela não afeta as regras de NSG e não explica por que a porta 22 continua funcionando enquanto a 80 não.
  • A alternativa C é o distrator mais perigoso: ela afirma que a ausência de NSG na NIC bloqueia tudo por padrão. Isso está errado. Quando não há NSG na NIC, o tráfego não é bloqueado por essa camada; apenas o NSG da sub-rede é aplicado. Agir com base nessa premissa levaria a associar um NSG desnecessário à NIC sem corrigir a regra faltante.

Gabarito — Cenário 2​

Resposta: B

Explicação:

  • A restrição central do cenário é clara: o nsg-api não pode ser removido da sub-rede, pois contém regras auditadas que levaram semanas para ser aprovadas. A solução deve preservar o NSG existente e sua posição de associação.
  • Adicionar uma regra Allow para a porta 9090 com prioridade mais alta do que qualquer regra de bloqueio existente resolve o problema sem remover o NSG, sem recriar regras e sem introduzir uma segunda associação de NSG à sub-rede, que não é possível.
  • A alternativa D parece plausível, mas possui um erro crítico de raciocínio: o NSG na NIC e o NSG na sub-rede são camadas independentes. Em tráfego de entrada, o NSG da sub-rede é avaliado primeiro. Se ele bloqueia a porta 9090, o tráfego nunca alcança a NIC para que o NSG dela possa permitir. Portanto, a alternativa D não resolveria o problema.
  • A alternativa C é tecnicamente inválida: não é possível associar dois NSGs à mesma sub-rede simultaneamente no Azure.

Gabarito — Cenário 3​

Resposta: D

Explicação:

  • A regra de entrada do nsg-data usa a tag VirtualNetwork como source. Essa tag, no Azure, inclui o espaço de endereço da própria VNet e de VNets conectadas por peering. Portanto, tráfego da snet-app deveria ser coberto por essa regra, descartando a alternativa C.
  • O peering está "configurado corretamente" conforme o enunciado, descartando a alternativa A.
  • O ponto crítico está na camada de saída do nsg-app: a regra de saída permite tráfego para 10.3.0.0/24 na porta 1433. Se o prefixo da snet-data não for exatamente 10.3.0.0/24, o tráfego não corresponde à regra Allow e é bloqueado pela regra Deny de saída antes mesmo de sair das VMs de aplicação.
  • A pista está na afirmação de que a falha começou após uma "mudança de configuração de rede", o que sugere alteração em regras ou endereçamento, não no mecanismo de peering em si.
  • O distrator mais perigoso é a alternativa C, pois apresenta um comportamento falso mas tecnicamente sofisticado sobre o comportamento da tag VirtualNetwork e a criação do NSG.

Gabarito — Cenário 4​

Resposta: A

Explicação:

  • O raciocínio diagnóstico correto segue do mais simples e estrutural para o mais específico e ferramental.
  • Passo 2 vem primeiro: confirmar se há um NSG associado à sub-rede é o pré-requisito para qualquer investigação de regras. Sem essa confirmação, os passos seguintes podem ser aplicados ao objeto errado.
  • Passo 1 vem em seguida: verificar as regras de saída do NSG da sub-rede, pois ela é a primeira camada avaliada no tráfego de saída.
  • Passo 3 cobre a segunda camada: NSGs nas NICs individuais das VMs afetadas.
  • Passo 4 usa o Network Watcher para confirmar instrumentalmente qual regra está bloqueando, após ter mapeado as hipóteses via inspeção manual.
  • Passo 5 avalia a camada de roteamento, que é independente de NSG e representa uma causa alternativa caso os NSGs não sejam o problema.
  • A alternativa B começa pela ferramenta de diagnóstico antes de entender o que existe na configuração, o que é uma prática ineficiente em ambientes complexos.

Árvore de Troubleshooting: Associate a NSG to a Resource​

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

Legenda de cores:

CorTipo de nó
Azul escuroSintoma inicial (ponto de entrada)
Azul médioPergunta diagnóstica
VermelhoCausa identificada
VerdeAção recomendada ou resolução
LaranjaValidação ou verificação intermediária

Diante de um problema real, comece pelo nó raiz descrevendo o sintoma de tráfego bloqueado. Siga as perguntas de diagnóstico respondendo sim ou não com base no que você observa no ambiente: verifique primeiro se há NSG associado, depois identifique o tipo de recurso e a direção do tráfego. Cada ramificação leva a uma causa concreta ou a uma ação de remediação. Quando o caminho chegar a um nó de validação intermediária (laranja), use ferramentas como o Network Watcher para confirmar a hipótese antes de agir.