Laboratório de Troubleshooting: Configure routing rules
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma VNet de hub contém um NVA responsável por inspecionar todo o tráfego entre spoke VNets e redes on-premises. A topologia usa VNet Peering com Allow Gateway Transit no hub e Use Remote Gateways nos spokes. O gateway VPN do hub está operacional e as sessões BGP com o on-premises estão estabelecidas.
A equipe relata que VMs no Spoke A alcançam recursos on-premises normalmente. VMs no Spoke B, por sua vez, alcançam recursos dentro da própria VNet e dentro do hub, mas não conseguem alcançar nenhum prefixo on-premises. O peering do Spoke B foi criado há três dias, após uma migração de workloads.
A tabela de rotas efetivas de uma VM no Spoke B mostra:
Source State Address Prefix Next Hop Type Next Hop IP
Default Active 10.0.0.0/8 VNetPeering -
Default Active 0.0.0.0/0 Internet -
Rotas on-premises (172.16.0.0/12) não aparecem na tabela efetiva.
A equipe já confirmou que o gateway VPN está anunciando os prefixos on-premises via BGP e que o Spoke A tem essas rotas visíveis em suas tabelas efetivas.
Qual é a causa raiz do problema no Spoke B?
A) O peering do Spoke B não tem a opção Use Remote Gateways habilitada
B) O gateway VPN do hub está com a sessão BGP para o Spoke B suspensa por excesso de prefixos anunciados
C) A Route Table associada à sub-rede do Spoke B tem BGP route propagation desabilitada
D) O Spoke B não possui uma UDR com next hop VirtualNetworkGateway para os prefixos on-premises
Cenário 2 — Decisão de Ação
A equipe de operações identificou que uma Route Table em produção está causando um loop de roteamento entre dois NVAs. O tráfego destinado ao segmento 192.168.10.0/24 entra no NVA-1, que tem uma rota UDR apontando para o NVA-2, que por sua vez tem uma rota UDR apontando de volta para o NVA-1. VMs dependentes desse segmento estão completamente sem conectividade.
A causa está confirmada: a UDR na sub-rede do NVA-2 aponta incorretamente para o IP do NVA-1 como next hop para 192.168.10.0/24, quando deveria apontar para o firewall perimetral (10.0.1.100).
O ambiente opera em produção 24 horas. Não há janela de manutenção programada. A correção da UDR não requer reinicialização de recursos e tem efeito imediato após salvar. O time de mudanças exige registro de incidente antes de qualquer alteração em Route Tables em produção, mas o gerente de operações está disponível para autorização emergencial.
Qual é a ação correta a tomar neste momento?
A) Remover imediatamente a Route Table da sub-rede do NVA-2 para eliminar o loop e depois criar a UDR correta
B) Solicitar autorização emergencial ao gerente de operações, registrar o incidente e corrigir o next hop da UDR na sub-rede do NVA-2
C) Criar uma nova Route Table com a configuração correta e associá-la à sub-rede do NVA-2 sem alterar a existente, para preservar o estado atual como rollback
D) Aguardar a abertura de uma janela de manutenção formal, pois alterações em Route Tables em produção sem processo completo de mudança podem gerar maior instabilidade
Cenário 3 — Causa Raiz
Uma equipe configurou uma sub-rede de workloads com a seguinte Route Table para forçar o tráfego de saída para a Internet via NVA:
Nome da Rota Prefixo Next Hop Type Next Hop IP
ForceTunnel 0.0.0.0/0 VirtualAppliance 10.1.0.4
Após associar a Route Table, as VMs na sub-rede perderam acesso à Internet. O NVA está operacional, o IP forwarding está habilitado na NIC do NVA e o NVA consegue fazer ping para endereços públicos a partir de sua própria interface. O NSG da sub-rede permite saída para qualquer destino na porta 443.
Um engenheiro inspeciona a sub-rede do NVA e observa que ela também tem uma Route Table associada, com a seguinte entrada:
Nome da Rota Prefixo Next Hop Type Next Hop IP
ToInternet 0.0.0.0/0 VirtualAppliance 10.1.0.4
O tráfego de saída das VMs chega ao NVA conforme confirmado pelos logs do NVA. A conectividade interna entre VMs continua funcionando normalmente.
Qual é a causa raiz da falha de acesso à Internet?
A) O NSG da sub-rede está bloqueando o tráfego de retorno da Internet para as VMs, pois não há regra de entrada permitindo respostas
B) A Route Table associada à sub-rede do NVA cria um loop: o tráfego que sai do NVA para a Internet é redirecionado de volta ao próprio NVA
C) O NVA não tem um endereço IP público associado, impedindo que o tráfego NAT de saída funcione corretamente
D) A rota 0.0.0.0/0 do tipo VirtualAppliance não é aplicada a tráfego de saída para a Internet, apenas para tráfego entre VNets
Cenário 4 — Sequência de Diagnóstico
Uma VM em uma sub-rede spoke não consegue alcançar um servidor on-premises (172.20.5.10). A VNet usa peering com hub, que contém um gateway ExpressRoute. Não houve alterações recentes relatadas pela equipe.
Os passos de investigação disponíveis são:
P1 — Verificar se a rota 172.20.0.0/16 aparece na tabela de rotas efetivas da NIC da VM
P2 — Verificar o status da sessão BGP no gateway ExpressRoute via az network express-route list-route-tables
P3 — Confirmar se a Route Table da sub-rede da VM tem BGP route propagation habilitada
P4 — Testar conectividade TCP da VM para 172.20.5.10:443 usando Test-NetConnection
P5 — Verificar se o peering da spoke com o hub tem Use Remote Gateways habilitado
Qual é a sequência correta de diagnóstico?
A) P4, P1, P3, P5, P2
B) P1, P3, P5, P2, P4
C) P2, P5, P3, P1, P4
D) P3, P5, P1, P2, P4
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: A
A pista decisiva está na tabela de rotas efetivas da VM no Spoke B: a rota 0.0.0.0/0 aponta para Internet, e os prefixos on-premises estão completamente ausentes. Esse padrão indica que o peering existe (há rotas da VNet visíveis), mas o gateway do hub não está sendo utilizado como gateway remoto para esse spoke.
Quando Use Remote Gateways não está habilitado no peering do Spoke B, o Azure não propaga as rotas aprendidas pelo gateway do hub para as tabelas efetivas desse spoke. O Spoke A funciona porque seu peering foi configurado corretamente antes da migração.
A opção C seria plausível se as rotas existissem na tabela mas estivessem desabilitadas. O fato de as rotas on-premises nem aparecerem descarta esse distrator: BGP route propagation desabilitada suprime rotas que já existiriam pela propagação do gateway; neste caso, a propagação via gateway remoto nunca chegou a ocorrer.
A opção D descreveria a solução para um cenário onde BGP route propagation está desabilitada, não a causa raiz aqui. A opção B é factualmente implausível: o BGP entre o gateway e o on-premises não opera por spoke individualmente.
Agir com base na opção D (adicionar UDRs manualmente) mascararia o problema sem corrigi-lo, pois qualquer alteração futura no peering exigiria atualização manual das UDRs, criando fragilidade operacional desnecessária.
Gabarito — Cenário 2
Resposta: B
A causa está identificada, o impacto em produção é ativo e severo, e a correção é cirúrgica e sem risco de instabilidade adicional. A restrição crítica do cenário não é técnica: é processual. O processo exige registro de incidente e autorização antes de alterações em Route Tables em produção. O gerente está disponível para autorização emergencial, o que torna o caminho correto iniciar esse processo imediatamente.
A opção A ignora a restrição processual e introduz risco adicional: remover a Route Table inteira interromperia temporariamente qualquer rota útil que ela contenha, além de não seguir o processo exigido.
A opção C é tecnicamente ineficaz: associar uma nova Route Table à sub-rede substituiria a anterior, não a preservaria como rollback. Além disso, manter duas Route Tables não é possível para uma mesma sub-rede no Azure.
A opção D é o distrator mais perigoso. Aguardar janela formal quando há impacto ativo em produção e o gerente pode autorizar emergencialmente é uma decisão que prolonga o incidente desnecessariamente e ignora o mecanismo de autorização emergencial explicitamente descrito no enunciado.
Gabarito — Cenário 3
Resposta: B
A informação relevante que confirma a causa está na Route Table da sub-rede do NVA: ela contém uma rota 0.0.0.0/0 com next hop VirtualAppliance apontando para o próprio IP do NVA (10.1.0.4). Isso significa que quando o NVA tenta encaminhar tráfego para a Internet, o Azure consulta a tabela de rotas da sub-rede onde o NVA está e redireciona esse tráfego de volta para o próprio NVA, criando um loop que esgota o TTL dos pacotes sem alcançar a Internet.
A informação irrelevante no enunciado é o NSG da sub-rede de workloads permitindo saída na porta 443. O NSG não tem relação com o problema: o tráfego sequer chega à Internet para que um bloqueio de retorno fosse relevante. Também é irrelevante que o NVA consiga fazer ping a partir de sua própria interface: esse ping usa a rota da NIC do NVA diretamente, não passa pela Route Table da sub-rede.
A opção C é um distrator plausível em outros contextos: NVAs que fazem NAT de saída geralmente precisam de IP público. Porém, o enunciado indica que os logs do NVA confirmam a chegada do tráfego, e o problema está no comportamento após o NVA tentar encaminhar, não na ausência de IP público.
Gabarito — Cenário 4
Resposta: B
A sequência correta é: P1, P3, P5, P2, P4.
O diagnóstico correto segue a lógica de verificar primeiro o estado mais próximo da VM (tabela de rotas efetivas), depois as causas locais progressivamente mais distantes, e reservar o teste de conectividade de ponta a ponta para quando o plano de roteamento já estiver validado.
P1 determina imediatamente se a VM sequer conhece uma rota para o destino. Se a rota não existe na tabela efetiva, os passos seguintes identificam por quê. P3 verifica se BGP route propagation está habilitado na Route Table da sub-rede, pois é a causa mais local para rotas ausentes. P5 verifica se o peering está configurado para usar o gateway remoto do hub, que é o próximo elo na cadeia. P2 verifica o estado BGP no gateway ExpressRoute, que é a origem das rotas on-premises. P4 é o teste de conectividade real, executado apenas após o plano de roteamento estar validado, para confirmar que nenhuma outra camada (NSG, firewall, aplicação) está bloqueando.
A opção A começa pelo teste de conectividade (P4), que é ineficaz quando o problema de roteamento ainda não foi diagnosticado: um timeout não diz nada sobre onde o tráfego está sendo descartado. A opção C começa pelo gateway ExpressRoute, saltando etapas que poderiam revelar causas locais muito mais simples. A opção D tem uma sequência plausível mas inverte P3 e P5, verificando BGP route propagation antes de confirmar se o peering está configurado para usar o gateway remoto, sendo que o peering é pré-requisito para a propagação de gateway funcionar.
Árvore de Troubleshooting: Configure routing rules
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta de diagnóstico |
| 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. Responda cada pergunta de diagnóstico com base no que você pode observar diretamente: tabela de rotas efetivas, logs do NVA, configurações de peering e estado do gateway. Siga o caminho correspondente à sua resposta até chegar a um nó de causa identificada. A partir daí, aplique a ação recomendada e retorne aos nós de validação para confirmar que a causa foi eliminada antes de encerrar o diagnóstico.