Pular para o conteúdo principal

Laboratório de Troubleshooting: Create and configure virtual networks and subnets

Cenários de Diagnóstico​

Cenário 1 — Causa Raiz​

Um administrador está configurando a infraestrutura de rede para um novo ambiente de produção na região East US. A virtual network vnet-prod foi criada há três dias com o espaço de endereçamento 172.16.0.0/16. Duas subnets foram adicionadas posteriormente:

snet-web:  172.16.10.0/24
snet-app:  172.16.20.0/24

Uma VM foi provisionada na snet-web e outra na snet-app. O administrador relata que a VM na snet-web consegue se comunicar normalmente com recursos externos, mas não consegue alcançar a VM na snet-app por IP privado, mesmo com as duas VMs no mesmo resource group e na mesma região.

Informações coletadas durante a investigação:

# Teste de conectividade executado a partir da VM em snet-web
ping 172.16.20.4
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1

# NSG associado à snet-web: nenhuma regra de saída personalizada
# NSG associado à snet-app: nenhuma regra de entrada personalizada
# Effective routes na NIC da VM em snet-web: sem entradas para 172.16.20.0/24

O administrador menciona também que o resource group foi criado com uma policy de tagging obrigatória que ainda não foi aplicada a todos os recursos.

Qual é a causa raiz da falha de comunicação entre as duas VMs?

A) O NSG da snet-app está bloqueando o tráfego de entrada proveniente de outras subnets por padrão. B) O espaço de endereçamento 172.16.0.0/16 não cobre os intervalos das duas subnets, impedindo o roteamento interno. C) A subnet snet-app foi criada após o provisionamento da VNet e não foi associada corretamente ao espaço de endereçamento, resultando em ausência de rota no sistema. D) As subnets snet-web e snet-app não foram adicionadas ao espaço de endereçamento da VNet, e por isso não existe rota de sistema entre elas.

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

A causa do problema foi identificada: o espaço de endereçamento da VNet vnet-hub está configurado como 10.0.0.0/24, mas a equipe precisa adicionar uma nova subnet snet-analytics com o intervalo 10.0.1.0/24 para hospedar um cluster de processamento de dados.

O ambiente tem as seguintes restrições conhecidas:

  • A VNet vnet-hub está em peering ativo com vnet-spoke-01 e vnet-spoke-02
  • Há VMs em produção rodando nas subnets existentes da vnet-hub
  • O peering com vnet-spoke-01 utiliza o espaço 10.1.0.0/16 e com vnet-spoke-02 utiliza 10.2.0.0/16
  • O time de segurança exige aprovação para qualquer alteração que afete conectividade de produção
  • A janela de manutenção programada é em 48 horas

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

A) Adicionar imediatamente o espaço 10.0.0.0/16 à VNet vnet-hub, expandindo o range atual para acomodar a nova subnet. B) Aguardar a janela de manutenção, expandir o espaço de endereçamento da VNet para 10.0.0.0/16 com aprovação do time de segurança e então criar a subnet snet-analytics. C) Recriar a VNet vnet-hub com o espaço correto, migrando os recursos existentes antes da janela de manutenção. D) Criar uma VNet separada com o espaço 10.0.1.0/24 e conectá-la via peering imediatamente, sem impacto nas VMs em produção.

Cenário 3 — Causa Raiz​

Um time de desenvolvimento reporta que uma nova aplicação implantada não consegue resolver nomes DNS internos de outros recursos na mesma VNet. A VNet vnet-dev foi configurada há uma semana. As VMs conseguem acessar a internet normalmente e pingar endereços IP privados de outras VMs sem problema.

Saída coletada de uma das VMs afetadas:

# Resolucao DNS falha para hostname interno
nslookup vm-backend.internal.contoso.com
Server:  168.63.129.16
Address: 168.63.129.16

** server can't find vm-backend.internal.contoso.com: NXDOMAIN

# Ping por IP funciona normalmente
ping 10.5.2.10
Reply from 10.5.2.10: bytes=32 time=1ms TTL=128

