Pular para o conteúdo principal

Laboratório de Troubleshooting: Create a network security group (NSG)

Cenários de Diagnóstico​

Cenário 1 — Causa Raiz​

Uma equipe de operações reporta que uma VM de produção parou de responder a conexões SSH (porta 22) vindas de um servidor de bastion interno com IP 10.1.0.5. A VM está em uma sub-rede chamada snet-backend na VNet vnet-prod.

O engenheiro de plantão verifica a configuração e coleta as seguintes informações:

NSG associado à sub-rede snet-backend:

Regras de entrada:
Prioridade | Nome               | Origem       | Porta | Ação
-----------|--------------------|--------------|-------|------
100        | Allow-SSH-Bastion  | 10.1.0.0/24  | 22    | Allow
300        | Allow-HTTPS        | *            | 443   | Allow
65000      | AllowVnetInBound   | VirtualNet.  | *     | Allow
65500      | DenyAllInBound     | *            | *     | Deny

NSG associado à NIC da VM:

Regras de entrada:
Prioridade | Nome               | Origem       | Porta | Ação
-----------|--------------------|--------------|-------|------
150        | Deny-SSH           | *            | 22    | Deny
65000      | AllowVnetInBound   | VirtualNet.  | *     | Allow
65500      | DenyAllInBound     | *            | *     | Deny

O engenheiro também verifica que a VM está em execução, o serviço SSH está ativo e o disco não apresenta alertas. O grupo de recursos foi criado há três dias como parte de uma nova implantação.

Qual é a causa raiz da falha de conectividade?

A) A regra Allow-SSH-Bastion no NSG da sub-rede usa o prefixo 10.1.0.0/24, que não abrange o IP 10.1.0.5, causando bloqueio no primeiro nível de avaliação.

B) A regra Deny-SSH no NSG da NIC, com prioridade 150, nega o tráfego SSH após o NSG da sub-rede permitir a conexão, bloqueando o acesso antes de alcançar a VM.

C) O serviço SSH da VM não está acessível porque a implantação recente pode ter introduzido uma configuração incorreta no sistema operacional.

D) A regra AllowVnetInBound com prioridade 65000 no NSG da NIC sobrepõe a regra Deny-SSH porque tags de serviço têm precedência sobre regras baseadas em porta.

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

A causa foi identificada: um NSG associado a uma sub-rede de produção contém uma regra com prioridade 200 que nega todo o tráfego de saída com destino ao intervalo 10.2.0.0/16. Esse intervalo corresponde à sub-rede de banco de dados em outra VNet conectada via peering. Todas as aplicações na sub-rede pararam de se comunicar com os bancos de dados há aproximadamente 40 minutos.

O ambiente opera em horário de pico. O time de banco de dados confirmou que os servidores estão operacionais. O engenheiro tem permissão de Contribuidor no grupo de recursos que contém o NSG. A equipe de segurança ainda não foi notificada sobre a mudança que originou o problema.

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

A) Remover imediatamente a regra de negação do NSG, restaurar a conectividade e notificar a equipe de segurança após a normalização.

B) Criar uma nova regra de saída com prioridade 100, origem *, destino 10.2.0.0/16, porta *, ação Allow, para sobrepor a regra de negação sem removê-la, e notificar a equipe de segurança em paralelo.

C) Aguardar a notificação e aprovação formal da equipe de segurança antes de qualquer alteração, pois a regra pode ter sido criada intencionalmente como controle de segurança.

D) Desassociar o NSG da sub-rede temporariamente para restaurar o tráfego enquanto a análise da regra é conduzida.

Cenário 3 — Causa Raiz​

Um desenvolvedor relata que uma VM recém-provisionada na sub-rede snet-app não consegue acessar um serviço externo na porta 443. O NSG associado à NIC da VM foi criado ontem e não possui nenhuma regra de saída personalizada. A saída do comando executado na VM é:

$ curl -v https://api.exemplo.com
* Trying 203.0.113.45:443...
* connect to 203.0.113.45 port 443 failed: Connection timed out
* Failed to connect to api.exemplo.com port 443 after 130004 ms
curl: (28) Connection timed out after 130003 milliseconds

O engenheiro verifica que a VM possui IP público atribuído. Ele também confirma que não há Azure Firewall nem User Defined Routes (UDR) configurados na sub-rede. O NSG da sub-rede snet-app possui as seguintes regras de saída:

