Laboratório de Troubleshooting: Identify when to use a policy-based VPN versus a route-based VPN connection
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de infraestrutura de uma empresa relata que a conectividade VPN entre a sede on-premises e uma VNet no Azure parou de funcionar após uma atualização planejada no firewall local. O gateway VPN no Azure foi provisionado há dois anos e nunca apresentou problemas. O administrador coletou as seguintes informações do ambiente:
Gateway Name : vpn-gw-sede
VPN Type : PolicyBased
SKU : Basic
Status : Connected (reported by portal)
BGP : Disabled
IKE Version : IKEv1
Firewall update : Firmware v4.2 -> v4.8
Firewall vendor : Checkpoint (legacy model)
Change applied : NAT rules updated for new DMZ segment
O portal do Azure indica o status da conexão como Connected, mas os usuários reportam que nenhum tráfego de aplicação consegue passar pelo túnel. O time de rede confirma que o link físico entre a sede e o provedor de internet está operacional e com latência normal. A equipe de segurança informa que nenhuma regra de ACL foi alterada no Azure durante a janela de manutenção.
Qual é a causa raiz mais provável do problema observado?
A) O SKU Basic do gateway não suporta a versão IKEv1 após atualizações de plataforma, causando falha silenciosa no túnel
B) A atualização do firmware do firewall alterou os seletores de tráfego configurados no dispositivo local, tornando-os incompatíveis com a política definida no gateway policy-based do Azure
C) O status "Connected" no portal indica que o plano de controle está ativo, mas o BGP desabilitado impede a propagação de rotas, bloqueando o tráfego
D) A atualização das regras de NAT no firewall causou um conflito de endereçamento com o prefixo da VNet no Azure, bloqueando o roteamento na camada 3
Cenário 2 — Decisão de Ação
Uma empresa de manufatura utiliza um route-based VPN gateway com SKU VpnGw2 para conectar três filiais ao ambiente Azure. Durante uma auditoria de capacidade, foi identificado que o ambiente precisa suportar uma quarta filial com um dispositivo VPN legado que opera exclusivamente com IKEv1 e exige seletores de tráfego estáticos baseados em prefixo.
A causa está identificada: o gateway route-based atual suporta IKEv1 em conexões Site-to-Site específicas, mas o dispositivo da quarta filial exige uma configuração de policy-based puro que o gateway route-based não pode emular completamente para esse modelo de equipamento.
O ambiente está em produção. As três conexões existentes estão ativas e críticas. A equipe tem uma janela de manutenção de 4 horas no próximo sábado.
Qual é a ação correta a tomar neste momento?
A) Provisionar um segundo VPN gateway do tipo policy-based em uma nova GatewaySubnet dedicada para atender exclusivamente a quarta filial, mantendo o gateway route-based existente intacto
B) Recriar o gateway existente como policy-based para unificar todas as conexões sob um único gateway compatível com IKEv1
C) Configurar uma custom IPsec policy no gateway route-based existente com IKEv1 forçado e seletores de tráfego manuais para a quarta filial
D) Substituir o dispositivo VPN da quarta filial por um modelo compatível com IKEv2 antes da janela de manutenção
Cenário 3 — Causa Raiz
Um administrador relata que tentou criar uma segunda conexão Site-to-Site em um VPN gateway existente no Azure, mas o portal retornou o seguinte erro:
Error Code : GatewayConnectionCountExceeded
Message : The gateway does not support more than 1 Site-to-Site connection.
Resource : /subscriptions/.../vpnGateways/vpn-gw-legacy
Operation : CreateOrUpdateVirtualNetworkGatewayConnection
O administrador verificou os seguintes detalhes do ambiente antes de abrir um chamado:
Gateway Name : vpn-gw-legacy
Location : East US
SKU : Basic
VPN Type : PolicyBased
Connections : vpn-conn-matriz (Site-to-Site, IKEv1, Status: Connected)
GatewaySubnet : 10.0.255.0/27
VNet Address : 10.0.0.0/16
Uptime : 847 dias
O administrador suspeita que o problema está relacionado ao SKU Basic, que possui limites de throughput e conexões simultâneas inferiores aos SKUs superiores. Ele abre um chamado solicitando upgrade para o SKU VpnGw1.
Qual é a causa raiz real do erro observado?
A) O SKU Basic limita o número de conexões Site-to-Site a 1; o upgrade para VpnGw1 resolveria o problema
B) O tamanho da GatewaySubnet (/27) é insuficiente para suportar múltiplas conexões e está causando o erro de alocação
C) O tipo PolicyBased do gateway impõe o limite de uma única conexão Site-to-Site, independentemente do SKU
D) O gateway atingiu o limite de uptime contínuo e precisa ser reiniciado antes de aceitar novas conexões
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe o seguinte relato: "O túnel VPN entre o Azure e o escritório remoto aparece como conectado no portal, mas nenhum tráfego passa entre as redes."
O gateway configurado é do tipo policy-based. O administrador tem acesso ao portal do Azure, ao dispositivo VPN on-premises e às ferramentas de diagnóstico da plataforma.
Os passos de investigação disponíveis são:
- Passo P: Verificar se os seletores de tráfego configurados no dispositivo on-premises correspondem exatamente aos prefixos definidos na política do gateway Azure
- Passo Q: Executar o VPN Diagnostics no portal do Azure para capturar logs do plano de dados
- Passo R: Confirmar que o status do túnel IKE Fase 1 está estabelecido no dispositivo on-premises
- Passo S: Testar conectividade ponta a ponta com ping de uma VM na VNet para um host on-premises
- Passo T: Verificar se há uma rota estática ou UDR na VNet que possa estar desviando o tráfego para outro próximo salto
Qual é a sequência correta de investigação?
A) S, R, P, Q, T
B) R, Q, P, T, S
C) Q, S, R, P, T
D) R, P, T, Q, S
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista central está na combinação de dois fatos: o portal reporta Connected (o que indica que a Fase 1 do IKE, o plano de controle, está ativa) e nenhum tráfego passa (o que aponta para uma falha no plano de dados, especificamente na Fase 2 do IKE). Em um gateway policy-based, a Fase 2 depende de seletores de tráfego negociados, que são combinações exatas de prefixos de origem e destino. A atualização de firmware que incluiu mudanças nas regras de NAT do firewall pode ter alterado os prefixos declarados nos seletores locais, tornando-os incompatíveis com os configurados no lado Azure.
A informação sobre a latência normal do link físico e a integridade das ACLs no Azure são propositalmente irrelevantes: elas confirmam apenas que o problema não está na camada física nem no controle de acesso do Azure, sem apontar para a causa real.
A alternativa A é incorreta: o SKU Basic suporta IKEv1 nativamente e não sofre impacto de atualizações de plataforma da forma descrita. A alternativa C é o distrator mais perigoso: o BGP desabilitado é a configuração padrão e esperada para um gateway policy-based, e não causa bloqueio de tráfego quando os seletores estão corretos. A alternativa D confunde a camada de problema: um conflito de NAT afetaria o estabelecimento do túnel na Fase 1, não permitiria que o portal reportasse Connected.
Gabarito — Cenário 2
Resposta: A
A restrição crítica do cenário é que as três conexões existentes estão em produção e são críticas. A alternativa B exigiria recriar o gateway existente como policy-based, o que destruiria as três conexões ativas e limitaria o ambiente a uma única conexão Site-to-Site futura, impossibilitando a manutenção das filiais existentes. A alternativa C é tecnicamente atraente, mas o enunciado declara explicitamente que o dispositivo da quarta filial exige policy-based puro incompatível com o que o route-based pode emular para esse modelo específico. A alternativa D ignora a restrição de tempo e transfere o problema para a equipe da filial, sem resolver a necessidade imediata.
A alternativa A resolve o problema sem afetar o ambiente existente: um segundo gateway policy-based em uma GatewaySubnet dedicada (uma VNet pode ter apenas um VPN gateway por GatewaySubnet, mas é possível usar peering ou arquiteturas hub-spoke para integrar ambos) atende exclusivamente a filial legada sem nenhum impacto nas conexões em produção. Esta é a ação correta dado o conjunto de restrições.
Gabarito — Cenário 3
Resposta: C
O erro GatewayConnectionCountExceeded com a mensagem explícita de limite de 1 conexão, combinado com o tipo PolicyBased visível na configuração, aponta diretamente para a limitação arquitetural do tipo de gateway, não do SKU. Gateways policy-based no Azure suportam no máximo uma conexão Site-to-Site, independentemente do SKU utilizado.
O distrator mais perigoso aqui é a alternativa A: o diagnóstico do administrador é plausível porque o SKU Basic de fato possui limites, mas esses limites dizem respeito a throughput e funcionalidades (como BGP e P2S), não ao número de conexões Site-to-Site. Um upgrade para VpnGw1 não resolveria o problema, pois o VPN Type continuaria sendo PolicyBased. O resultado seria tempo e custo desperdiçados, com o erro persistindo após a migração. A solução correta seria migrar para um gateway route-based, o que exige recriar o recurso.
A alternativa B é irrelevante: o tamanho da GatewaySubnet não impacta o número de conexões permitidas. A alternativa D é tecnicamente inválida: uptime não é um fator limitante para criação de conexões.
Gabarito — Cenário 4
Resposta: B
A sequência correta é R, Q, P, T, S, que segue a lógica de diagnóstico progressivo do mais fundamental para o mais específico:
R confirma que a Fase 1 do IKE está estabelecida no dispositivo on-premises. Se a Fase 1 falhou, o restante da investigação é irrelevante. Este é sempre o primeiro passo em qualquer diagnóstico de VPN.
Q executa o VPN Diagnostics no portal do Azure para capturar evidências do plano de dados do lado Azure, identificando se o problema está no túnel em si ou além dele.
P investiga os seletores de tráfego, que são o componente mais crítico de um gateway policy-based. Uma incompatibilidade aqui explica exatamente o sintoma: túnel reportado como ativo, mas sem tráfego passando.
T verifica se há uma rota ou UDR desviando o tráfego antes que ele alcance o gateway, o que é uma causa colateral comum em ambientes com roteamento complexo.
S é o passo de validação final: apenas após eliminar as hipóteses acima faz sentido testar conectividade ponta a ponta, pois o resultado positivo ou negativo do ping terá contexto diagnóstico suficiente para ser interpretado corretamente.
As alternativas A e C cometem o erro de iniciar com testes ponta a ponta antes de validar o estado do túnel, o que gera ruído diagnóstico sem eliminar hipóteses. A alternativa D inverte P e T em relação à ordem ideal, investigando rotas antes de validar os seletores, que são a causa mais provável em um cenário policy-based.
Árvore de Troubleshooting: Identify when to use a policy-based VPN versus a route-based VPN connection
Legenda de cores:
| 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 | Verificação ou validação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz identificando o sintoma observado. Siga a ramificação correspondendo cada pergunta ao que você consegue confirmar no ambiente: comece sempre pela pergunta mais fundamental (tipo do gateway, estado da conexão, estado da Fase 1 IKE) antes de avançar para verificações mais específicas como seletores de tráfego ou rotas. Cada caminho termina em uma causa nomeada ou em uma ação concreta, eliminando hipóteses progressivamente sem saltar para conclusões prematuras.