Laboratório de Troubleshooting: Configure user-defined routes
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações relata que VMs na sub-rede app-subnet (10.2.1.0/24) perderam acesso à internet após uma janela de manutenção na noite anterior. O ambiente possui um NVA implantado em nva-subnet (10.2.2.0/24) com IP 10.2.2.10, responsável por inspecionar e encaminhar tráfego de saída.
Durante a manutenção, um administrador aplicou patches no sistema operacional do NVA e reiniciou a VM. O administrador confirma que a VM do NVA está ligada e que o IP forwarding está habilitado na NIC do Azure. O NSG associado à nva-subnet permite tráfego de entrada e saída nas portas necessárias. O peering entre VNets não foi alterado.
A route table associada à app-subnet contém a seguinte entrada:
Prefixo de destino : 0.0.0.0/0
Tipo do próximo salto : VirtualAppliance
Endereço do próximo salto: 10.2.2.10
Ao executar um ping 8.8.8.8 a partir de uma VM na app-subnet, os pacotes não retornam.
Qual é a causa raiz do problema?
A) O IP forwarding na NIC do Azure do NVA foi desabilitado durante a reinicialização da VM
B) O NSG na nva-subnet está bloqueando o tráfego ICMP de saída para a internet
C) O sistema operacional do NVA não está com o IP forwarding habilitado após a reinicialização
D) A route table com a UDR foi desassociada da app-subnet durante a janela de manutenção
Cenário 2 — Decisão de Ação
A causa do problema abaixo já foi identificada pela equipe: uma route table foi associada por engano à sub-rede GatewaySubnet de uma VNet hub, adicionando uma UDR com próximo salto None para o prefixo 10.0.0.0/8. Isso está derrubando todo o tráfego roteado via VPN Gateway entre a rede on-premises e as VNets spoke.
O ambiente é de produção. Aproximadamente 300 usuários remotos dependem da conectividade VPN neste momento. A sub-rede GatewaySubnet não possui nenhuma outra route table legítima associada que possa ser restaurada. A equipe tem permissão de escrita no resource group da VNet hub.
Qual é a ação correta a tomar neste momento?
A) Editar a UDR existente na route table, alterando o tipo do próximo salto de None para VirtualNetworkGateway
B) Desassociar a route table da GatewaySubnet imediatamente, sem aguardar uma janela de manutenção
C) Criar uma nova route table com a rota correta e associá-la à GatewaySubnet antes de remover a incorreta
D) Reiniciar o VPN Gateway para forçar a releitura das rotas e restaurar a conectividade
Cenário 3 — Causa Raiz
Um administrador configura uma topologia hub-spoke com inspeção centralizada de tráfego. O hub contém um NVA em 10.0.1.4. O spoke possui a sub-rede spoke-app (10.1.2.0/24).
A route table associada à spoke-app contém:
Prefixo de destino : 0.0.0.0/0
Tipo do próximo salto : VirtualAppliance
Endereço do próximo salto: 10.0.1.4
O VNet Peering entre hub e spoke está configurado com Allow forwarded traffic habilitado em ambos os lados. A VM do NVA está em execução, com IP forwarding habilitado na NIC do Azure e no sistema operacional. O administrador relata que o tráfego de spoke-app para a internet funciona corretamente, mas o tráfego de spoke-app para uma sub-rede spoke-db (10.1.3.0/24) dentro da mesma VNet spoke não chega ao destino.
O administrador suspeita que o peering está com problema e abre um chamado para a equipe de rede.
Qual é a causa raiz do problema?
A) O VNet Peering não propaga rotas para sub-redes dentro da mesma VNet spoke quando há uma UDR de 0.0.0.0/0 ativa
B) O NVA no hub não possui uma rota de retorno para a sub-rede spoke-db após encaminhar o tráfego
C) A UDR de 0.0.0.0/0 está capturando também o tráfego destinado a 10.1.3.0/24 e enviando ao NVA, que não encaminha esse tráfego de volta à VNet spoke
D) O IP forwarding no sistema operacional do NVA não suporta encaminhar tráfego entre sub-redes de uma mesma VNet remota
Cenário 4 — Sequência de Diagnóstico
Uma VM na sub-rede prod-app não consegue alcançar um endpoint interno em 10.5.0.20. O ambiente possui route tables customizadas, NSGs e um NVA na rota. Você precisa diagnosticar o problema de forma eficiente.
Os passos abaixo estão fora de ordem:
- Verificar no Azure Network Watcher com a ferramenta Next Hop qual próximo salto está sendo resolvido para o destino
10.5.0.20a partir da VM de origem - Confirmar se o NVA está encaminhando o tráfego no nível do sistema operacional, verificando logs ou contadores de interface
- Verificar as effective routes da NIC da VM de origem para identificar qual rota está sendo aplicada
- Confirmar se existe uma regra de NSG bloqueando o tráfego entre a VM de origem e o destino
10.5.0.20 - Testar conectividade direta da VM de origem para
10.5.0.20usandoTest-NetConnectionoucurl
Qual é a sequência correta de diagnóstico?
A) 5 -> 1 -> 3 -> 4 -> 2
B) 5 -> 4 -> 1 -> 3 -> 2
C) 5 -> 3 -> 1 -> 4 -> 2
D) 1 -> 3 -> 5 -> 4 -> 2
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: C
A pista central está na sequência dos eventos: o problema surgiu após patches e reinicialização do sistema operacional do NVA. O IP forwarding no Azure (habilitado na NIC) e o IP forwarding no sistema operacional são configurações independentes. O Azure apenas permite que a interface receba pacotes destinados a outros IPs; quem decide encaminhá-los é o kernel do SO. Após uma reinicialização, configurações aplicadas manualmente (como net.ipv4.ip_forward=1 sem persistência em /etc/sysctl.conf no Linux) são perdidas.
A informação irrelevante no enunciado é o estado do NSG na nva-subnet: como o tráfego sequer está sendo encaminhado pelo NVA, o NSG não é o gargalo, e sua menção serve apenas para desviar o diagnóstico.
A alternativa A é atraente porque lembra que as duas configurações são distintas, mas o enunciado confirma explicitamente que o IP forwarding na NIC do Azure está habilitado. A alternativa D seria catastrófica se real, mas não há nenhuma indicação de desassociação na descrição. O distrator mais perigoso é A, pois levaria o analista a verificar a configuração da NIC (que já está correta) em vez de acessar o SO do NVA e verificar o estado do forwarding.
Gabarito — Cenário 2
Resposta: B
A causa já está identificada e é clara: uma route table indevida está associada à GatewaySubnet, com uma rota None que descarta tráfego. A ação correta e imediata é desassociar a route table, restaurando o comportamento padrão do gateway. A Microsoft documenta explicitamente que a GatewaySubnet não deve ter route tables com UDRs que interfiram nas rotas do gateway. Remover a associação é a ação mais direta, de menor risco e com efeito imediato para os 300 usuários afetados.
A alternativa A é incorreta porque editar a UDR para VirtualNetworkGateway não é a configuração adequada para a GatewaySubnet; ela deve ficar sem route tables. A alternativa C adiciona uma etapa desnecessária que prolonga o impacto. A alternativa D é o distrator mais perigoso: reiniciar o VPN Gateway é uma operação longa (pode levar 45 minutos ou mais), causaria interrupção adicional e não resolveria o problema, pois a route table continuaria associada após o reinício.
Gabarito — Cenário 3
Resposta: C
A UDR de 0.0.0.0/0 captura qualquer tráfego cujo destino não tenha uma rota mais específica. O prefixo 10.1.3.0/24 (spoke-db) está contido em 10.1.0.0/16, mas se não houver uma rota de sistema mais específica visível na route table da spoke-app para esse prefixo após a sobreposição da UDR, o tráfego para 10.1.3.0/24 também é enviado ao NVA no hub. O NVA recebe o pacote, mas não tem configuração para encaminhar tráfego de volta para uma sub-rede dentro da VNet spoke, pois seu próximo salto natural para 10.1.3.0/24 depende de uma rota de peering que pode não existir ou não ser propagada corretamente nesse caminho de retorno.
A informação irrelevante é a confirmação de que o tráfego para a internet funciona: esse dado confirma que o NVA está operacional para tráfego externo, mas não tem relação com o problema de tráfego leste-oeste dentro do spoke.
O distrator mais perigoso é B, pois a ausência de rota de retorno no NVA é um problema real em topologias de inspeção, mas a causa raiz aqui é anterior: o tráfego nem deveria estar chegando ao NVA. A solução correta seria adicionar UDRs específicas para sub-redes locais do spoke com próximo salto VnetLocal, impedindo que a rota 0.0.0.0/0 capte esse tráfego.
Gabarito — Cenário 4
Resposta: A
A sequência correta é: 5 -> 1 -> 3 -> 4 -> 2
O raciocínio diagnóstico progressivo parte do sintoma observável para a causa mais específica:
- Passo 5: confirmar o sintoma objetivamente antes de investigar infraestrutura. Sem confirmar a falha, qualquer investigação pode ser prematura.
- Passo 1: usar o Next Hop do Network Watcher para entender imediatamente qual é o próximo salto resolvido pelo plano de controle do Azure. Isso revela se o problema está na camada de roteamento.
- Passo 3: verificar as effective routes da NIC para obter a visão completa das rotas aplicadas, confirmando ou detalhando o que o Next Hop já indicou.
- Passo 4: após confirmar que a rota leva ao NVA ou ao destino correto, verificar se um NSG está bloqueando o tráfego nesse caminho.
- Passo 2: por último, verificar o comportamento do NVA no nível do SO, pois este é o passo mais custoso e deve ser feito apenas quando os anteriores indicarem que o tráfego está chegando ao NVA mas não sendo encaminhado.
A alternativa B é atraente mas incorreta: verificar o NSG antes das rotas efetivas levaria a investigar uma camada de filtragem sem saber ainda se a rota está correta. A alternativa D começa pelo Network Watcher sem antes confirmar o sintoma, pulando a etapa de validação inicial.
Árvore de Troubleshooting: Configure user-defined routes
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul médio | Pergunta diagnóstica (decisão verificável) |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma observado e siga cada ramificação respondendo objetivamente à pergunta do nó de decisão com base no que você consegue observar ou medir no ambiente. Cada resposta elimina um conjunto de hipóteses e direciona para a causa ou ação correta sem necessidade de testar todas as possibilidades. O caminho mais curto até a resolução é sempre o que parte da verificação do plano de controle (Next Hop, effective routes) antes de descer para o plano de dados (NVA, NSG, SO).