Pular para o conteúdo principal

Laboratório de Troubleshooting: Troubleshoot Network Connectivity

Cenários de Diagnóstico​

Cenário 1 — Causa Raiz​

Uma VM Windows hospedada na subnet prod-app de uma VNet na região East US está inacessível via RDP (porta 3389) a partir da rede corporativa. A equipe relata que a VM estava funcionando normalmente até ontem à tarde, quando um colega realizou uma atualização de segurança no NSG da subnet.

O administrador verifica o estado da VM no portal e confirma que ela está Running. O diagnóstico de boot não apresenta erros. O IP público associado à NIC da VM está ativo e responde a ping.

A saída do IP Flow Verify retorna o seguinte:

Access : Deny
RuleName : DenyAllInbound
Direction : Inbound
Protocol : TCP
SourcePort : *
DestinationPort : 3389

O administrador também nota que o NSG associado à NIC da VM possui a seguinte regra:

Priority : 100
Name     : Allow-RDP-NIC
Access   : Allow
Protocol : TCP
Direction: Inbound
Source   : 203.0.113.0/24 (rede corporativa)
DestPort : 3389

Qual é a causa raiz da inacessibilidade via RDP?

A) O IP público da VM está sendo roteado por uma rota inválida, impedindo que os pacotes cheguem à NIC antes da avaliação do NSG.

B) O NSG da subnet não possui regra de permissão para a porta 3389, e como o IP Flow Verify avalia o NSG da subnet antes do NSG da NIC, o tráfego é negado antes de atingir a regra permissiva da NIC.

C) A regra Allow-RDP-NIC no NSG da NIC está configurada com um intervalo de IP de origem incorreto que não cobre a rede corporativa.

D) O Windows Firewall da VM está bloqueando o tráfego de RDP após a atualização de segurança aplicada ontem.

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

A equipe de infraestrutura identificou que uma VM de produção, responsável por processar pedidos em tempo real, perdeu conectividade com o banco de dados hospedado em outra VNet. A causa foi confirmada: o VNet Peering entre as duas VNets foi acidentalmente removido por um script de automação executado há 20 minutos. O banco de dados está saudável e acessível a partir de outras VMs.

O sistema de pedidos está degradado, mas ainda operacional via cache local. O SLA prevê janela de manutenção apenas aos domingos. O engenheiro responsável possui a role Network Contributor na subscription.

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

A) Abrir um ticket de emergência para a equipe de segurança revisar o script de automação antes de recriar o peering, pois a remoção pode ter sido intencional.

B) Recriar imediatamente o VNet Peering entre as duas VNets, configurando os parâmetros de acordo com o estado anterior documentado, sem aguardar a janela de manutenção.

C) Aguardar a janela de manutenção do domingo para recriar o peering, pois alterações em conectividade de rede em produção fora da janela podem causar impacto adicional.

D) Adicionar uma rota estática temporária nas Route Tables das duas VNets apontando para os prefixos de endereço um do outro, contornando a necessidade do peering.

Cenário 3 — Causa Raiz​

Uma VM Linux na subnet data-subnet passou a receber erros ao tentar acessar o Azure Storage Account via endpoint público. O administrador confirma que o Storage Account está acessível a partir da sua máquina local e que outras VMs em subnets diferentes da mesma VNet conseguem acessá-lo normalmente.

A VM em questão foi recentemente migrada da subnet old-subnet para a data-subnet sem alterações nas configurações de rede da própria VM. O administrador verifica e confirma que a data-subnet possui um Service Endpoint habilitado para Microsoft.Storage.

O erro retornado na VM é:

curl https://mystorageaccount.blob.core.windows.net/container/file.txt
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to
mystorageaccount.blob.core.windows.net:443

O administrador também verifica que a Route Table associada à data-subnet contém a seguinte entrada criada automaticamente pelo Service Endpoint:

Prefixo : Storage.EastUS
NextHop : VirtualNetworkServiceEndpoint

O Storage Account possui a seguinte configuração de firewall:

Public network access : Enabled from selected virtual networks and IP addresses
Virtual networks      : old-subnet (VNet: prod-vnet)
IP rules              : (nenhum)

Qual é a causa raiz do problema?

A) O Service Endpoint habilitado na data-subnet está causando um conflito de roteamento com a rota padrão de saída para a internet, impedindo que o tráfego TLS seja estabelecido corretamente.

B) A configuração de firewall do Storage Account ainda autoriza apenas a old-subnet, e a VM agora origina o tráfego pela data-subnet, que não está na lista de redes permitidas.

C) A VM precisa ser reiniciada após a migração de subnet para que o Service Endpoint da nova subnet seja reconhecido pela pilha de rede do sistema operacional.

D) O erro SSL indica que o certificado do Storage Account expirou, o que é independente das configurações de rede e subnet.

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

Uma VM na subnet frontend-subnet não consegue alcançar uma API externa na internet via HTTPS (porta 443). A VM possui IP público associado à sua NIC. O ambiente utiliza uma Route Table customizada associada à frontend-subnet. Não houve alterações relatadas recentemente.

Os seguintes passos de investigação estão disponíveis, fora de ordem:

  1. Verificar se existe uma rota 0.0.0.0/0 na Route Table com next hop válido para tráfego de saída
  2. Usar o Connection Troubleshoot do Network Watcher para testar a conectividade da VM até o endpoint externo na porta 443
  3. Verificar se o NSG da subnet e da NIC possuem regras de saída que permitam o tráfego para a porta 443
  4. Confirmar que a VM está no estado Running e que o agente do Network Watcher está instalado e ativo
  5. Analisar o resultado do Connection Troubleshoot e identificar se o problema está em NSG, rota ou no destino

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

