Laboratório de Troubleshooting: Design service chaining, including gateway transit
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de rede reporta que VMs em Spoke-A não conseguem se comunicar com o ambiente local via VPN. A topologia é hub-and-spoke clássica: o Hub-VNet possui um gateway de VPN ativo e conectado, e os peerings entre Hub e Spoke-A foram criados há duas semanas sem incidentes. Recentemente, a equipe de infraestrutura provisionou um gateway de rede virtual dentro da própria Spoke-A para um projeto piloto de ExpressRoute que acabou sendo cancelado antes de entrar em produção. O gateway foi mantido para eventual uso futuro. O peering de Spoke-A para Hub-VNet continua listado como Connected no portal.
O administrador executa o seguinte comando para verificar as rotas efetivas na NIC de uma VM em Spoke-A:
az network nic show-effective-route-table \
--resource-group rg-spoke-a \
--name vm-spoke-a-nic01 \
--output table
A saída mostra apenas rotas do espaço de endereço local de Spoke-A e nenhuma rota com prefixo da rede local.
Qual é a causa raiz da ausência das rotas da rede local nas VMs de Spoke-A?
A) O gateway de VPN no Hub-VNet perdeu a conexão com o dispositivo local e parou de anunciar rotas
B) A existência de um gateway de rede virtual em Spoke-A impede que Use remote gateways seja ativado nessa VNet, bloqueando a propagação de rotas do Hub
C) O peering entre Spoke-A e Hub-VNet está com Allow forwarded traffic desabilitado, impedindo que rotas externas sejam aceitas
D) O gateway de ExpressRoute cancelado deixou rotas conflitantes na tabela de roteamento efetiva de Spoke-A
Cenário 2 — Decisão de Ação
A equipe de segurança identificou que tráfego entre Spoke-B e Spoke-C está fluindo diretamente entre as VMs sem passar pelo NVA centralizado no Hub-VNet. A causa foi confirmada: nenhuma UDR foi aplicada nas sub-redes de Spoke-B e Spoke-C. O ambiente está em produção com dezenas de VMs ativas em cada Spoke. O NVA já está configurado, com IP Forwarding habilitado na NIC, e o peering entre cada Spoke e o Hub possui Allow forwarded traffic ativado.
A equipe tem uma janela de manutenção de 30 minutos disponível agora. A aplicação que roda nas VMs é sensível a interrupções e qualquer mudança de rota causa uma reconexão de sessão TCP de aproximadamente 8 segundos.
Qual é a ação correta a tomar neste momento?
A) Recriar os peerings entre Spoke-B, Spoke-C e o Hub-VNet com as configurações corretas para forçar a atualização das tabelas de rota
B) Aplicar as UDRs nas sub-redes de Spoke-B e Spoke-C durante a janela de manutenção, aceitando o impacto de reconexão previsto de 8 segundos
C) Habilitar Use remote gateways em Spoke-B e Spoke-C para que o Hub passe a controlar o roteamento entre os Spokes automaticamente
D) Aguardar uma janela de manutenção maior antes de aplicar qualquer mudança, pois recriar peerings causa impacto mais severo do que aplicar UDRs
Cenário 3 — Causa Raiz
Um engenheiro configurou service chaining entre Spoke-D e Spoke-E via NVA no Hub-VNet. As UDRs foram aplicadas corretamente em ambos os Spokes. O IP Forwarding está habilitado na NIC do NVA. O peering entre Spoke-D e Hub-VNet possui Allow forwarded traffic habilitado. O peering entre Hub-VNet e Spoke-E também possui Allow forwarded traffic habilitado.
Durante os testes, pings de VMs em Spoke-D chegam ao NVA (confirmado via tcpdump na VM do NVA), mas não avançam para Spoke-E. O engenheiro verifica o sistema operacional do NVA:
cat /proc/sys/net/ipv4/ip_forward
0
O engenheiro então verifica o portal do Azure e confirma que a NIC do NVA tem a opção IP Forwarding marcada como Enabled.
Qual é a causa raiz do problema?
A) O peering entre Hub-VNet e Spoke-E está com Allow forwarded traffic desabilitado, descartando os pacotes antes de chegarem às VMs de destino
B) A UDR em Spoke-D está com next hop do tipo errado; deveria ser VirtualNetworkGateway em vez de VirtualAppliance
C) O IP Forwarding está habilitado no Azure (camada de plataforma), mas está desabilitado no sistema operacional da VM do NVA, que é onde o encaminhamento real ocorre
D) O NVA possui apenas uma NIC, o que impede o roteamento entre interfaces de sub-redes diferentes
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe o seguinte relato: VMs em Spoke-F não conseguem alcançar um servidor local com IP 192.168.10.50, mas conseguem alcançar outros recursos dentro da própria Spoke-F e dentro do Hub-VNet sem problemas. O Hub-VNet possui um gateway de VPN ativo. O peering entre Spoke-F e Hub-VNet existe e está listado como Connected.
Os seguintes passos de investigação estão disponíveis, fora de ordem:
- Verificar se
Use remote gatewaysestá habilitado no peering de Spoke-F para o Hub-VNet - Verificar as rotas efetivas na NIC de uma VM em Spoke-F e confirmar se existe uma rota para
192.168.0.0/16 - Verificar o status da conexão VPN no gateway do Hub-VNet e confirmar se o túnel com o ambiente local está
Connected - Verificar se
Allow gateway transitestá habilitado no peering do Hub-VNet para Spoke-F - Testar conectividade direta de uma VM no Hub-VNet para
192.168.10.50
Qual é a sequência correta de investigação?
A) 3 -> 5 -> 1 -> 4 -> 2
B) 2 -> 1 -> 4 -> 3 -> 5
C) 5 -> 3 -> 4 -> 1 -> 2
D) 1 -> 2 -> 3 -> 4 -> 5
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista central está na combinação de dois fatos: o peering continua Connected (portanto o peering em si não é o problema) e um gateway foi provisionado dentro de Spoke-A. O Azure impõe uma restrição que torna Use remote gateways e a existência de um gateway local mutuamente exclusivos na mesma VNet. Com um gateway presente em Spoke-A, a opção Use remote gateways é automaticamente bloqueada, e as rotas aprendidas pelo gateway do Hub simplesmente não são propagadas para Spoke-A.
O detalhe sobre o projeto de ExpressRoute cancelado é a informação irrelevante inserida propositalmente. O fato de o projeto ter sido cancelado não importa; o que importa é que o gateway continua existindo na VNet.
A alternativa A é o distrator mais perigoso: é plausível suspeitar do gateway do Hub, mas o enunciado diz explicitamente que a conexão VPN está ativa e que outras VNets (presumivelmente) funcionam. A alternativa C confunde Allow forwarded traffic com o mecanismo de propagação de rotas de gateway, que são funcionalidades distintas. A alternativa D é factualmente incorreta: rotas conflitantes de um gateway nunca implantado em produção não causariam esse tipo de ausência seletiva.
Agir com base no distrator A levaria a investigar e possivelmente recriar a conexão VPN no Hub, gerando impacto desnecessário em toda a topologia.
Gabarito — Cenário 2
Resposta: B
A causa já está declarada no enunciado (ausência de UDRs) e o NVA está plenamente configurado. A decisão correta é aplicar as UDRs durante a janela disponível. O impacto de 8 segundos por reconexão é previsível, controlado e compatível com uma janela de manutenção.
A alternativa A é tecnicamente incorreta para esse problema: recriar peerings não resolve a ausência de UDRs e causaria impacto muito superior ao necessário. A alternativa C representa um erro conceitual grave: Use remote gateways serve para compartilhar um gateway VPN/ExpressRoute, não para forçar o Hub a controlar o roteamento entre Spokes via NVA. Essa configuração não teria efeito algum sobre o fluxo entre Spokes. A alternativa D poderia ser válida se o impacto fosse imprevisível ou severo, mas o enunciado fornece o dado exato de 8 segundos de reconexão, tornando a postergação injustificada.
O distrator mais perigoso é A: recriar peerings em produção causa interrupção completa de conectividade durante o processo, muito pior do que 8 segundos de reconexão.
Gabarito — Cenário 3
Resposta: C
O comando cat /proc/sys/net/ipv4/ip_forward retornando 0 é a pista definitiva. O IP Forwarding opera em duas camadas independentes: a camada da plataforma Azure (configuração na NIC no portal) e a camada do sistema operacional da VM. A camada do Azure permite que a plataforma não descarte pacotes destinados a outros endereços antes de entregá-los à VM. Mas quem de fato encaminha o pacote para outra interface é o kernel do sistema operacional. Se o kernel tiver ip_forward = 0, o pacote chega à VM e é descartado ali.
O fato de os pings chegarem ao NVA (confirmado via tcpdump) elimina imediatamente as alternativas A e B: se o peering de Hub para Spoke-E fosse o problema, o tráfego seria descartado antes de chegar ao NVA. A alternativa D é um distrator técnico plausível em arquiteturas mais antigas, mas o Azure suporta encaminhamento de pacotes com NVA de NIC única via roteamento no kernel, e o enunciado não indica nenhuma restrição de NIC.
Agir com base na alternativa A levaria o engenheiro a modificar configurações de peering que estão corretas, sem resolver o problema real.
Gabarito — Cenário 4
Resposta: A
A sequência correta é 3 -> 5 -> 4 -> 1 -> 2, e a alternativa A representa exatamente esse raciocínio de eliminação progressiva:
Passo 3 confirma se o túnel VPN está ativo. Se o túnel estiver caído, todos os outros passos são irrelevantes.
Passo 5 isola se o problema é específico de Spoke-F ou afeta toda a topologia. Se uma VM no Hub também não alcança 192.168.10.50, o problema está no gateway ou na conexão, não no peering.
Passo 4 verifica se o Hub está compartilhando o gateway (Allow gateway transit).
Passo 1 verifica se Spoke-F está configurada para consumir esse gateway (Use remote gateways).
Passo 2 confirma o resultado final: se a rota para 192.168.0.0/16 aparece na tabela efetiva, o mecanismo de propagação está funcionando.
A alternativa B começa pelo sintoma final (rotas efetivas) sem primeiro validar se o gateway e o túnel estão operacionais, o que é um erro de diagnóstico clássico: investigar a consequência antes de verificar se a causa primária existe. A alternativa C pula direto para testar do Hub sem primeiro confirmar o status do túnel. A alternativa D é aleatória e não segue nenhuma lógica de eliminação progressiva.
Árvore de Troubleshooting: Design service chaining, including gateway transit
Legenda:
- Azul escuro: sintoma inicial, ponto de entrada da investigação
- Azul: pergunta diagnóstica com resposta sim ou nao
- Laranja: nó de validação ou verificação intermediária
- Vermelho: causa identificada com ação recomendada
- Verde: não utilizado neste diagrama; reservado para resoluções confirmadas
Para usar esta árvore diante de um problema real, comece pelo nó raiz e responda cada pergunta com base no que é diretamente observável no ambiente: status do túnel, configurações de peering no portal, rotas efetivas na NIC e estado do IP Forwarding no sistema operacional. Cada resposta elimina um ramo inteiro de hipóteses. O objetivo é chegar a um nó vermelho com a causa identificada antes de realizar qualquer alteração no ambiente.