# Configuracao de DNS da VNet (via portal)
DNS servers: 10.5.0.5, 10.5.0.6

O administrador informa que os servidores 10.5.0.5 e 10.5.0.6 são instâncias de Windows Server DNS customizadas provisionadas na subnet snet-infra. A VNet foi criada a partir de um template ARM reutilizado de outro projeto. O resource group tem 12 recursos no total.

Qual é a causa raiz da falha de resolução DNS?

A) O Azure DNS padrão (168.63.129.16) está sendo consultado mesmo com servidores customizados configurados, indicando que as VMs não receberam as configurações DNS atualizadas via DHCP. B) Os servidores DNS customizados em 10.5.0.5 e 10.5.0.6 não foram configurados para encaminhar consultas não resolvidas ao Azure DNS, e por isso nomes internos da zona privada não são resolvidos. C) A zona DNS privada do Azure não foi vinculada à VNet vnet-dev, impedindo a resolução de nomes .internal.contoso.com. D) O template ARM reutilizado criou a VNet com configuração de DNS incorreta e a alteração feita no portal ainda não foi propagada para as VMs porque elas não foram reiniciadas.

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

Um administrador recebe o seguinte alerta de um sistema de monitoramento:

"Falha de conectividade detectada entre vnet-onprem-linked e vnet-core. Tráfego de 192.168.10.0/24 não alcança 10.100.5.0/24."

Os dois ambientes estavam se comunicando normalmente até ontem. Nenhuma mudança foi registrada via Change Management nas últimas 24 horas pelos times de aplicação. A VNet vnet-core está em peering com outras 4 VNets além da vnet-onprem-linked.

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

  • Passo P: Verificar as effective routes na NIC de uma VM em vnet-core para confirmar se a rota para 192.168.10.0/24 está presente.
  • Passo Q: Verificar o status do peering entre vnet-onprem-linked e vnet-core no portal do Azure.
  • Passo R: Confirmar se os espaços de endereçamento das VNets ainda estão corretos e não foram alterados.
  • Passo S: Inspecionar os NSGs aplicados às subnets relevantes em busca de regras que bloqueiem o tráfego entre os dois ranges.
  • Passo T: Tentar um ping de teste de uma VM em 192.168.10.0/24 para um IP em 10.100.5.0/24 para confirmar e reproduzir a falha.

Qual sequência de diagnóstico segue a lógica correta de investigação progressiva?

A) T -> Q -> R -> P -> S B) Q -> T -> P -> R -> S C) P -> Q -> T -> S -> R D) T -> S -> Q -> P -> R

Gabarito e Explicações​

Gabarito — Cenário 1​

Resposta: D

A pista definitiva está na saída de effective routes: sem entradas para 172.16.20.0/24. Em uma VNet corretamente configurada, o Azure cria rotas de sistema automaticamente para todos os prefixos de subnet que fazem parte do espaço de endereçamento da VNet. Se a rota não existe na tabela efetiva, as subnets não estão sendo reconhecidas como pertencentes ao mesmo espaço de roteamento.

O distrator A é o erro de diagnóstico mais comum: culpar o NSG antes de verificar o plano de roteamento. Um NSG bloqueando tráfego apareceria como pacotes descartados, não como ausência de rota. O distrator B é factualmente incorreto, pois 172.16.0.0/16 cobre tanto 172.16.10.0/24 quanto 172.16.20.0/24. O distrator C confunde o sintoma com uma impossibilidade técnica: subnets criadas após a VNet funcionam normalmente desde que o espaço de endereçamento as comporte.

A informação sobre a policy de tagging é deliberadamente irrelevante e não tem qualquer relação com roteamento entre subnets. Agir com base no distrator A levaria o administrador a criar regras NSG permissivas desnecessárias, introduzindo risco de segurança sem resolver o problema real.

Gabarito — Cenário 2​

Resposta: B

