Laboratório de Troubleshooting: Design a Virtual WAN architecture, including selecting types and services
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de rede recebe um chamado relatando que duas filiais conectadas via S2S VPN ao mesmo Virtual WAN hub na região East US conseguem se comunicar com VNets spoke associadas a esse hub, mas não conseguem alcançar uma a outra diretamente. A latência para as VNets spoke está dentro do esperado e sem perdas de pacote. O hub foi provisionado há três semanas e está com status Succeeded no portal do Azure. Não houve alterações de configuração nas últimas 72 horas. A equipe verificou que as VPN Gateways das filiais estão operacionais e que os túneis IPSec aparecem como Connected no portal.
Branch A (S2S VPN) --> Hub East US --> VNet Spoke 1 [OK]
Branch B (S2S VPN) --> Hub East US --> VNet Spoke 2 [OK]
Branch A --> Branch B [FALHA]
Qual é a causa raiz da falha de comunicação entre Branch A e Branch B?
A) Os túneis IPSec das filiais estão em estado degradado, o que impede o roteamento transitivo mesmo com status Connected exibido no portal.
B) O hub foi provisionado como Virtual WAN Basic, que não suporta roteamento transitivo entre branches.
C) As filiais estão usando prefixos de endereço sobrepostos, o que faz o hub descartar o tráfego entre elas silenciosamente.
D) A route table padrão do hub está com propagação desabilitada para as conexões S2S VPN das filiais.
Cenário 2 — Decisão de Ação
A causa já foi identificada: um Virtual WAN hub em produção foi criado como Basic e precisa ser convertido para Standard para habilitar o roteamento transitivo exigido por um novo projeto. O hub possui atualmente 12 conexões S2S VPN ativas com filiais em operação. A conversão de tier é suportada pelo Azure. O time de arquitetura tem uma janela de manutenção disponível no próximo fim de semana, mas o gerente de projeto solicita que a mudança seja feita imediatamente, pois o novo projeto já está atrasado. Não há ambiente de homologação com Virtual WAN configurado.
Qual é a ação correta a tomar neste momento?
A) Executar a conversão imediatamente via portal do Azure, pois a operação é não disruptiva e as conexões S2S VPN existentes são preservadas automaticamente.
B) Criar um novo hub Standard em paralelo, migrar as conexões manualmente e desativar o hub Basic após validação.
C) Aguardar a janela de manutenção para executar a conversão, comunicando o risco ao gerente de projeto e documentando o impacto potencial sobre as 12 conexões ativas.
D) Executar a conversão imediatamente usando Azure CLI para reduzir o tempo de operação, sem necessidade de janela de manutenção.
Cenário 3 — Causa Raiz
Uma organização opera um Virtual WAN Standard com dois hubs: Hub-WestEurope e Hub-EastUS. VNets spoke estão conectadas a ambos os hubs. O time de segurança habilitou recentemente o Azure Firewall no Hub-WestEurope, convertendo-o em um Secured Virtual Hub. Após essa mudança, as equipes de aplicação relatam que VMs em VNets spoke conectadas ao Hub-WestEurope perderam acesso à internet. O tráfego leste-oeste entre VNets do mesmo hub continua funcionando. O Hub-EastUS não foi alterado e suas VNets spoke mantêm acesso à internet normalmente. O time de segurança confirma que nenhuma regra de negação explícita foi criada no Azure Firewall.
Hub-WestEurope (Secured Virtual Hub)
├── VNet Spoke WE-1 --> Internet [FALHA]
├── VNet Spoke WE-2 --> Internet [FALHA]
└── Azure Firewall --> Status: Running
Hub-EastUS (Hub padrão)
├── VNet Spoke US-1 --> Internet [OK]
Qual é a causa raiz da perda de acesso à internet nas VNets spoke do Hub-WestEurope?
A) O Azure Firewall em execução no hub está consumindo toda a capacidade de throughput disponível, bloqueando o tráfego de saída das VNets spoke.
B) Ao converter o hub em Secured Virtual Hub, a internet traffic routing intent foi habilitada, redirecionando o tráfego de saída para o Azure Firewall, que ainda não possui regras de permissão para tráfego à internet.
C) A conversão para Secured Virtual Hub remove automaticamente o peering gerenciado entre as VNets spoke e o hub, exigindo reconexão manual das VNets.
D) O Azure Firewall bloqueia por padrão todo tráfego norte-sul até que uma política de firewall com regras explícitas de DNAT seja associada ao hub.
Cenário 4 — Sequência de Diagnóstico
Uma VM em uma VNet spoke conectada ao Hub-BrazilSouth não consegue alcançar uma VM em uma VNet spoke conectada ao Hub-EastUS, ambos pertencentes ao mesmo Virtual WAN Standard. O tráfego dentro do mesmo hub funciona normalmente. Um engenheiro de rede recebe o chamado e precisa investigar o problema.
Os passos de investigação disponíveis são:
- Passo P: Verificar se as duas VNets spoke estão efetivamente conectadas aos seus respectivos hubs e com status Connected.
- Passo Q: Confirmar que o Virtual WAN resource é do tipo Standard e não Basic.
- Passo R: Inspecionar as effective routes da NIC da VM de origem para verificar se existe uma rota para o prefixo de destino.
- Passo S: Usar o Network Watcher Connection Troubleshoot entre as duas VMs para validar conectividade fim a fim e identificar onde o tráfego está sendo descartado.
- Passo T: Verificar se há custom route tables aplicadas aos hubs que possam estar bloqueando a propagação de rotas inter-hub.
Qual é a sequência correta de investigação?
A) Q -> P -> R -> T -> S
B) S -> R -> P -> Q -> T
C) R -> S -> Q -> P -> T
D) P -> Q -> T -> R -> S
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista definitiva no enunciado é o comportamento observado: as filiais alcançam as VNets spoke, mas não se alcançam entre si. Esse padrão é a assinatura exata da limitação do Virtual WAN Basic: ele suporta conectividade S2S VPN de branch para VNet, mas não habilita roteamento transitivo entre branches. O tier Basic não possui o plano de controle necessário para propagar e resolver rotas entre conexões do tipo branch-to-branch.
O status Succeeded do hub e os túneis em Connected são informações corretas, mas irrelevantes para o diagnóstico. Eles eliminam falhas de infraestrutura, mas não contradizem a limitação de tier. Esse é o detalhe propositalmente incluído para distrair.
A alternativa A representa o erro clássico de confundir sintoma com causa: o status Connected no portal confirma o plano de controle do túnel, não o roteamento transitivo. A alternativa D é tecnicamente plausível, mas a route table padrão não bloqueia propagação em hubs Basic; ela simplesmente não existe com capacidade transitiva. Agir com base no distrator D levaria a horas de investigação de roteamento em um problema que só se resolve com conversão de tier.
Gabarito — Cenário 2
Resposta: C
A restrição crítica do cenário é a existência de 12 conexões S2S VPN ativas em produção e a ausência de ambiente de homologação. Embora a conversão de Basic para Standard seja suportada e tecnicamente possível a qualquer momento, o risco de impacto sobre as conexões ativas sem validação prévia em ambiente equivalente justifica aguardar a janela de manutenção disponível. A decisão correta prioriza a estabilidade do ambiente produtivo sobre a pressão de prazo do projeto.
A alternativa A apresenta a operação como não disruptiva, o que é uma simplificação perigosa: a documentação da Microsoft descreve a conversão como suportada, mas não garante ausência de impacto em todos os cenários, especialmente com múltiplas conexões ativas. A alternativa B seria válida em um contexto de migração planejada com recursos disponíveis, mas criar e migrar 12 conexões manualmente e sem homologação introduz risco maior do que aguardar o fim de semana. A alternativa D representa ação correta aplicada no momento errado: o meio de execução não elimina o risco da ausência de janela de manutenção.
Gabarito — Cenário 3
Resposta: B
A causa raiz é o comportamento padrão da routing intent em Secured Virtual Hubs. Quando a internet traffic routing intent é habilitada, o hub passa a anunciar o prefixo 0.0.0.0/0 via o Azure Firewall para todas as VNets spoke conectadas. O tráfego de saída dessas VNets é então redirecionado para o firewall antes de sair para a internet. Como nenhuma application rule ou network rule de permissão foi criada no Azure Firewall, o comportamento padrão de deny-all do firewall descarta o tráfego de saída.
A informação sobre o Hub-EastUS não alterado e com internet funcionando normalmente é um dado relevante que confirma o escopo do problema, mas poderia induzir o leitor a focar em diferenças de infraestrutura entre os hubs em vez de no comportamento da routing intent.
A alternativa A é incorreta porque o Azure Firewall não satura throughput de forma silenciosa em condições normais de operação. A alternativa C é falsa: a conversão para Secured Virtual Hub não remove peerings gerenciados. A alternativa D confunde o comportamento de DNAT com o comportamento de regras de rede e aplicação; o tráfego de saída à internet não requer DNAT. O distrator mais perigoso é C, pois levaria o engenheiro a tentar reconectar VNets desnecessariamente, postergando a solução real.
Gabarito — Cenário 4
Resposta: A
A sequência correta é Q -> P -> R -> T -> S, que segue a lógica de eliminação progressiva do mais simples para o mais complexo, do plano de controle para o plano de dados.
Q valida o pressuposto fundamental: se o Virtual WAN é Basic, toda a investigação subsequente é irrelevante, pois o problema é de tier. P confirma que as VNets spoke estão efetivamente conectadas e com status válido, eliminando falhas de conectividade básica. R inspeciona as rotas efetivas na NIC da VM de origem: se a rota para o destino não existe na tabela de rotas, o problema está no plano de controle e direciona para T. T verifica custom route tables que possam estar bloqueando a propagação inter-hub. Somente após validar toda a cadeia de roteamento faz sentido executar S, que consome mais tempo e recursos e só é diagnóstico útil quando o plano de controle está correto.
A sequência B começa pelo fim, usando Connection Troubleshoot antes de entender o plano de controle, o que desperdiça tempo e pode retornar resultados inconclusivos. A sequência C começa pela inspeção de rotas sem antes confirmar o tier e a conectividade das VNets, o que pode levar a conclusões equivocadas. A sequência D inverte P e Q, investigando conectividade das VNets antes de confirmar que o tier suporta o tráfego pretendido.
Árvore de Troubleshooting: Design a Virtual WAN architecture, including selecting types and services
Legenda:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica |
| 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 identificando o sintoma de falha de conectividade no Virtual WAN. A primeira pergunta sempre valida o tier, pois ela elimina ou confirma a maior classe de limitações de uma só vez. Siga as ramificações respondendo objetivamente cada pergunta com base no que é observável no portal ou via CLI. Cada caminho termina em uma causa nomeada ou em uma ação concreta. Se o caminho chegar ao nó de validação laranja, execute o Connection Troubleshoot do Network Watcher antes de avançar para hipóteses de plano de dados.