Laboratório de Troubleshooting: Select an appropriate virtual network gateway SKU for site-to-site VPN requirements
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de infraestrutura de uma empresa reporta que uma conexão site-to-site VPN entre a filial de São Paulo e o Azure foi estabelecida com sucesso há três semanas. O gateway está no SKU VpnGw1 com VPN Type RouteBased. Na última semana, a empresa adquiriu dois novos parceiros e tentou adicionar conexões site-to-site para cada um deles. Ambas as tentativas falharam com o mesmo erro.
O engenheiro responsável verifica o estado atual do gateway:
$ az network vnet-gateway show \
--name gw-hub-prod \
--resource-group rg-networking \
--query "{SKU:sku.name, VpnType:vpnType, ActiveActive:activeActive, Connections:ipConfigurations}" \
-o json
{
"SKU": "VpnGw1",
"VpnType": "RouteBased",
"ActiveActive": false,
"Connections": [
{ "id": "/subscriptions/.../connections/conn-matriz" },
{ "id": "/subscriptions/.../connections/conn-parceiro1" },
{ "id": "/subscriptions/.../connections/conn-parceiro2" }
]
}
O engenheiro observa que as conexões para os parceiros aparecem como criadas no portal do Azure, mas o status de ambas é Not Connected. A conexão original com a matriz permanece estável. O gateway foi recentemente atualizado de Basic para VpnGw1 há dois meses. A região utilizada é Brazil South, que suporta todos os SKUs da família VpnGw.
Qual é a causa raiz do problema?
A) O SKU VpnGw1 não suporta mais de uma conexão simultânea; é necessário migrar para VpnGw2.
B) O limite de túneis site-to-site do SKU VpnGw1 foi atingido, pois ele suporta no máximo 30 túneis, e a terceira conexão excedeu a capacidade de processamento simultâneo da instância.
C) As conexões com os parceiros estão com status Not Connected porque os Local Network Gateways correspondentes foram criados com endereços IP de gateway on-premises incorretos ou ausentes.
D) A configuração ActiveActive: false impede que o gateway aceite mais de uma conexão simultânea em ambientes com múltiplos parceiros.
Cenário 2 — Decisão de Ação
A causa do problema foi identificada: o VPN Gateway em produção está no SKU Basic com VPN Type PolicyBased, e a empresa precisa habilitar BGP para suportar o roteamento dinâmico exigido por um novo parceiro estratégico. A janela de manutenção aprovada é de 4 horas, programada para esta madrugada.
O ambiente possui as seguintes restrições:
- O gateway está em produção e suporta atualmente uma conexão site-to-site ativa com a matriz
- A conexão com a matriz usa rotas estáticas e não pode ser interrompida por mais de 30 minutos
- A equipe possui permissões de Contributor no resource group de rede
- Não há um gateway de backup disponível
Qual é a ação correta a tomar dentro da janela de manutenção?
A) Alterar o VPN Type do gateway existente de PolicyBased para RouteBased diretamente no portal do Azure, sem excluir o recurso, e depois habilitar BGP nas configurações avançadas.
B) Excluir o gateway atual, provisionar um novo gateway com SKU VpnGw1 e VPN Type RouteBased, recriar a conexão com a matriz usando rotas estáticas e configurar a nova conexão com BGP para o parceiro.
C) Provisionar um segundo gateway na mesma VNet com SKU VpnGw1 e VPN Type RouteBased em paralelo, migrar a conexão da matriz para o novo gateway e depois excluir o gateway Basic.
D) Redimensionar o SKU do gateway de Basic para VpnGw1 usando o comando az network vnet-gateway update sem excluir o recurso, o que preserva as conexões existentes e permite habilitar BGP em seguida.
Cenário 3 — Causa Raiz
Um administrador de rede relata que o throughput da conexão site-to-site VPN entre o datacenter on-premises e o Azure está consistentemente limitado a aproximadamente 100 Mbps, mesmo durante horários de baixo uso. O gateway foi provisionado há seis meses pelo time anterior.
O administrador coleta as seguintes informações:
$ az network vnet-gateway show \
--name gw-corp-eastus \
--resource-group rg-network-prod \
--query "{SKU:sku.name, Tier:sku.tier, VpnType:vpnType, Generation:vpnGatewayGeneration}" \
-o json
{
"SKU": "VpnGw1",
"Tier": "VpnGw1",
"VpnType": "RouteBased",
"Generation": "Generation1"
}
Testes de latência entre o datacenter e o Azure mostram valores normais (12 ms). O link MPLS contratado pelo datacenter tem capacidade de 500 Mbps e está operando a 40% de utilização. O ISP confirmou que não há throttling aplicado ao tráfego de saída. A conexão usa IKEv2 e o túnel está em estado Connected.
Qual é a causa raiz da limitação de throughput?
A) O protocolo IKEv2 possui overhead de encriptação superior ao IKEv1, reduzindo o throughput efetivo do túnel para aproximadamente 100 Mbps no SKU VpnGw1.
B) O SKU VpnGw1 na Generation1 possui throughput agregado máximo de 650 Mbps, mas esse valor é distribuído entre todos os túneis ativos; com múltiplos túneis, a banda disponível por túnel pode ser inferior ao esperado.
C) O throughput máximo de um único túnel site-to-site no SKU VpnGw1, independentemente da geração, é limitado a 100 Mbps por túnel; o limite de 650 Mbps é o agregado total do gateway.
D) O link MPLS de 500 Mbps está sendo o gargalo real, pois a utilização de 40% em um link de 500 Mbps representa 200 Mbps consumidos, deixando apenas 100 Mbps disponíveis para o túnel VPN.
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte relato: "O VPN Gateway foi migrado de SKU VpnGw2 para VpnGw3 ontem à tarde para suportar mais túneis. Desde então, três filiais relatam que a conectividade com o Azure está intermitente, caindo e reconectando a cada 5 a 10 minutos."
Os passos de investigação disponíveis são:
- Verificar os logs de diagnóstico do gateway no Log Analytics para identificar eventos de renegociação de IKE ou erros de autenticação após o redimensionamento.
- Confirmar se o redimensionamento de SKU foi concluído com sucesso e se o gateway está em estado Succeeded no Azure.
- Verificar se as conexões afetadas possuem BGP habilitado e se os peers BGP estão com status Connected no gateway redimensionado.
- Comparar as configurações de Dead Peer Detection (DPD) e timers de IKE entre os dispositivos on-premises das filiais e o novo SKU do gateway.
- Checar se o endereço IP público do gateway foi alterado durante o redimensionamento e se os dispositivos on-premises das filiais foram atualizados com o novo IP.
Qual é a sequência correta de investigação?
A) 2, 5, 1, 3, 4
B) 1, 2, 4, 5, 3
C) 3, 1, 5, 2, 4
D) 2, 1, 5, 4, 3
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: C
A pista decisiva está no output do comando: as conexões aparecem como criadas no Azure, mas com status Not Connected. Isso significa que o problema não é de capacidade do SKU nem de configuração do gateway em si, mas de negociação de túnel com o endpoint remoto. O status Not Connected indica que o IKE handshake não foi completado, o que acontece quando o Local Network Gateway associado a cada conexão contém informações incorretas sobre o gateway on-premises do parceiro, especialmente o endereço IP público.
O distrator A é incorreto: o VpnGw1 suporta até 30 túneis, e apenas três conexões foram criadas. O distrator B confunde o limite agregado do gateway com uma limitação de conexões simultâneas, além de aplicar lógica de saturação onde não há evidência de sobrecarga. O distrator D é o mais perigoso: o campo ActiveActive: false descreve alta disponibilidade com dois endereços IP públicos, e não limita o número de conexões suportadas. Agir com base no distrator D levaria a uma reconfiguração desnecessária do gateway, sem resolver o problema real.
A informação sobre o gateway ter sido atualizado de Basic para VpnGw1 há dois meses é irrelevante para o diagnóstico: é um detalhe de histórico que não tem relação com o status das novas conexões.
Gabarito — Cenário 2
Resposta: B
O VPN Type de um gateway não pode ser alterado após o provisionamento. Isso elimina diretamente a alternativa A. A restrição técnica fundamental é que migrar de PolicyBased para RouteBased exige a exclusão e recriação do gateway. Dado que a janela de manutenção é de 4 horas e a interrupção máxima tolerada é de 30 minutos, a alternativa B é viável: provisionar um novo gateway VpnGw1 RouteBased e recriar a conexão com a matriz dentro da janela.
A alternativa C parece atraente, mas é tecnicamente inviável: o Azure não permite dois VPN Gateways na mesma VNet simultaneamente. A alternativa D é o distrator mais perigoso: embora seja possível redimensionar o SKU de Basic para VpnGw1 com az network vnet-gateway update, isso não altera o VPN Type. O gateway continuaria PolicyBased após o redimensionamento, tornando impossível habilitar BGP. Executar essa ação e depois descobrir que o VPN Type não mudou é um erro que consome tempo crítico da janela de manutenção.
Gabarito — Cenário 3
Resposta: C
O limite de 100 Mbps por túnel no SKU VpnGw1 é uma restrição real e documentada pela Microsoft. O valor de 650 Mbps frequentemente mencionado é o throughput agregado do gateway, aplicável quando múltiplos túneis somam essa capacidade. Para um único túnel site-to-site, o teto é significativamente menor. Essa distinção entre throughput por túnel e throughput agregado é um ponto de confusão comum no dimensionamento de gateways.
O distrator A é factualmente incorreto: o protocolo IKEv2 não reduz o throughput para 100 Mbps por design; o overhead de encriptação existe, mas não é o fator limitante neste contexto. O distrator B está parcialmente correto sobre a distribuição de banda entre túneis, mas não identifica o limite por túnel como causa raiz. O distrator D é o mais perigoso, pois usa dados numéricos plausíveis do enunciado (40% de 500 Mbps = 200 Mbps), criando uma narrativa convincente que atribui a culpa ao link MPLS, ignorando completamente a limitação do SKU. A informação sobre a latência de 12 ms e o estado do túnel como Connected é deliberadamente irrelevante: confirma que a conectividade existe, mas não tem relação com o throughput.
Gabarito — Cenário 4
Resposta: A
A sequência correta é 2, 5, 1, 3, 4.
O ponto de partida obrigatório é confirmar se o redimensionamento em si foi concluído com sucesso (passo 2): um gateway em estado de provisionamento parcial ou com falha pode exibir comportamento imprevisível. Em seguida, verificar se o endereço IP público do gateway foi alterado (passo 5) é crítico, pois redimensionamentos de SKU podem, em alguns cenários, resultar em um novo IP público. Se os dispositivos on-premises ainda apontam para o IP antigo, os túneis cairão ciclicamente ao tentar renegociar. Depois, examinar os logs de diagnóstico (passo 1) fornece evidência concreta sobre o que está ocorrendo durante as quedas. A verificação de BGP (passo 3) vem em seguida, pois é específica para conexões que usam roteamento dinâmico. Por último, a análise dos timers de DPD (passo 4) é o nível mais granular de investigação, aplicável quando as causas mais prováveis já foram descartadas.
A sequência B começa pelos logs antes de confirmar se o gateway está sequer operacional, o que inverte a lógica de triagem. A sequência C começa por BGP, que é específico e não é o ponto de partida correto quando a falha é generalizada e afeta múltiplas filiais. A sequência D é a segunda mais plausível, mas omite a verificação de IP público antes dos logs, perdendo a causa mais comum e mais rapidamente verificável em cenários pós-redimensionamento.
Árvore de Troubleshooting: Select an appropriate virtual network gateway SKU for site-to-site VPN requirements
Legenda:
| Cor | Significado |
|---|---|
| Azul escuro | Sintoma inicial ou ponto de entrada |
| Azul | Pergunta diagnóstica objetiva |
| Vermelho | Causa identificada que exige recriação ou provisionamento |
| Verde | Ação corretiva ou resolução aplicável |
| Laranja | Validação ou verificação intermediária antes de decidir |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma geral e siga as ramificações respondendo cada pergunta com o que você observa no ambiente. As perguntas azuis são verificáveis diretamente no portal do Azure ou via CLI. Quando chegar a um nó vermelho, a causa exige replanejamento estrutural; quando chegar a um nó verde, a ação pode ser executada dentro do escopo operacional normal. Os nós laranjas indicam que é necessário coletar mais evidências antes de decidir qual caminho seguir.