A restrição crítica que elimina as outras alternativas é a combinação de dois fatores: há VMs em produção ativas e existe um processo de aprovação de segurança obrigatório, com janela de manutenção disponível em 48 horas. A expansão do espaço de endereçamento de uma VNet no Azure pode ser realizada sem downtime para os recursos existentes, tornando-a uma operação segura quando planejada adequadamente.

O distrator A representa a ação tecnicamente correta, mas aplicada sem respeitar o processo de governança. A aprovação do time de segurança existe justamente para mudanças que afetam conectividade de produção, e ignorá-la seria uma violação de processo mesmo que a ação técnica fosse válida. O distrator C é desnecessariamente destrutivo: recriar a VNet implicaria interrupção de produção e perda dos peerings configurados, quando a expansão do espaço de endereçamento resolve o problema sem nenhum desses impactos. O distrator D cria complexidade desnecessária e potencial sobreposição de endereços se não for cuidadosamente planejado.

Gabarito — Cenário 3​

Resposta: D

A pista central está na saída do nslookup: o servidor respondendo é 168.63.129.16, que é o endereço do Azure DNS recursivo. Se os servidores customizados 10.5.0.5 e 10.5.0.6 estivessem sendo efetivamente consultados, eles apareceriam como o servidor na resposta. O fato de o Azure DNS padrão estar respondendo indica que as VMs ainda estão com a configuração DNS antiga em cache via DHCP, e uma reinicialização ou renovação de lease DHCP forçaria a aplicação das novas configurações.

O distrator B descreve um problema real e comum em ambientes com DNS customizado, mas é incompatível com a evidência observada: se os servidores customizados fossem consultados e não soubessem responder, o servidor mostrado no nslookup seria um deles, não o 168.63.129.16. O distrator C confunde DNS privado do Azure com DNS customizado via servidor Windows. O distrator A descreve exatamente o sintoma, não a causa, um erro diagnóstico clássico de confundir o que é observado com o porquê ocorre.

A informação sobre o número de recursos no resource group é deliberadamente irrelevante e não deve influenciar o diagnóstico.

Gabarito — Cenário 4​

Resposta: A

A sequência correta é T -> Q -> R -> P -> S, que segue o princípio de diagnóstico progressivo: confirmar o problema antes de investigar causas, verificar o componente mais provável de falha (o peering), validar as configurações de rede subjacentes, verificar o plano de roteamento resultante e, por último, inspecionar regras de filtragem.

O primeiro passo deve sempre ser reproduzir e confirmar a falha (T), evitando investigar um problema que pode ter se resolvido ou ser intermitente. Em seguida, como o tráfego entre as VNets parou de funcionar sem mudanças registradas, o status do peering (Q) é o candidato mais provável, pois peerings podem cair por mudanças nos espaços de endereçamento. Verificar os espaços de endereçamento (R) em seguida confirma se uma mudança silenciosa causou conflito. As effective routes (P) validam se o plano de dados reflete o estado esperado. Os NSGs (S) vêm por último porque, se o peering e as rotas estão corretos e o problema persiste, a filtragem é a hipótese remanescente.

O distrator D é o erro mais perigoso: colocar a inspeção de NSG como segundo passo desperdiça tempo investigando filtragem quando o plano de roteamento pode estar completamente quebrado.

Árvore de Troubleshooting: Create and configure virtual networks and subnets​

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

Legenda de cores:

CorSignificado
Azul escuroSintoma inicial (ponto de entrada)
AzulPergunta diagnóstica (decisão binária ou verificável)
LaranjaVerificação ou validação intermediária
VermelhoCausa identificada
VerdeAção recomendada ou resolução

Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma observado e responda cada pergunta com base no que você consegue verificar diretamente no portal, via CLI ou dentro da VM. Siga o caminho correspondente à sua resposta até alcançar um nó vermelho de causa identificada, e então execute a ação verde associada. Se a ação não resolver o problema, retorne ao ponto de ramificação anterior e avalie se alguma resposta anterior pode ter sido incorreta ou incompleta.