Laboratório de Troubleshooting: Deploy a gateway into a virtual hub
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de rede implantou com sucesso um gateway de VPN site-to-site em um virtual hub da região East US. O hub faz parte de um Virtual WAN do tipo Standard criado há seis meses. Existem três spokes conectados ao hub, todos com conectividade funcional entre si.
Após a implantação do gateway, a equipe tentou criar uma conexão com um branch corporativo. A conexão foi criada no portal, mas permanece no estado Failed. O branch utiliza um dispositivo VPN certificado pela Microsoft e o endereço IP público do dispositivo foi corretamente informado.
A equipe verifica os logs do gateway e observa o seguinte:
IKE diagnostic log:
[2026-03-20 14:32:11] Initiating IKEv2 SA negotiation with 203.0.113.45
[2026-03-20 14:32:11] Sending IKE_SA_INIT request
[2026-03-20 14:32:41] Retransmit 1 of IKE_SA_INIT request
[2026-03-20 14:33:11] Retransmit 2 of IKE_SA_INIT request
[2026-03-20 14:33:41] ERROR: No response received from peer. IKE negotiation timed out.
A equipe também confirma que o BGP está habilitado na conexão e que a chave pré-compartilhada foi configurada em ambos os lados. O Virtual WAN possui uma política de roteamento customizada aplicada no hub, redirecionando tráfego de gerenciamento para um NVA.
Qual é a causa raiz mais provável da falha?
A) A política de roteamento customizada do hub está interceptando o tráfego IKE antes que ele chegue ao gateway.
B) O dispositivo VPN remoto não está respondendo às requisições IKE, indicando bloqueio de tráfego UDP 500/4500 no lado do branch.
C) O BGP habilitado na conexão está conflitando com a negociação IKEv2, pois o Virtual WAN não suporta BGP em conjunto com IKEv2.
D) A chave pré-compartilhada configurada no portal não foi propagada ao gateway porque o provisionamento ainda não foi concluído.
Cenário 2 — Decisão de Ação
A equipe de plataforma identificou que um gateway de ExpressRoute em um virtual hub de produção está com a unidade de escala subdimensionada. O gateway foi provisionado com escala 1 (1 Gbps), mas a medição de tráfego dos últimos 30 dias mostra picos consistentes acima de 900 Mbps, com episódios de descarte de pacotes registrados.
O ambiente possui as seguintes restrições:
- O circuito ExpressRoute conecta a sede corporativa principal e suporta operações financeiras em tempo real
- A janela de manutenção aprovada começa em 72 horas
- Existe um circuito de backup via VPN site-to-site configurado, mas não testado nos últimos 4 meses
- A equipe tem permissão para executar a mudança imediatamente se necessário
Qual é a ação correta a tomar neste momento?
A) Aumentar a unidade de escala do gateway imediatamente, pois a operação de redimensionamento é não disruptiva e pode ser feita fora da janela de manutenção.
B) Aguardar a janela de manutenção, testar o circuito de backup VPN antes da mudança e então aumentar a unidade de escala dentro da janela aprovada.
C) Ativar o circuito de backup VPN imediatamente para liberar carga do ExpressRoute e depois redimensionar o gateway fora da janela, sem necessidade de testes adicionais.
D) Abrir um chamado na Microsoft para solicitar aumento de capacidade emergencial, pois alterações de unidade de escala em gateways de produção exigem aprovação do suporte.
Cenário 3 — Causa Raiz
Uma organização mantém dois virtual hubs em uma mesma Virtual WAN Standard: hub-eastus e hub-westus. Cada hub tem um gateway de VPN site-to-site provisionado e múltiplos spokes associados.
Um novo requisito de negócio exige que filiais conectadas ao hub-eastus alcancem workloads em spokes do hub-westus. A equipe ativou o roteamento interhub na configuração da Virtual WAN e aguardou 20 minutos.
Após o período de aguardo, filiais do hub-eastus ainda não conseguem alcançar spokes do hub-westus. A equipe verifica o effective routes de uma VM em um spoke do hub-westus e não encontra rotas referentes às sub-redes das filiais do hub-eastus.
A configuração dos dois gateways está mostrada abaixo:
| Configuração | hub-eastus | hub-westus |
|---|---|---|
| SKU | VpnGw1 | VpnGw1 |
| Unidade de escala | 1 | 1 |
| BGP habilitado | Sim | Não |
| Branch-to-branch | Habilitado | Habilitado |
A equipe menciona que o hub-westus foi criado recentemente e ainda não possui nenhuma VNet spoke formalmente associada via portal, embora as VNets estejam com peering configurado manualmente.
Qual é a causa raiz do problema de roteamento?
A) A assimetria de BGP entre os dois gateways impede a propagação de rotas interhub, pois ambos precisam ter BGP habilitado para o roteamento transitivo funcionar.
B) As VNets do hub-westus foram conectadas via peering manual em vez de conexão de spoke gerenciada pela Virtual WAN, impedindo que o Virtual Hub Router aprenda e anuncie essas rotas.
C) A unidade de escala 1 nos dois gateways é insuficiente para suportar roteamento interhub; é necessário escalar para pelo menos 2 em ambos os hubs.
D) O intervalo de 20 minutos não foi suficiente; o roteamento interhub em Virtual WAN pode levar até 4 horas para propagar rotas após a ativação.
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe o seguinte relato: "O gateway de VPN ponto a site do virtual hub parou de aceitar novas conexões de clientes remotos. Clientes já conectados continuam funcionando normalmente."
Os passos de investigação disponíveis são:
- Verificar o número de conexões ativas no gateway e comparar com o limite máximo da unidade de escala configurada
- Confirmar se o certificado raiz de autenticação configurado no gateway está válido e não expirado
- Verificar se houve mudança recente na unidade de escala ou no SKU do gateway
- Checar se novas solicitações de conexão aparecem nos logs de diagnóstico do gateway com erro específico
- Validar se o pool de endereços IP do cliente VPN tem endereços disponíveis ou está esgotado
Qual é a sequência correta de diagnóstico para esse sintoma?
A) 3 → 1 → 5 → 4 → 2
B) 4 → 1 → 5 → 2 → 3
C) 2 → 3 → 4 → 1 → 5
D) 4 → 5 → 1 → 2 → 3
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
O log de diagnóstico IKE é a pista central. O gateway Azure enviou corretamente a requisição IKE_SA_INIT e realizou retransmissões, mas nunca recebeu resposta do peer remoto no endereço 203.0.113.45. Esse padrão específico de timeout sem resposta indica que o tráfego não está chegando ao dispositivo remoto ou está sendo bloqueado antes de retornar. As portas UDP 500 (IKE) e 4500 (NAT-T) devem estar abertas no firewall do branch para que a negociação IKEv2 ocorra.
A informação sobre a política de roteamento customizada para tráfego de gerenciamento é o elemento irrelevante do cenário. Políticas de roteamento em Virtual WAN afetam tráfego de dados após o túnel estar estabelecido; elas não interferem no plano de controle da negociação IKE, que ocorre antes de qualquer túnel existir.
A alternativa C representa um equívoco técnico grave: o Virtual WAN suporta plenamente BGP com IKEv2, pois são planos completamente distintos. Agir com base nessa alternativa levaria a desabilitar o BGP desnecessariamente, quebrando o roteamento dinâmico quando o túnel finalmente fosse estabelecido.
Gabarito — Cenário 2
Resposta: B
O conjunto de restrições do cenário define a resposta correta por eliminação. A operação de aumento de unidade de escala em um gateway de ExpressRoute em virtual hub é disruptiva: ela causa interrupção temporária da conectividade durante o redimensionamento. Portanto, executar imediatamente (alternativa A) colocaria as operações financeiras em risco sem nenhuma contingência validada.
O circuito de backup VPN não foi testado em 4 meses, o que significa que ativá-lo diretamente sem validação prévia (alternativa C) seria igualmente arriscado. A alternativa correta combina as duas salvaguardas necessárias: validar o backup antes de precisar dele e executar a mudança dentro da janela aprovada, que existe justamente para proteger o ambiente de produção.
A alternativa D representa um equívoco de processo: alterações de unidade de escala são operações self-service e não requerem envolvimento do suporte Microsoft, exceto em casos de falha técnica.
Gabarito — Cenário 3
Resposta: B
A pista decisiva está na observação de que as VNets do hub-westus foram conectadas via peering manual em vez de conexão de spoke gerenciada pela Virtual WAN. No modelo de Virtual WAN, o Virtual Hub Router aprende e anuncia rotas apenas de conexões registradas como spoke connections dentro da Virtual WAN. VNets com peering configurado manualmente, fora do modelo de spoke da Virtual WAN, são invisíveis ao plano de roteamento do hub e, portanto, suas rotas não são propagadas interhub nem para gateways conectados.
A assimetria de BGP descrita na alternativa A é um detalhe verdadeiro mas irrelevante para este problema específico: o roteamento interhub na Virtual WAN utiliza o Virtual Hub Router como mecanismo primário, independentemente do estado do BGP nos gateways de branch. A ausência de BGP em um gateway afeta a propagação de rotas de branches, mas não impede o roteamento entre spokes de hubs distintos quando as conexões de spoke estão corretamente registradas.
O distrator mais perigoso é a alternativa D: aguardar mais tempo sem investigar a causa raiz real atrasaria a resolução indefinidamente, pois o problema não é de convergência, mas de arquitetura de conexão.
Gabarito — Cenário 4
Resposta: B
O sintoma central é objetivo: novas conexões falham, mas conexões existentes permanecem ativas. Esse comportamento aponta para um limite de capacidade ou recurso esgotado, não para uma falha de autenticação ou certificado, que afetaria todas as conexões indistintamente.
A sequência correta começa em 4 (verificar logs para obter o erro específico) porque o log de diagnóstico frequentemente entrega diretamente o motivo da recusa, evitando investigação desnecessária. Com o erro em mãos, parte-se para 1 (verificar se o limite de conexões simultâneas da unidade de escala foi atingido) e 5 (verificar se o pool de endereços IP do cliente está esgotado), que são as duas causas mais comuns para esse sintoma exato. O passo 2 (verificar certificado raiz) vem depois porque, se o certificado estivesse expirado, nenhuma conexão funcionaria. O passo 3 (verificar mudanças recentes) é investigação de contexto histórico, útil ao final para correlacionar causa com evento.
A sequência C comete o erro clássico de começar pela hipótese mais familiar ao investigador (verificar o certificado) em vez de pelo dado mais objetivo disponível (o log de erro).
Árvore de Troubleshooting: Deploy a gateway into a virtual hub
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (raiz da árvore) |
| Azul médio | Pergunta de diagnóstico |
| 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 descrevendo o sintoma observado e responda cada pergunta de diagnóstico com base no que pode ser verificado diretamente no portal, nos logs ou via CLI. Siga o caminho indicado pela resposta até chegar a um nó de causa (vermelho) ou ação (verde). Nunca pule um nó de validação intermediária (laranja), pois eles protegem contra diagnósticos prematuros que levam a ações corretivas aplicadas no problema errado.