Prioridade | Nome                  | Destino   | Porta | Ação
-----------|-----------------------|-----------|-------|------
100        | Deny-Internet-Egress  | Internet  | *     | Deny
65000      | AllowVnetOutBound     | VNet.     | *     | Allow
65001      | AllowInternetOutBound | Internet  | *     | Allow
65500      | DenyAllOutBound       | *         | *     | Deny

O desenvolvedor sugere que o timeout indica um problema de DNS. A equipe de rede menciona que o IP público da VM foi atribuído ontem mesmo.

Qual é a causa raiz do problema?

A) O IP público atribuído à VM foi provisionado recentemente e ainda não propagou corretamente, impedindo o roteamento de saída para a internet.

B) A ausência de regras de saída personalizadas no NSG da NIC faz com que o tráfego de saída seja bloqueado por padrão, pois o comportamento padrão é negar tudo.

C) A regra Deny-Internet-Egress com prioridade 100 no NSG da sub-rede bloqueia todo o tráfego de saída com destino à tag Internet, sobrepondo a regra padrão AllowInternetOutBound.

D) O timeout na porta 443 indica que o problema é de resolução DNS, pois o endereço IP de destino está sendo resolvido incorretamente dentro da VNet.

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

Uma VM em produção não está recebendo tráfego HTTP (porta 80) de clientes externos. O engenheiro responsável tem acesso ao portal do Azure e à VM. Abaixo estão cinco passos de investigação possíveis, apresentados fora de ordem:

[P] Verificar se a aplicação web está em execução e escutando na porta 80 dentro da VM
[Q] Usar a funcionalidade "Verificar fluxo de IP" (IP Flow Verify) no Network Watcher para testar se o NSG bloqueia o tráfego de entrada na porta 80
[R] Verificar se há NSG associado tanto à NIC quanto à sub-rede da VM e listar todas as regras de entrada de ambos
[S] Confirmar que a VM está em execução e acessível via portal do Azure
[T] Revisar os logs de fluxo do NSG (NSG Flow Logs) para identificar se pacotes foram efetivamente bloqueados e por qual regra

Qual é a sequência correta de investigação diagnóstica?

A) S -> R -> Q -> T -> P

B) Q -> R -> T -> S -> P

C) R -> Q -> S -> T -> P

D) S -> Q -> R -> P -> T

Gabarito e Explicações​

Gabarito — Cenário 1​

Resposta: B

Explicação:

  • A pista determinante está na configuração do NSG da NIC: a regra Deny-SSH com prioridade 150 nega todo o tráfego na porta 22 independente da origem. Para tráfego de entrada, o Azure avalia o NSG da sub-rede primeiro e, em seguida, o NSG da NIC. O NSG da sub-rede permite o tráfego do bastion (prioridade 100, 10.1.0.0/24 abrange 10.1.0.5), mas o NSG da NIC o nega na sequência. O tráfego não alcança a VM.
  • A informação irrelevante neste cenário é o fato de o grupo de recursos ter sido criado há três dias e o serviço SSH estar ativo na VM. Esses dados são plausíveis como pistas, mas não influenciam o diagnóstico uma vez que a cadeia de avaliação de NSGs explica o bloqueio de forma completa.
  • A alternativa A é um distrator que força o leitor a recalcular o CIDR: 10.1.0.0/24 abrange todos os endereços de 10.1.0.0 a 10.1.0.255, então 10.1.0.5 está dentro do intervalo. Esse erro de cálculo é comum sob pressão. A alternativa D representa um equívoco grave: tags de serviço não têm precedência especial sobre regras baseadas em porta; a avaliação é estritamente por número de prioridade.
  • O distrator mais perigoso é o C: agir com base nele levaria o engenheiro a investigar a VM por tempo indefinido sem encontrar problema algum, enquanto o tráfego permanece bloqueado pelo NSG da NIC.

Gabarito — Cenário 2​

Resposta: B

