Laboratório de Troubleshooting: Plan and implement network segmentation and address spaces
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações recebe um chamado relatando que VMs na sub-rede 10.2.4.0/24 da VNet-App não conseguem se comunicar com VMs na sub-rede 10.2.8.0/24 da VNet-Data. As duas VNets estão na mesma região e foram configuradas com peering há três semanas, funcionando normalmente até ontem.
O engenheiro responsável coleta as seguintes informações:
- O peering entre VNet-App e VNet-Data aparece com status Connected no portal do Azure
- Nenhuma regra de NSG foi alterada nos últimos sete dias
- Ontem à noite, a equipe de arquitetura executou uma expansão do espaço de endereçamento da VNet-Data, adicionando o bloco
10.3.0.0/16para suportar novos ambientes - O gateway de VPN associado à VNet-Data está operacional e com status Connected
- Testes de conectividade com
Test-NetConnectionretornam timeout na porta 3389 entre as VMs
PS C:\> Test-NetConnection -ComputerName 10.2.8.15 -Port 3389
ComputerName : 10.2.8.15
RemoteAddress : 10.2.8.15
RemotePort : 3389
InterfaceAlias : Ethernet
SourceAddress : 10.2.4.10
TcpTestSucceeded : False
A equipe confirma que o NSG da sub-rede de destino permite RDP a partir de 10.2.4.0/24 e que a VM de destino está em execução.
Qual é a causa raiz da perda de conectividade?
A) Uma regra de NSG foi alterada de forma não registrada e está bloqueando o tráfego entre as sub-redes
B) A adição de um novo espaço de endereçamento à VNet-Data invalidou o peering existente, que agora precisa ser removido e recriado
C) O gateway de VPN da VNet-Data está competindo com o peering pelo roteamento do tráfego, causando loop
D) A sub-rede 10.2.8.0/24 ficou sem endereços disponíveis após a expansão, impedindo a comunicação
Cenário 2 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte relato: VMs em uma nova sub-rede 10.0.5.0/24, recém-criada em uma VNet existente, não conseguem resolver nomes DNS internos nem acessar a internet. VMs em outras sub-redes da mesma VNet funcionam normalmente. Nenhum NSG foi associado à nova sub-rede ainda.
Os passos de investigação disponíveis são:
- Verificar se a nova sub-rede tem uma UDR associada com rota padrão apontando para um NVA que não está operacional
- Confirmar se o intervalo
10.0.5.0/24se sobrepõe a alguma outra sub-rede existente na VNet - Verificar se as VMs na nova sub-rede receberam um endereço IP válido dentro do intervalo esperado
- Testar conectividade a partir de uma VM na nova sub-rede usando
ping 168.63.129.16para validar alcance ao plano de controle do Azure - Comparar as configurações de DNS da VNet com as configurações efetivas nas VMs da nova sub-rede
Qual é a sequência correta de diagnóstico?
A) 2 → 3 → 5 → 4 → 1
B) 3 → 2 → 4 → 5 → 1
C) 1 → 4 → 3 → 2 → 5
D) 5 → 3 → 1 → 4 → 2
Cenário 3 — Causa Raiz
Uma empresa opera uma arquitetura hub-and-spoke. A VNet-Hub contém um Azure Firewall e está pareada com VNet-Spoke-A e VNet-Spoke-B. As três VNets foram implantadas há dois meses e a comunicação entre os spokes, roteada pelo firewall no hub, funcionava corretamente.
Hoje, após um novo membro da equipe ter executado uma tarefa de manutenção rotineira na VNet-Spoke-A, as VMs nessa VNet perderam acesso à internet e à VNet-Spoke-B. O acesso à VNet-Hub continua funcionando normalmente a partir da VNet-Spoke-A.
O engenheiro observa:
- O peering entre VNet-Spoke-A e VNet-Hub está com status Connected
- A configuração "Use remote gateways" está habilitada no peering do lado da VNet-Spoke-A
- A configuração "Allow gateway transit" está habilitada no peering do lado da VNet-Hub
- A UDR associada à sub-rede de VMs na VNet-Spoke-A contém uma rota
0.0.0.0/0com próximo salto apontando para o IP privado do Azure Firewall
Após investigação, o engenheiro descobre que durante a manutenção foi adicionada uma nova sub-rede chamada snet-management à VNet-Spoke-A, sem nenhuma UDR associada.
A queixa dos usuários é que as VMs na sub-rede de VMs original continuam sem acesso externo, não as VMs na nova sub-rede.
Qual é a causa raiz do problema nas VMs da sub-rede original?
A) A adição da nova sub-rede corrompeu a tabela de roteamento efetiva da sub-rede de VMs original
B) O peering foi reiniciado automaticamente pela criação da nova sub-rede e perdeu as configurações de gateway transit
C) A UDR associada à sub-rede de VMs original foi desassociada ou modificada durante a criação da nova sub-rede
D) A nova sub-rede sem UDR está gerando uma rota mais específica na VNet que sobrescreve a rota padrão das demais sub-redes
Cenário 4 — Decisão de Ação
A causa já foi identificada: durante um processo de reorganização de endereçamento, um administrador removeu o peering entre VNet-Prod e VNet-Shared para adicionar um novo bloco de endereços à VNet-Shared. O novo bloco foi adicionado com sucesso, mas o administrador esqueceu de recriar o peering. O ambiente de produção está degradado há 40 minutos. Aplicações críticas dependem de serviços hospedados na VNet-Shared, incluindo um servidor DNS interno e um servidor de licenças.
O administrador agora tem as seguintes informações:
- O novo bloco adicionado à VNet-Shared é
172.20.0.0/16 - O espaço de endereçamento original da VNet-Prod é
10.10.0.0/16 - O espaço de endereçamento original da VNet-Shared é
10.20.0.0/16 - Não há sobreposição entre nenhum dos blocos
- O administrador possui permissões de Network Contributor nas duas VNets
- Existe documentação do peering original, incluindo as configurações de Allow forwarded traffic e Allow gateway transit que estavam habilitadas
Qual é a ação correta a tomar neste momento?
A) Abrir um chamado para a equipe de arquitetura revisar o novo espaço de endereçamento antes de recriar o peering, para evitar problemas futuros
B) Recriar imediatamente o peering nos dois sentidos entre VNet-Prod e VNet-Shared, restaurando as configurações originais documentadas
C) Recriar o peering apenas do lado da VNet-Prod para VNet-Shared, pois o sentido inverso é opcional em casos de urgência
D) Remover o bloco 172.20.0.0/16 recém-adicionado, recriar o peering com o espaço original e depois planejar a expansão corretamente
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista definitiva no enunciado é a execução da expansão do espaço de endereçamento da VNet-Data na noite anterior, exatamente o momento em que a conectividade foi perdida. O Azure exige que peerings ativos sejam removidos antes de modificar o espaço de endereçamento de uma VNet peerada. Quando essa alteração é feita sem remover o peering, o estado do peering pode se tornar inconsistente internamente, mesmo que o portal exiba Connected. O status Connected visível no portal reflete o plano de controle, não necessariamente a validade das rotas propagadas. A solução é remover o peering e recriá-lo para que o Azure sincronize o novo espaço de endereçamento nas tabelas de roteamento de ambas as VNets.
A informação sobre o gateway de VPN operacional é irrelevante para este diagnóstico e foi incluída propositalmente para induzir a alternativa C. O gateway não interfere com o roteamento de peering quando as configurações de gateway transit não estão em conflito descrito. A alternativa A é plausível, mas o enunciado afirma explicitamente que nenhuma regra de NSG foi alterada. Agir com base na alternativa C, investigando o gateway, atrasaria a resolução de um incidente ativo sem benefício.
Gabarito — Cenário 2
Resposta: A
A sequência correta é 2 → 3 → 5 → 4 → 1, pois segue a lógica de diagnóstico do mais básico e estrutural para o mais específico e operacional.
O primeiro passo (2) valida se o intervalo da sub-rede é estruturalmente válido dentro da VNet, pois sobreposição impede comunicação desde a criação. Em seguida (3), confirmar se as VMs receberam endereço IP válido elimina falhas de provisionamento antes de qualquer teste funcional. O passo seguinte (5) compara as configurações de DNS, identificando se o problema de resolução de nomes tem origem na configuração da VNet ou nas VMs. O passo (4) testa o alcance ao plano de controle do Azure, que depende de roteamento correto. Somente após confirmar que o roteamento básico funciona (ou não funciona) faz sentido investigar (1) se há uma UDR mal configurada direcionando o tráfego para um destino inválido.
Começar pelo passo 1 (alternativa C) seria um erro clássico de ir direto à causa mais complexa sem validar as fundações. Começar pelo passo 5 (alternativa D) ignora que problemas de endereçamento ou sobreposição invalidariam qualquer resultado de teste DNS.
Gabarito — Cenário 3
Resposta: C
A causa raiz é que a UDR foi desassociada ou modificada da sub-rede de VMs original durante a operação de manutenção. O comportamento observado é coerente: o acesso à VNet-Hub funciona (roteamento de peering direto, sem dependência de UDR para o hub), mas o acesso à internet e à VNet-Spoke-B falha (ambos dependem da rota 0.0.0.0/0 que aponta para o Azure Firewall, configurada via UDR). Sem essa rota, o tráfego para destinos externos segue a rota padrão do sistema, que não passa pelo firewall e pode não ter saída válida para internet nem para o spoke remoto.
A informação sobre "Use remote gateways" e "Allow gateway transit" é irrelevante para este diagnóstico e serve como distrator para a alternativa B. A alternativa A descreve um comportamento que não existe no Azure: a criação de uma sub-rede não altera tabelas de roteamento de outras sub-redes. A alternativa D confunde o conceito de rota mais específica com o comportamento de sub-redes sem UDR, que simplesmente herdam as rotas do sistema sem influenciar outras sub-redes.
O distrator mais perigoso é A, pois levaria o engenheiro a investigar uma suposta corrupção de tabela de roteamento do sistema, consumindo tempo em um caminho sem solução real.
Gabarito — Cenário 4
Resposta: B
A causa está identificada, as permissões estão disponíveis, não há sobreposição de endereços e a documentação das configurações originais existe. Todas as pré-condições para recriar o peering imediatamente estão satisfeitas. O ambiente de produção está degradado há 40 minutos com impacto em serviços críticos. A ação correta é recriar o peering nos dois sentidos com as configurações originais documentadas, restaurando o serviço o mais rápido possível.
A alternativa A ignora que o diagnóstico está completo e a solução é conhecida. Escalar para arquitetura sem necessidade técnica prolonga o incidente sem justificativa. A alternativa C está errada porque peering no Azure requer configuração em ambos os lados para ser estabelecido; criar apenas um lado deixa o peering em estado Initiated, sem tráfego fluindo. A alternativa D seria um retrocesso que descartaria uma modificação planejada e válida, além de não resolver o incidente mais rapidamente, pois exigiria nova janela de expansão futura.
O distrator mais perigoso é C, pois o administrador poderia interpretar o status Initiated como parcialmente funcional e perder tempo tentando diagnosticar por que o tráfego ainda não flui.
Árvore de Troubleshooting: Plan and implement network segmentation and address spaces
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (decisão binária ou observável) |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma de conectividade e responda cada pergunta com base no que é diretamente observável no portal do Azure ou via ferramentas como Get-AzEffectiveRouteTable e Test-NetConnection. Siga o caminho até alcançar um nó vermelho de causa identificada e então execute a ação verde correspondente. Se o primeiro caminho percorrido não resolver o problema, retorne ao último nó de validação laranja e reavalie a resposta dada naquele ponto.