Laboratório de Troubleshooting: Design and Implement User-Defined Routes (UDRs)
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações reporta que VMs em uma sub-rede de produção (10.1.2.0/24) perderam conectividade com um servidor de logs localizado em 10.3.0.10, pertencente a uma VNet remota conectada via VNet Peering. A conectividade com recursos dentro da própria VNet continua funcionando normalmente. O peering está com status Connected em ambos os lados.
O administrador verifica as rotas efetivas da NIC de uma das VMs afetadas e obtém a seguinte saída:
Prefixo de destino Próximo salto Fonte
-------------------- -------------------- --------------------
10.1.0.0/16 VnetLocal Default
10.3.0.0/16 VirtualAppliance User
10.3.0.0/24 VirtualNetworkPeering Default
0.0.0.0/0 VirtualAppliance User
O NVA referenciado na UDR tem IP 10.0.1.4 e está em execução. A sub-rede 10.1.2.0/24 tem uma route table associada com duas entradas: uma para 0.0.0.0/0 e uma para 10.3.0.0/16, ambas apontando para o NVA. O time de segurança informa que um NSG foi adicionado à sub-rede do NVA na semana anterior, mas não houve alterações nas UDRs.
Qual é a causa raiz da perda de conectividade com 10.3.0.10?
A) O NSG adicionado à sub-rede do NVA está bloqueando o tráfego antes que ele alcance o servidor de logs.
B) A UDR com prefixo 10.3.0.0/16 sobrescreve a rota de sistema do peering (10.3.0.0/24), e o NVA não está encaminhando o tráfego corretamente para o destino.
C) O peering está com status Connected mas não propagou a rota 10.3.0.0/24 corretamente, causando descarte silencioso.
D) A rota 10.3.0.0/16 da UDR é menos específica que a rota 10.3.0.0/24 do peering, portanto o Azure usa a rota do peering e o problema está em outro lugar.
Cenário 2 — Decisão de Ação
Uma organização identificou que VMs em uma sub-rede spoke (10.2.1.0/24) estão se comunicando diretamente com a internet sem passar pelo Azure Firewall implantado no hub VNet (10.0.0.4). A causa foi confirmada: a sub-rede spoke não possui nenhuma route table associada, portanto utiliza apenas rotas de sistema padrão.
O ambiente é de produção, com SLA ativo. O firewall já está configurado e operacional. Um colega sugere imediatamente criar e associar uma UDR com 0.0.0.0/0 apontando para 10.0.0.4 como VirtualAppliance.
Antes de executar a ação, o arquiteto responsável identifica uma restrição crítica: há uma regra de aplicação no Azure Firewall que ainda não foi configurada para liberar o tráfego HTTPS das VMs spoke em direção a três endpoints SaaS utilizados pelos sistemas de produção. Esses endpoints não estão documentados na CMDB.
Qual é a ação correta a tomar neste momento?
A) Criar e associar a UDR imediatamente, pois o firewall já está operacional e pode ser ajustado depois com base nos logs de tráfego bloqueado.
B) Identificar os endpoints SaaS acessados pelas VMs de produção via logs de fluxo ou análise de tráfego, configurar as regras no firewall e só então criar e associar a UDR.
C) Criar a UDR com 0.0.0.0/0 apontando para o firewall e, simultaneamente, adicionar uma regra temporária de allow all no firewall para evitar interrupção durante a transição.
D) Abrir um chamado para o time de segurança levantar os endpoints antes de qualquer ação, sem criar a UDR nem alterar o firewall.
Cenário 3 — Causa Raiz
Uma VM (vm-app-01) em uma sub-rede de aplicação tenta alcançar um endpoint on-premises no IP 192.168.10.20. A conexão é feita via VPN Gateway implantado na VNet hub. O ambiente usa topologia hub-and-spoke com peering entre hub e spoke. O peering de spoke para hub tem a opção Use Remote Gateway habilitada, e o peering de hub para spoke tem Allow Gateway Transit habilitado.
O administrador roda o seguinte comando a partir da VM e não obtém resposta:
curl --connect-timeout 5 http://192.168.10.20
# curl: (28) Connection timed out after 5001 milliseconds
Ele verifica as rotas efetivas da NIC de vm-app-01:
Prefixo de destino Próximo salto Fonte
-------------------- -------------------- --------------------
10.1.0.0/16 VnetLocal Default
10.0.0.0/16 VNetPeering Default
192.168.10.0/24 VirtualNetworkGateway Default
0.0.0.0/0 VirtualAppliance User
192.168.0.0/16 VirtualAppliance User
O VPN Gateway está com status Connected e o túnel on-premises está ativo. O time de rede on-premises confirma que não houve alterações recentes na infraestrutura deles. O NVA referenciado na UDR 192.168.0.0/16 tem IP 10.0.1.4 e está em execução.
Qual é a causa raiz da falha de conectividade?
A) A rota de sistema 192.168.10.0/24 aprendida via gateway está sendo aplicada corretamente, portanto o problema é no túnel VPN, que deve estar com falha intermitente.
B) A UDR com prefixo 192.168.0.0/16 sobrescreve a rota mais específica 192.168.10.0/24 aprendida via gateway, redirecionando o tráfego para o NVA em vez do VPN Gateway.
C) O peering com Use Remote Gateway impede que rotas aprendidas via BGP sejam propagadas para a sub-rede spoke, bloqueando a rota 192.168.10.0/24.
D) A rota 0.0.0.0/0 apontando para o NVA intercepta o tráfego destinado a 192.168.10.20 porque ela é avaliada antes das rotas mais específicas na tabela efetiva.
Cenário 4 — Impacto Colateral
Um administrador identificou que VMs em uma sub-rede de aplicação estavam se comunicando com 8.8.8.8 diretamente, sem passar pelo NVA de inspeção. Para corrigir, ele criou uma UDR com 0.0.0.0/0 apontando para o NVA (10.0.1.4 como VirtualAppliance) e associou à sub-rede. O tráfego para 8.8.8.8 passou a ser inspecionado conforme esperado.
No dia seguinte, o time de plataforma reporta que Azure Monitor Agent nas VMs da sub-rede parou de enviar métricas e logs para o workspace do Log Analytics. As VMs estão em execução e os agentes aparecem como instalados.
Qual é o impacto colateral causado pela ação corretiva aplicada?
A) A UDR alterou as rotas de sistema da VNet inteira, bloqueando o acesso dos agentes ao endpoint do Log Analytics em todas as sub-redes.
B) O NVA está descartando o tráfego HTTPS das VMs para os endpoints do Azure Monitor porque não possui regras configuradas para permitir esses destinos, interrompendo a telemetria.
C) A associação de uma route table à sub-rede desabilitou automaticamente o Service Endpoint para Microsoft.OperationalInsights, quebrando a conectividade privada com o Log Analytics.
D) A rota 0.0.0.0/0 via NVA suprime as rotas de sistema para os prefixos gerenciados da Microsoft, tornando os endpoints do Azure Monitor inacessíveis mesmo que o NVA permita o tráfego.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A saída das rotas efetivas mostra duas entradas para o espaço 10.3.0.0: uma UDR com prefixo /16 (origem User) e uma rota de peering com prefixo /24 (origem Default). Pela regra de longest prefix match, a rota /24 seria mais específica e deveria prevalecer, o que tornaria a alternativa D aparentemente correta. Porém, o comportamento real do Azure é que UDRs sempre têm precedência sobre rotas de sistema de mesmo comprimento de prefixo, mas quando o prefixo da UDR é menos específico (/16) e o prefixo da rota de sistema é mais específico (/24), o Azure usa a rota mais específica. Nesse caso, a rota 10.3.0.0/24 do peering deveria vencer.
O detalhe crítico que o enunciado entrega está na saída real: ambas as rotas aparecem na tabela, e o tráfego para 10.3.0.10 deveria seguir a rota /24 do peering. Porém, a questão confirma que a conectividade está falhando. A causa está no NVA: a UDR /16 captura o tráfego para 10.3.0.0/16 como um todo, e o NVA não está encaminhando corretamente porque IP Forwarding não está habilitado ou porque o NVA não tem rota de retorno. A rota /24 do peering aparece mas é sobrescrita na prática pelo comportamento do NVA no caminho.
A informação sobre o NSG adicionado à sub-rede do NVA é a informação irrelevante proposital. O enunciado diz que o NVA está em execução, e o NSG afetaria o tráfego que já chegou ao NVA, não a seleção de rota. O diagnóstico não deve partir do NSG sem antes confirmar que o tráfego está chegando ao NVA.
O distrator mais perigoso é D: induzir o leitor a concluir que a rota de peering prevalece e que o problema está em outro lugar, ignorando o comportamento real do NVA no encaminhamento.
Gabarito — Cenário 2
Resposta: B
A causa já foi identificada e o firewall está operacional, mas há uma restrição crítica: três endpoints SaaS de produção não estão documentados e ainda não têm regras de liberação no firewall. Associar a UDR antes de configurar essas regras bloquearia tráfego de produção sem aviso, pois o Azure Firewall nega por padrão tudo que não está explicitamente permitido.
A ação correta é identificar os endpoints primeiro, configurar as regras e só então aplicar a UDR. Esse é o único caminho que respeita o SLA ativo sem introduzir uma janela de impacto.
A alternativa A é o distrator mais perigoso: associar a UDR e ajustar depois parece ágil, mas em produção com SLA ativo, o "depois" acontece durante uma interrupção ativa. A alternativa C introduz uma regra de allow all temporária, o que viola a postura de segurança e anula o propósito do firewall. A alternativa D erra por omissão: abrir chamado sem nenhuma ação paralela, como levantamento de logs de fluxo, desperdiça tempo sem entregar progresso.
Gabarito — Cenário 3
Resposta: B
A tabela de rotas efetivas mostra duas entradas que se sobrepõem para o espaço 192.168.x.x:
192.168.10.0/24 VirtualNetworkGateway Default
192.168.0.0/16 VirtualAppliance User
Pela regra de longest prefix match, 192.168.10.0/24 (mais específico) deveria prevalecer sobre 192.168.0.0/16. Isso tornaria a alternativa B aparentemente errada. Porém, a precedência de UDR sobre rotas de sistema se aplica quando os prefixos têm o mesmo comprimento. Quando os comprimentos diferem, o prefixo mais longo vence independentemente da fonte.
A causa real é que a UDR 192.168.0.0/16 tem prefixo /16 e a rota do gateway tem prefixo /24. O Azure aplica 192.168.10.0/24 via gateway corretamente como rota mais longa. Mas o NVA referenciado na UDR /16 está descartando o tráfego que deveria seguir para o gateway, porque não possui rota de retorno ou IP Forwarding mal configurado para esse prefixo. A rota efetiva mostra o gateway como próximo salto para /24, mas o tráfego não chega porque o NVA na rota /16 interfere antes.
A informação sobre o status Connected do VPN Gateway e a confirmação do time on-premises de que não houve mudanças são informações irrelevantes: desviam o diagnóstico para o túnel VPN quando o problema está na seleção e no encaminhamento de rotas dentro do Azure.
O distrator mais perigoso é A: confiar no status Connected do túnel e concluir falha intermitente, sem examinar a tabela de rotas efetivas.
Gabarito — Cenário 4
Resposta: B
Ao criar uma UDR com 0.0.0.0/0 apontando para o NVA, todo o tráfego de saída das VMs na sub-rede passa a ser inspecionado pelo NVA, incluindo o tráfego HTTPS dos agentes do Azure Monitor para os endpoints públicos do serviço (*.ods.opinsights.azure.com, *.oms.opinsights.azure.com e similares). Se o NVA não tem regras explícitas para permitir esses destinos, ele descarta o tráfego silenciosamente, interrompendo a telemetria.
A alternativa A está errada porque UDRs são associadas a sub-redes específicas e não afetam outras sub-redes da VNet. A alternativa C é tecnicamente plausível mas incorreta: associar uma route table não desabilita automaticamente Service Endpoints; essa é uma operação separada e explícita. A alternativa D descreve um comportamento que não existe: a rota 0.0.0.0/0 não suprime rotas de sistema para prefixos específicos da Microsoft; ela captura apenas o tráfego sem correspondência mais específica.
O impacto colateral real é a ausência de regras no NVA para os endpoints do Azure Monitor, um destino muitas vezes esquecido ao redirecionar tráfego de saída via appliance.
Árvore de Troubleshooting: Design and Implement User-Defined Routes (UDRs)
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica |
| Laranja | Validação ou verificação intermediária |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
Para utilizar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma observado e siga as ramificações respondendo cada pergunta com base no que você consegue verificar no ambiente. As perguntas azuis são todas verificáveis diretamente no portal, via CLI ou via rotas efetivas da NIC. Ao chegar a um nó vermelho, você identificou a causa. O nó verde imediatamente relacionado indica a ação corretiva. Valide sempre o resultado após aplicar a correção antes de encerrar o diagnóstico.