Pular para o conteúdo principal

Laboratório Técnico: Troubleshoot Network Connectivity

Questões​

Questão 1 — Múltipla Escolha​

Uma equipe de operações relata que uma máquina virtual não consegue alcançar um endpoint externo na internet. A VM está em uma subnet associada a uma Route Table com a seguinte configuração:

Prefixo de destinoPróximo salto
0.0.0.0/0VirtualAppliance
10.0.0.0/8VnetLocal

O endereço IP configurado como next hop para a rota 0.0.0.0/0 pertence a uma NVA (Network Virtual Appliance) que foi desalocada há dois dias.

Qual é a causa raiz do problema?

A) A subnet não possui um Network Security Group associado, bloqueando o tráfego de saída por padrão.

B) A rota padrão aponta para uma NVA que não está respondendo, descartando o tráfego antes de atingir o gateway da VNet.

C) A ausência de uma rota explícita para 0.0.0.0/0 com next hop Internet impede qualquer tráfego de saída.

D) O Azure bloqueia automaticamente o tráfego de saída para a internet quando uma NVA é desalocada e a rota não é removida.

Questão 2 — Cenário Técnico​

Um administrador precisa diagnosticar por que uma VM não consegue se comunicar com outra VM na mesma VNet, em uma subnet diferente. Ele executa o seguinte comando:

az network watcher check-connectivity \
  --source-resource /subscriptions/.../virtualMachines/vm-origem \
  --dest-address 10.1.2.4 \
  --dest-port 443

O resultado retorna Unreachable com issues indicando NetworkSecurityRule. O administrador examina o NSG associado à subnet de destino e não encontra nenhuma regra de negação explícita para a porta 443.

Qual é a causa mais provável do bloqueio?

A) O Network Watcher não consegue inspecionar tráfego entre subnets da mesma VNet, tornando o resultado inválido.

B) Existe uma regra de negação explícita na NIC da VM de destino que tem precedência sobre as regras da subnet.

C) A regra padrão DenyAllInbound está sendo aplicada porque nenhuma regra de permissão para a porta 443 existe no NSG, seja da subnet ou da NIC da VM de destino.

D) O tráfego está sendo bloqueado pelo NSG da subnet de origem, que não possui regra de saída explícita para a porta 443.

Questão 3 — Verdadeiro ou Falso​

Um administrador habilita o VNet Peering entre duas VNets na mesma região. Após o peering ser estabelecido com status Connected em ambos os lados, as VMs nas duas VNets ainda não conseguem se comunicar entre si. É verdadeiro afirmar que o peering por si só garante conectividade efetiva entre as VMs, desde que nenhum NSG esteja aplicado às subnets envolvidas.

Questão 4 — Múltipla Escolha​

Um administrador usa o IP Flow Verify do Network Watcher para testar se o tráfego na porta 22 (SSH) é permitido em direção a uma VM. O resultado indica Allow. No entanto, a conexão SSH feita diretamente do terminal ainda falha com timeout.

Qual é a explicação mais precisa para essa discrepância?

A) O IP Flow Verify analisa apenas regras de NSG; outros fatores como o estado do serviço SSH na VM, firewall do sistema operacional ou uma rota inválida podem estar bloqueando a conexão.

B) O IP Flow Verify apresenta resultados inconsistentes quando a VM está em execução há mais de 72 horas sem reinicialização.

C) O resultado Allow do IP Flow Verify indica que o tráfego foi permitido em algum momento, mas não reflete o estado atual das regras do NSG.

D) O IP Flow Verify considera apenas NSGs de subnet; como o NSG da NIC não foi avaliado, ele pode estar bloqueando o tráfego.

Questão 5 — Cenário Técnico​

Uma aplicação hospedada em uma VM na subnet app-subnet precisa acessar o Azure Storage via Service Endpoint. O administrador habilitou o Service Endpoint para Microsoft.Storage na subnet e criou a regra de firewall no Storage Account apontando para a VNet correta. Mesmo assim, a VM ainda recebe erro de acesso negado ao tentar conectar ao Storage.

# Erro observado na VM:
curl: (7) Failed to connect to mystorageaccount.blob.core.windows.net: Connection refused

