Laboratório de Troubleshooting: Associate a route table with a subnet
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
O time de operações reporta que VMs na subnet app-subnet (10.0.2.0/24) não conseguem alcançar um servidor on-premises no endereço 192.168.10.5. A VNet possui um VPN Gateway ativo e o túnel IPsec está estabelecido, conforme confirmado pelo time de rede. Outras subnets da mesma VNet conseguem se comunicar normalmente com 192.168.10.5.
A equipe verifica as rotas efetivas de uma das VMs afetadas via portal e obtém a seguinte saída:
Source State Address Prefix Next Hop Type Next Hop IP
-------- ------- ---------------- -------------------- -----------
User Active 0.0.0.0/0 VirtualAppliance 10.0.1.4
User Active 192.168.10.0/24 VirtualAppliance 10.0.1.4
System Invalid 192.168.0.0/16 VirtualNetworkGateway -
System Invalid 10.0.0.0/16 VirtualNetwork -
O NVA no IP 10.0.1.4 está operacional e processa corretamente tráfego HTTP e HTTPS. O time informa que o firewall do NVA permite todo o tráfego na porta 443. A rota do sistema para o gateway aparece com estado Invalid.
Qual é a causa raiz da falha de conectividade?
A) O NVA está bloqueando o tráfego para 192.168.10.5 porque a porta utilizada não é 443.
B) A UDR com prefixo 192.168.10.0/24 na route table associada à app-subnet está sobrescrevendo a rota aprendida pelo VPN Gateway, e o NVA não está encaminhando esse tráfego ao destino final.
C) O túnel VPN está instável e derrubou as rotas do sistema periodicamente.
D) A route table não deveria estar associada à app-subnet; ela deveria estar associada à GatewaySubnet.
Cenário 2 — Decisão de Ação
A causa do problema foi identificada: uma route table associada à GatewaySubnet contém uma UDR com prefixo 0.0.0.0/0 e next hop Internet. Essa rota está impedindo que o VPN Gateway processe corretamente o tráfego de retorno de conexões on-premises, causando falha intermitente nas sessões estabelecidas.
O ambiente é de produção. O gateway atende a 12 subnets conectadas via VPN site-to-site com três filiais. A equipe de segurança confirma que a UDR foi adicionada por engano durante uma janela de manutenção na semana anterior. A janela de manutenção programada para alterações de rede é às 23h, e o horário atual é 14h.
Qual é a ação correta a tomar neste momento?
A) Remover imediatamente a route table da GatewaySubnet, pois o impacto já está ocorrendo em produção e a correção é reversível.
B) Aguardar a janela de manutenção às 23h e remover a route table da GatewaySubnet nesse horário, pois qualquer alteração em produção fora da janela representa risco adicional.
C) Remover apenas a UDR 0.0.0.0/0 da route table dentro da janela de manutenção, mantendo a route table associada à GatewaySubnet caso ela contenha outras rotas necessárias.
D) Criar uma segunda UDR na mesma route table com prefixo 0.0.0.0/0 e next hop VirtualNetworkGateway para sobrescrever a rota incorreta imediatamente.
Cenário 3 — Causa Raiz
Um engenheiro aplica uma nova route table à subnet db-subnet (10.0.3.0/24) para redirecionar tráfego de saída via NVA. Imediatamente após a associação, as VMs da db-subnet perdem acesso ao serviço Azure Storage acessado via Service Endpoint configurado na subnet.
O engenheiro verifica as rotas efetivas e nota o seguinte:
Source State Address Prefix Next Hop Type Next Hop IP
-------- ------- ---------------------- ------------------ -----------
User Active 0.0.0.0/0 VirtualAppliance 10.0.1.4
System Active 10.0.0.0/16 VirtualNetwork -
System Active Storage.BrazilSouth VirtualAppliance 10.0.1.4
O engenheiro observa que o NVA tem acesso à internet e conclui que o problema deve ser a capacidade do NVA de resolver nomes DNS do Storage. Ele abre um ticket para a equipe de DNS. O Service Endpoint para Storage estava ativo e funcionando normalmente antes da mudança.
Qual é a causa raiz do problema?
A) O DNS do NVA não consegue resolver os FQDNs do Azure Storage depois que o tráfego passa pelo appliance.
B) A UDR 0.0.0.0/0 com next hop VirtualAppliance sobrescreveu a rota de sistema do Service Endpoint, redirecionando o tráfego do Storage pelo NVA em vez de pelo caminho direto do endpoint privado.
C) O Service Endpoint foi automaticamente desassociado da db-subnet quando a route table foi vinculada.
D) O NVA não suporta tráfego destinado a prefixos de serviço do Azure por limitação de plataforma.
Cenário 4 — Sequência de Diagnóstico
Uma VM na subnet web-subnet não consegue alcançar um destino externo 203.0.113.10. O ambiente possui uma route table associada à web-subnet com múltiplas UDRs. O engenheiro precisa diagnosticar se o problema é de roteamento, de configuração do NVA ou de outra natureza.
Os passos de investigação disponíveis são:
- Passo P: Verificar as rotas efetivas da NIC da VM no portal do Azure para identificar qual next hop está sendo aplicado para
203.0.113.10. - Passo Q: Verificar se o IP forwarding está habilitado na NIC do NVA.
- Passo R: Executar um teste de conectividade com
Network Watcher > Connection Troubleshootda VM para203.0.113.10. - Passo S: Revisar o conteúdo da route table associada à
web-subnetno portal para listar as UDRs configuradas. - Passo T: Verificar os logs de fluxo do NSG aplicado à subnet do NVA para confirmar se o tráfego está chegando ao appliance.
Qual é a sequência correta de diagnóstico?
A) S -> P -> R -> T -> Q
B) P -> S -> Q -> T -> R
C) R -> P -> S -> T -> Q
D) S -> R -> P -> Q -> T
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está na saída de rotas efetivas: a rota do sistema 192.168.0.0/16 via VirtualNetworkGateway aparece com estado Invalid, o que indica que uma UDR com prefixo mais específico (192.168.10.0/24) está sendo preferida pelo Azure. O Azure sempre aplica a rota mais longa (mais específica) que cobre o destino. Como 192.168.10.0/24 é mais específico que 192.168.0.0/16, a UDR vence e o tráfego é enviado ao NVA. Se o NVA não tiver uma rota de retorno para 192.168.10.0/24 ou não estiver encaminhando esse tráfego ao gateway VPN, o pacote é descartado.
A informação sobre a porta 443 é propositalmente irrelevante: o problema não é de filtragem de portas, mas de roteamento. A alternativa A leva o leitor a focar nessa isca. A alternativa C é implausível porque o estado do túnel foi confirmado como ativo. A alternativa D confunde a direção correta de associação: a route table está corretamente na subnet de origem do tráfego; o problema é o conteúdo dela, não o local de associação.
O distrator mais perigoso é A: agir sobre o firewall do NVA consumiria tempo e não resolveria o problema real, enquanto o tráfego continuaria sendo roteado incorretamente.
Gabarito — Cenário 2
Resposta: C
A restrição crítica do cenário é que a route table pode conter outras rotas além da UDR incorreta. Remover a route table inteira da GatewaySubnet (alternativa A) pode eliminar configurações válidas e causar impacto adicional não planejado. A alternativa B ignora que o impacto já está ocorrendo em produção: aguardar 9 horas com uma falha ativa é inaceitável quando a correção cirúrgica é viável.
A alternativa D é tecnicamente equivocada: criar uma segunda rota 0.0.0.0/0 com next hop diferente gera ambiguidade de roteamento, pois o Azure não suporta duas UDRs com o mesmo prefixo na mesma route table; a operação seria rejeitada ou sobrescreveria a anterior de forma imprevisível.
A ação correta é remover especificamente a UDR problemática (0.0.0.0/0 com next hop Internet) dentro da janela de manutenção, preservando as demais rotas e seguindo o processo de change management do ambiente. O impacto já existente não justifica ignorar o processo, mas justifica priorizar a correção cirúrgica no próximo momento seguro disponível.
Gabarito — Cenário 3
Resposta: B
O Service Endpoint do Azure Storage funciona injetando automaticamente uma rota de sistema com o prefixo do serviço (Storage.BrazilSouth) e next hop VirtualNetworkServiceEndpoint. Essa rota garante que o tráfego vá diretamente ao backbone da Microsoft sem sair pela internet. Quando uma UDR 0.0.0.0/0 com next hop VirtualAppliance é adicionada, o Azure passa a aplicá-la para qualquer destino não coberto por uma rota mais específica. O prefixo do Service Endpoint, que antes era a rota mais específica para o Storage, pode ser sobrescrito se a UDR tiver precedência de mesma ou maior especificidade, quebrando o caminho direto do endpoint.
A saída de rotas efetivas confirma isso: Storage.BrazilSouth aparece com next hop VirtualAppliance, indicando que a UDR substituiu a rota do Service Endpoint.
A informação sobre o DNS é a isca do cenário e representa o erro de raciocínio mais comum: o engenheiro confundiu sintoma de conectividade com problema de resolução de nomes. As alternativas C e D são tecnicamente falsas: Service Endpoints não são desassociados por route tables, e o Azure não impõe essa limitação ao NVA por tipo de prefixo.
Gabarito — Cenário 4
Resposta: A
A sequência correta é S -> P -> R -> T -> Q, que segue a lógica de diagnóstico progressivo do mais amplo para o mais específico:
S revela o que está configurado na route table, fornecendo o mapa de intenção do roteamento. P revela o que o Azure está efetivamente aplicando na NIC da VM, permitindo comparar intenção com realidade. R executa um teste de ponta a ponta que confirma se o tráfego chega ao destino e onde falha. T valida se o tráfego está efetivamente chegando ao NVA, isolando se o problema está antes ou depois do appliance. Q verifica a configuração de IP forwarding do NVA apenas se o tráfego estiver chegando a ele, evitando investigar o NVA desnecessariamente.
A alternativa B começa pelas rotas efetivas sem revisar a route table, o que pode gerar conclusões sem o contexto da intenção original. A alternativa C começa pelo teste de conectividade, que é custoso e gera menos contexto diagnóstico do que verificar as rotas primeiro. A alternativa D intercala o teste de conectividade no meio da análise de roteamento, quebrando a progressão lógica.
Árvore de Troubleshooting: Associate a route table with a subnet
Legenda:
| Cor | Significado |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (decisão binária ou por estado) |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Diante de um problema real, comece pelo nó raiz e responda cada pergunta com base no que é observável no ambiente: portal do Azure, rotas efetivas, logs do Network Watcher. Siga o caminho correspondente à resposta até atingir um nó de causa identificada, aplique a ação recomendada correspondente e retorne ao fluxo de validação para confirmar que o comportamento esperado foi restaurado antes de encerrar o diagnóstico.