A) 1 → 3 → 2 → 4 → 5

B) 4 → 2 → 5 → 3 → 1

C) 2 → 4 → 1 → 3 → 5

D) 4 → 3 → 1 → 2 → 5

Gabarito e Explicações​

Gabarito — Cenário 1​

Resposta: B

O IP Flow Verify avalia os NSGs na seguinte ordem para tráfego de entrada: primeiro o NSG da subnet, depois o NSG da NIC. Se o NSG da subnet não possui nenhuma regra explícita de permissão para a porta 3389, a regra padrão DenyAllInbound (prioridade 65500) é aplicada, e o tráfego é descartado antes mesmo de ser avaliado pelo NSG da NIC. A saída do IP Flow Verify confirma isso: o nome da regra responsável pelo bloqueio é DenyAllInbound, que pertence ao NSG da subnet.

A pista decisiva no enunciado é que o colega atualizou o NSG da subnet, não da NIC, e que o IP Flow Verify cita a regra DenyAllInbound sem indicar o nome de uma regra customizada.

A alternativa D representa o erro de raciocínio mais perigoso: o administrador poderia conectar via console ou Bastion para inspecionar o Windows Firewall, perdendo tempo com a camada errada. O Windows Firewall só seria relevante se o NSG estivesse permitindo o tráfego e a conexão ainda falhasse. A informação sobre o ping respondendo ao IP público é irrelevante: ping usa ICMP, não TCP 3389, e não valida nada sobre a política de RDP.

Gabarito — Cenário 2​

Resposta: B

A causa já está identificada e confirmada: o peering foi removido acidentalmente. O sistema está degradado, mas não completamente parado. A role Network Contributor é suficiente para recriar peerings. Nenhuma das restrições do cenário impede a ação imediata: o SLA menciona janela de manutenção para mudanças planejadas, não para restauração de conectividade perdida por acidente.

Aguardar a janela de domingo (alternativa C) seria a consequência mais grave, pois o sistema operaria em modo degradado por dias sem necessidade. A alternativa A ignora que a causa já foi confirmada como acidental (o script de automação executou inadvertidamente) e introduz um atraso sem justificativa técnica.

A alternativa D representa uma solução tecnicamente inválida para substituir peering: rotas estáticas entre VNets sem peering não estabelecem conectividade, pois o plano de dados do Azure exige que o peering exista para que o roteamento entre VNets funcione. Essa alternativa é o distrator mais perigoso por parecer uma solução de contorno legítima.

Gabarito — Cenário 3​

Resposta: B

O Service Endpoint redireciona o tráfego da subnet para o serviço via backbone do Azure, mas o firewall do Storage Account controla quais subnets têm acesso autorizado. A VM foi migrada para a data-subnet, mas o firewall do Storage Account ainda lista apenas a old-subnet como rede permitida. O tráfego chega ao Storage Account vindo da data-subnet, que não está autorizada, resultando em rejeição.

O erro SSL apresentado na VM é um sintoma de conexão recusada ou resetada pelo lado do servidor, não um erro de certificado. Esse detalhe é propositalmente enganoso para induzir o leitor à alternativa D. A rota VirtualNetworkServiceEndpoint na Route Table confirma que o Service Endpoint está corretamente configurado na subnet, eliminando a alternativa A.

A informação de que outras VMs em subnets diferentes conseguem acessar o Storage é irrelevante para o diagnóstico: essas subnets podem ou não estar na lista de permissões, e o cenário não especifica. O foco correto é a comparação entre a subnet de onde a VM agora origina tráfego e a lista de subnets autorizadas no firewall do Storage Account.

Gabarito — Cenário 4​

Resposta: B

A sequência correta é: 4 → 2 → 5 → 3 → 1.

O raciocínio diagnóstico progressivo segue esta lógica:

  • Passo 4: Antes de usar qualquer ferramenta de diagnóstico do Network Watcher, é necessário confirmar que a VM está Running e que o agente está ativo. Sem o agente, o Connection Troubleshoot falhará com erro de infraestrutura, não de rede.
  • Passo 2: Com o agente confirmado, executa-se o Connection Troubleshoot diretamente para o endpoint externo na porta 443. Essa ferramenta agrega múltiplas verificações em uma única execução.
  • Passo 5: Analisa-se o resultado. Se o problema for identificado como NSG ou rota, a investigação se aprofunda nessa camada específica.
  • Passo 3: Com o resultado apontando para NSG, verificam-se as regras de saída do NSG da subnet e da NIC.
  • Passo 1: Se o NSG estiver correto, verifica-se a Route Table para identificar se o next hop da rota 0.0.0.0/0 é válido.

A alternativa D parece razoável, mas inverte a lógica ao verificar NSG e rota manualmente antes de usar a ferramenta diagnóstica que já faz essa análise de forma integrada, duplicando esforço e aumentando o risco de erro humano na leitura das regras.

Árvore de Troubleshooting: Troubleshoot Network Connectivity​

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

Legenda de cores:

  • Azul escuro: sintoma inicial, ponto de entrada da investigação
  • Azul: pergunta diagnóstica, decisão baseada em observação
  • Vermelho: causa identificada
  • Verde: ação corretiva ou estado de resolução
  • Laranja: validação intermediária ou ferramenta de diagnóstico

Para usar esta árvore diante de um problema real, comece pelo nó raiz e responda cada pergunta com base no que é observável no ambiente: estado da VM no portal, resultado do IP Flow Verify, configuração das Route Tables, lista de subnets no firewall do serviço, e status do VNet Peering. Cada resposta elimina um conjunto de hipóteses e direciona para a causa com o menor número de passos possível. Nunca pule a verificação de estado da VM antes de acionar ferramentas de diagnóstico de rede.