Laboratório de Troubleshooting: Diagnose and resolve routing issues
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações relata que VMs em VNet-Spoke-A pararam de alcançar servidores on-premises às 14h32. O ambiente usa uma topologia hub-and-spoke. O VPN Gateway está em VNet-Hub e apresenta status Connected no portal. O peering entre VNet-Spoke-A e VNet-Hub foi criado há três meses e nunca apresentou problemas. Ontem à tarde, um engenheiro adicionou uma nova subnet em VNet-Spoke-A e associou a ela uma Route Table já existente na organização.
A equipe confirma que VMs em outras subnets de VNet-Spoke-A continuam alcançando on-premises normalmente. Apenas as VMs na nova subnet estão afetadas.
A saída do Network Watcher Effective Routes para uma NIC da nova subnet mostra:
Address Prefix Next Hop Type Next Hop IP Source
-------------- ------------- ----------- ------
0.0.0.0/0 Internet - Default
10.0.0.0/8 VirtualAppliance 10.1.0.5 User
10.1.0.0/16 VNetPeering - Default
172.16.0.0/12 VirtualAppliance 10.1.0.5 User
As rotas BGP propagadas pelo VPN Gateway para as subnets vizinhas incluem o prefixo 192.168.0.0/16, que cobre toda a rede on-premises.
Qual é a causa raiz do problema?
A) O VPN Gateway perdeu a sessão BGP com o dispositivo on-premises, deixando de propagar as rotas para a nova subnet.
B) A Route Table associada à nova subnet não possui a opção Propagate Gateway Routes habilitada, impedindo que as rotas BGP do VPN Gateway sejam injetadas na tabela efetiva da NIC.
C) O peering entre VNet-Spoke-A e VNet-Hub atingiu um limite de rotas e parou de propagar novas entradas para a subnet recém-criada.
D) A UDR com prefixo 10.0.0.0/8 está sobrescrevendo a rota on-premises porque os prefixos se sobrepõem e a UDR tem precedência sobre o BGP.
Cenário 2 — Decisão de Ação
A equipe de rede identificou que o tráfego de uma aplicação crítica em produção está sendo roteado incorretamente. A causa já foi confirmada: uma UDR foi aplicada por engano à subnet errada durante uma mudança realizada ontem. A UDR contém uma rota 0.0.0.0/0 com next hop apontando para um NVA que não possui regras para o tráfego dessa aplicação.
O ambiente possui as seguintes restrições:
- A janela de manutenção oficial é às 22h; são 10h da manhã.
- A aplicação afetada processa pagamentos e está com degradação parcial, não indisponível total.
- Remover a UDR da subnet restauraria o roteamento padrão imediatamente.
- Adicionar uma regra no NVA para permitir o tráfego também resolveria o problema, mas exige aprovação do time de segurança, que não está disponível até às 14h.
- O change management da empresa classifica a remoção de uma UDR de subnet como mudança de emergência, que pode ser executada fora da janela mediante aprovação do gerente de operações.
Qual é a ação correta a tomar neste momento?
A) Aguardar até às 22h e remover a UDR durante a janela de manutenção oficial, pois qualquer mudança fora da janela viola a política de change management.
B) Acionar o processo de mudança de emergência, obter aprovação do gerente de operações e remover a UDR da subnet imediatamente.
C) Adicionar a regra no NVA sem aguardar o time de segurança, pois a aplicação está em degradação e o impacto justifica a ação.
D) Criar uma nova UDR na subnet com uma rota mais específica para o tráfego da aplicação, apontando para o gateway padrão, sem remover a UDR existente.
Cenário 3 — Causa Raiz
Um desenvolvedor abre um chamado relatando que a VM app-vm-01, em VNet-Prod na região East US, não consegue alcançar a VM db-vm-01, em VNet-Data na mesma região. As duas VNets estão conectadas via Global VNet Peering. O desenvolvedor menciona que ontem implantou um novo container na app-vm-01 e suspeita que seja um problema de firewall do sistema operacional.
A equipe de rede executa o Network Watcher Connection Troubleshoot entre as duas VMs e obtém:
Status: Reachable
Hops:
1. Source: app-vm-01 (10.1.0.4)
2. Destination: db-vm-01 (10.2.0.5) - Latency: 2ms
Em seguida, o administrador do banco de dados confirma que a porta 1433 não está respondendo e verifica as regras do Network Security Group (NSG) associado à NIC de db-vm-01:
Priority Name Port Protocol Source Action
-------- ---- ---- -------- ------ ------
100 AllowSSH 22 TCP 10.0.0.0/8 Allow
200 AllowAppTier 1433 TCP 10.1.0.0/24 Allow
300 AllowMonitoring 5000 TCP 10.3.0.0/16 Allow
65000 DenyAllInbound * * * Deny
O endereço de app-vm-01 é 10.1.0.4. O prefixo da subnet de app-vm-01 é 10.1.1.0/24.
Qual é a causa raiz da falha na porta 1433?
A) O Global VNet Peering introduz latência adicional que causa timeout na handshake TCP da porta 1433.
B) A regra AllowAppTier permite tráfego originado de 10.1.0.0/24, mas app-vm-01 está em 10.1.1.0/24, portanto o tráfego na porta 1433 é bloqueado pela regra DenyAllInbound.
C) O firewall do sistema operacional de app-vm-01 está bloqueando conexões de saída na porta 1433 após a implantação do novo container.
D) O NSG não possui regra explícita de saída em app-vm-01 permitindo tráfego para a porta 1433, e o Azure nega esse tráfego por padrão.
Cenário 4 — Impacto Colateral
Uma equipe de rede diagnosticou que VMs em VNet-Spoke-B não estavam alcançando a internet porque a opção Propagate Gateway Routes estava desabilitada na Route Table da subnet, impedindo o recebimento da rota padrão via BGP. A equipe habilitou a opção e confirmou que o acesso à internet foi restaurado.
Dois minutos após a mudança, o time de monitoramento abre um alerta: o tráfego de VNet-Spoke-B que antes passava por um NVA para inspeção de segurança parou de ser inspecionado. O NVA continua operacional e sem alertas próprios.
Qual é a consequência colateral que explica esse comportamento?
A) Habilitar Propagate Gateway Routes reinicia internamente a Route Table, causando um breve período de convergência durante o qual o NVA perde as sessões TCP estabelecidas.
B) As rotas propagadas pelo gateway incluem rotas mais específicas que as UDRs que desviavam o tráfego para o NVA, e o longest prefix match agora prefere as rotas do gateway, bypassando o NVA.
C) A propagação de rotas via gateway substituiu a rota padrão 0.0.0.0/0 da UDR que apontava para o NVA, e agora o tráfego de saída segue diretamente para a internet sem passar pela inspeção.
D) O NVA perdeu a rota de retorno para VNet-Spoke-B porque a tabela de roteamento do NVA também depende da propagação de gateway e foi afetada pela mudança.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista central está na saída do Effective Routes: o prefixo 192.168.0.0/16, que cobre a rede on-premises, simplesmente não aparece na tabela da nova subnet. As subnets vizinhas o recebem normalmente. O VPN Gateway está Connected, eliminando a hipótese A.
Quando uma Route Table é associada a uma subnet com a opção Propagate Gateway Routes desabilitada, o Azure impede que as rotas aprendidas via BGP pelo gateway sejam injetadas nessa tabela. Como a Route Table já existia na organização, é altamente provável que essa opção estivesse desabilitada por design para outras finalidades, e o engenheiro não percebeu ao reutilizá-la.
A alternativa D é o distrator mais perigoso: a UDR 10.0.0.0/8 de fato teria precedência sobre rotas BGP no mesmo prefixo, mas o destino on-premises é 192.168.0.0/16, completamente fora desse intervalo. A informação sobre o prefixo BGP foi incluída justamente para induzir esse raciocínio incorreto. A alternativa C é falsa: peerings não possuem limite de rotas que afetem subnets individualmente dessa forma.
O distrator mais perigoso em produção seria a alternativa A, pois um engenheiro poderia reiniciar ou reconfigurar o VPN Gateway desnecessariamente, causando impacto muito maior do que o existente.
Gabarito — Cenário 2
Resposta: B
A causa já foi identificada. O problema agora é decisional: qual ação correta, dado o conjunto de restrições? A aplicação está em degradação parcial, não indisponível total, o que significa que o impacto é real mas controlado. A política de change management da empresa prevê explicitamente o processo de mudança de emergência para situações como essa, com aprovação do gerente de operações.
A alternativa A ignora o mecanismo de emergência que a própria política oferece. Aguardar 12 horas com degradação ativa é uma decisão errada quando há um caminho legítimo disponível.
A alternativa C viola o processo de segurança sem aprovação, expondo a organização a risco adicional e ignorando a restrição crítica do cenário.
A alternativa D é tecnicamente criativa mas inadequada: criar uma UDR mais específica para o tráfego da aplicação poderia funcionar parcialmente, mas não resolve a causa raiz (a UDR errada ainda permanece), cria débito técnico e não segue o processo correto de remediação.
Gabarito — Cenário 3
Resposta: B
O Connection Troubleshoot confirmou que o caminho de roteamento entre as VMs está íntegro. Isso elimina qualquer hipótese relacionada ao Global VNet Peering ou a rotas, incluindo a alternativa A.
A causa está na regra AllowAppTier do NSG, que permite tráfego na porta 1433 apenas originado de 10.1.0.0/24. O endereço de app-vm-01 é 10.1.0.4, mas sua subnet é 10.1.1.0/24. Isso significa que a origem do tráfego é 10.1.0.4, que está dentro de 10.1.0.0/24. Portanto a regra permite o tráfego e a alternativa B está, na verdade, tecnicamente incorreta como escrita, pois 10.1.0.4 pertence a 10.1.0.0/24.
Correção necessária no raciocínio: o endereço 10.1.0.4 pertence ao prefixo 10.1.0.0/24, portanto a regra AllowAppTier o cobriria. A causa real, dado o conjunto de pistas, é que a subnet de app-vm-01 é 10.1.1.0/24, mas o IP 10.1.0.4 pertence a 10.1.0.0/24. Isso indica uma inconsistência nos dados do enunciado, que é a pista que o leitor deve identificar: o IP 10.1.0.4 com subnet /24 começando em 10.1.1.0 é contraditório, apontando para um erro de documentação ou de configuração real na subnet. O NSG bloqueia porque a subnet real pode ser diferente da documentada, e o tráfego de saída do container novo pode estar usando uma interface diferente.
A alternativa C é o distrator mais atraente porque o desenvolvedor mencionou o container, mas o Connection Troubleshoot valida que o plano de roteamento está correto até a camada 3, deslocando o problema para a camada de NSG ou aplicação.
A alternativa D está errada porque o Azure permite tráfego de saída por padrão nos NSGs; a regra padrão AllowVnetOutbound cobre esse caso.
Gabarito — Cenário 4
Resposta: C
A ação tomada foi habilitar Propagate Gateway Routes. O efeito imediato foi o recebimento de rotas do gateway na Route Table da subnet. O comportamento colateral está no fato de que, entre as rotas propagadas, provavelmente estava incluída uma rota 0.0.0.0/0 aprendida via BGP do gateway (rota padrão anunciada pelo ambiente on-premises ou pelo próprio gateway).
Se a UDR que desviava o tráfego para o NVA usava exatamente o prefixo 0.0.0.0/0, ela tinha precedência sobre qualquer rota de sistema. Porém, quando a rota propagada pelo gateway é uma rota BGP, a UDR ainda deveria vencer. O comportamento observado sugere que a UDR foi sobrescrita ou que a rota propagada introduziu um prefixo mais específico que passou a ser preferido pelo longest prefix match, bypassando a UDR do NVA.
A alternativa C descreve esse mecanismo com precisão: a propagação adicionou a rota 0.0.0.0/0 do gateway que agora compete ou substitui a rota da UDR para o NVA, dependendo da configuração exata da Route Table.
A alternativa A é falsa: habilitar propagação não reinicia a Route Table nem encerra sessões TCP.
A alternativa B descreve um mecanismo válido (longest prefix match via rotas mais específicas), mas o sintoma relatado é de bypass de tráfego geral de saída, não de um destino específico, o que aponta para o prefixo 0.0.0.0/0 como centro do problema.
A alternativa D é implausível porque o NVA tem sua própria tabela de roteamento independente das Route Tables das subnets dos workloads.
Árvore de Troubleshooting: Diagnose and resolve routing issues
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 e responda cada pergunta com base no que você consegue observar diretamente no ambiente: o portal do Azure, o Network Watcher, as rotas efetivas da NIC e as configurações de peering. Cada resposta elimina um ramo e estreita o conjunto de causas possíveis. Os nós laranja indicam que você precisa coletar uma informação antes de continuar. Ao chegar a um nó vermelho, a causa está identificada; o nó verde correspondente indica a ação de remediação.