Após revisar as configurações, o administrador percebe o seguinte:

  • Service Endpoint habilitado em: app-subnet
  • Regra de VNet no Storage Account aponta para: db-subnet

Qual é a correção adequada?

A) Desabilitar e reabilitar o Service Endpoint na app-subnet para forçar a propagação da rota de serviço.

B) Adicionar uma rota estática na Route Table da app-subnet apontando para o prefixo de endereço do Azure Storage.

C) Atualizar a regra de VNet no firewall do Storage Account para referenciar a app-subnet em vez da db-subnet.

D) Habilitar o Service Endpoint também na db-subnet, pois o Azure exige que ambas as subnets tenham o endpoint ativo para o acesso funcionar.

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: B

Quando uma Route Table define uma rota com next hop do tipo VirtualAppliance, o Azure encaminha o tráfego para o IP especificado. Se a NVA estiver desalocada, o IP do next hop deixa de responder, e os pacotes são descartados silenciosamente. O Azure não remove nem invalida automaticamente rotas cujo destino se torna inacessível.

A alternativa C representa um equívoco comum: a ausência de uma rota explícita Internet não é o problema, porque a rota 0.0.0.0/0 existe e está ativa. O problema é para onde ela aponta. A alternativa D é falsa: o Azure não bloqueia tráfego automaticamente com base no estado de uma NVA referenciada em uma rota.

Gabarito — Questão 2​

Resposta: C

Os NSGs possuem regras padrão implícitas que não aparecem listadas como regras explícitas no portal ou na CLI. A regra DenyAllInbound com prioridade 65500 nega todo o tráfego de entrada que não foi explicitamente permitido por regras de menor prioridade. Se nenhuma regra de Allow para a porta 443 existe no NSG da subnet de destino nem no NSG da NIC da VM de destino, essa regra padrão é aplicada.

A alternativa B representa um erro real de diagnóstico: é possível que exista um NSG na NIC, mas a questão afirma que nenhuma regra de negação explícita foi encontrada, o que não descarta a ausência de permissão. A alternativa A é incorreta porque o Network Watcher e o check-connectivity funcionam plenamente entre subnets da mesma VNet.

Gabarito — Questão 3​

Resposta: Falso

O VNet Peering com status Connected estabelece o plano de roteamento entre as VNets, mas não garante conectividade efetiva por si só. Mesmo sem NSGs nas subnets, outros fatores podem bloquear o tráfego: firewall do sistema operacional das VMs, ausência do serviço em escuta na porta de destino, ou rotas mais específicas que desviem o tráfego. Além disso, o peering precisa estar Connected em ambos os lados para o tráfego fluir. A afirmação é tecnicamente incorreta ao usar "garante" sem considerar a pilha completa de conectividade.

Gabarito — Questão 4​

Resposta: A

O IP Flow Verify avalia exclusivamente as regras de NSG aplicadas à VM (tanto da subnet quanto da NIC). Ele não verifica o estado da pilha de rede interna da VM, o firewall do sistema operacional (como iptables ou ufw no Linux, ou o Windows Firewall), nem a validade das rotas de retorno. Um resultado Allow significa apenas que nenhum NSG bloquearia aquele fluxo. O timeout na conexão SSH pode ser causado por qualquer um desses fatores adicionais.

A alternativa D representa um equívoco relevante: o IP Flow Verify avalia NSGs de subnet e de NIC em conjunto, não apenas um dos dois.

Gabarito — Questão 5​

Resposta: C

O mecanismo de Service Endpoint funciona por subnet. A regra de firewall do Storage Account deve referenciar exatamente a subnet a partir da qual o tráfego se origina. Neste cenário, o tráfego parte da app-subnet, mas a regra no Storage Account aponta para a db-subnet, que é uma subnet diferente. O Azure identifica a origem pelo Service Endpoint da subnet de onde o pacote saiu, e como ela não está autorizada no firewall, o acesso é negado.

A alternativa B representa um equívoco comum: Service Endpoints injetam automaticamente rotas de serviço na subnet, dispensando rotas estáticas manuais para os prefixos do serviço. A alternativa D é falsa: não existe requisito de que múltiplas subnets tenham o endpoint habilitado para que uma delas funcione.