Explicação:

  • A restrição crítica do cenário é a combinação de dois fatores: ambiente em horário de pico (impacto ativo em produção) e incerteza sobre a intencionalidade da regra (a equipe de segurança não foi consultada). Remover a regra imediatamente (alternativa A) restaura o serviço, mas desfaz uma alteração que pode ter sido intencional sem validação prévia com o time responsável. Criar uma regra de sobreposição com prioridade 100 (alternativa B) restaura o tráfego de forma imediata e reversível, mantendo a regra original intacta para análise posterior e notificando a equipe de segurança em paralelo. Essa abordagem equilibra urgência operacional com responsabilidade de governança.
  • A alternativa C ignora a criticidade do impacto em produção: aguardar aprovação formal enquanto aplicações estão falhando há 40 minutos é inaceitável operacionalmente sem ao menos escalar de forma urgente.
  • A alternativa D é a mais perigosa: desassociar o NSG da sub-rede remove todas as regras de segurança, expondo potencialmente outros recursos da sub-rede que dependem das demais regras do NSG para proteção. Essa ação resolve o sintoma imediato criando um problema de segurança mais amplo.

Gabarito — Cenário 3​

Resposta: C

Explicação:

  • A chave diagnóstica está nas regras de saída do NSG da sub-rede: a regra Deny-Internet-Egress com prioridade 100 nega todo o tráfego com destino à tag Internet. Essa regra tem prioridade maior que AllowInternetOutBound (prioridade 65001), que é a regra padrão que normalmente permitiria o acesso à internet. O NSG da NIC sem regras personalizadas utiliza apenas as regras padrão, que incluem AllowInternetOutBound, mas a avaliação para tráfego de saída começa pelo NSG da NIC e depois passa ao NSG da sub-rede. O NSG da NIC permite o tráfego, mas o NSG da sub-rede o bloqueia.
  • As informações irrelevantes são o IP público da VM e a ausência de Azure Firewall e UDR. Ambos são dados plausíveis que direcionam o raciocínio para caminhos errados, mas não têm relação com o bloqueio efetivo.
  • A alternativa B representa um erro clássico: o comportamento padrão do NSG para saída não é negar tudo. As regras padrão AllowVnetOutBound e AllowInternetOutBound estão presentes em todo NSG. A alternativa D acolhe a sugestão do desenvolvedor sobre DNS sem base técnica: o timeout indica que os pacotes estão saindo e não recebendo resposta (ou sendo bloqueados no caminho), não que o DNS falhou. Adotar essa hipótese levaria a uma investigação de DNS completamente infrutífera.

Gabarito — Cenário 4​

Resposta: A

Explicação:

  • A sequência correta de diagnóstico segue o princípio de progressão do mais simples e abrangente para o mais específico e custoso. O passo S confirma que a VM está operacional antes de qualquer análise de rede, evitando investigar NSGs quando o problema pode ser trivial. O passo R mapeia todas as regras existentes em ambos os NSGs, criando visibilidade completa antes de qualquer teste. O passo Q usa o IP Flow Verify para validar objetivamente se o NSG é a causa do bloqueio, sem ambiguidade. O passo T acessa os logs de fluxo para confirmar qual regra específica está atuando, caso Q indique bloqueio. O passo P verifica a aplicação dentro da VM, relevante apenas se os passos anteriores descartarem o NSG como causa.
  • A alternativa B começa pelo IP Flow Verify antes de confirmar que a VM está em execução, o que pode gerar falsos resultados ou desperdício de esforço se a VM estiver desligada. A alternativa C começa por listar regras sem validar o estado da VM, o que também pode ser infrutífero. A alternativa D pula de Q diretamente para a aplicação sem validar com logs, o que impede a identificação precisa da regra responsável caso o NSG seja a causa.
  • O erro de raciocínio mais comum que os distratores exploram é a inversão entre validação de infraestrutura (NSG) e validação de aplicação: investigar a aplicação antes de descartar causas de rede é uma das fontes mais frequentes de diagnósticos prolongados.

Árvore de Troubleshooting: Create a network security group (NSG)​

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

Legenda de cores:

CorTipo de nó
Azul escuroSintoma inicial (ponto de entrada)
AzulPergunta diagnóstica (decisão de investigação)
LaranjaVerificação intermediária (validação antes de concluir)
VermelhoCausa identificada
VerdeAção recomendada ou resolução

Diante de um problema real, comece pelo nó raiz identificando o sintoma de tráfego bloqueado e percorra as ramificações respondendo cada pergunta com base no que é observável diretamente: estado da VM, existência de NSG associado, resultado do IP Flow Verify, direção do tráfego afetado e presença de regras de negação com prioridade dominante. Cada bifurcação elimina uma classe de causas até que o caminho convirja em uma causa identificada e uma ação concreta, evitando intervenções prematuras baseadas em hipóteses não validadas.