Laboratório de Troubleshooting: Seleção de SKU de Gateway de Rede Virtual para VPN Point-to-Site
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma empresa implantou um gateway VPN há seis meses com o SKU Basic para atender um grupo de 40 usuários remotos. O ambiente funcionou sem incidentes durante esse período. Recentemente, a empresa adquiriu uma subsidiária e o número de conexões P2S simultâneas previsto saltou para 200. A equipe de rede decidiu fazer o upgrade do gateway para o SKU VpnGw1 pelo portal do Azure.
Durante a tentativa de upgrade, a operação falha com a seguinte mensagem:
Code: GatewaySkuNotSupported
Message: Resize operation is not supported from Basic to VpnGw1.
The gateway must be deleted and recreated with the desired SKU.
Target SKU: VpnGw1
Current SKU: Basic
O analista responsável revisa o histórico e confirma que o gateway está saudável, as conexões ativas estão funcionando e não há alertas no painel de diagnóstico. Ele considera que o erro pode estar relacionado à versão da geração do gateway (Generation1 versus Generation2) ou a alguma configuração de rede virtual que impede o resize.
Qual é a causa raiz da falha?
A) O gateway Basic pertence à Generation1 e o VpnGw1 à Generation2, e upgrades entre gerações distintas não são suportados pelo portal
B) O SKU Basic não suporta a operação de resize para nenhum outro SKU; a migração exige exclusão e recriação do gateway
C) A operação de resize falhou porque há conexões P2S ativas no momento da tentativa, e o gateway precisa estar sem conexões para ser redimensionado
D) O erro indica que a sub-rede do gateway (GatewaySubnet) tem um prefixo menor que /27, impedindo a alocação de recursos do SKU superior
Cenário 2 — Decisão de Ação
A equipe de rede de uma empresa identificou que o gateway VPN P2S, atualmente com SKU VpnGw1, está consumindo 94% da capacidade de conexões simultâneas de forma consistente nos últimos cinco dias. O SKU VpnGw1 suporta 650 conexões P2S. A análise mostra que picos ocorrem entre 09h e 11h e entre 14h e 16h no fuso horário local.
A causa foi confirmada: o volume de usuários remotos cresceu além da capacidade planejada para esse SKU.
O ambiente tem as seguintes restrições:
- O gateway está em produção com SLA contratual ativo
- Uma janela de manutenção programada está disponível na próxima sexta-feira, às 23h
- A equipe tem permissão para executar upgrades de SKU sem aprovação adicional
- Há uma solicitação interna urgente para resolver o problema ainda hoje
Qual é a ação correta a tomar neste momento?
A) Executar o upgrade de SKU imediatamente para VpnGw2, aproveitando que a operação de resize entre SKUs da família VpnGw é suportada e não causa indisponibilidade prolongada
B) Criar um segundo gateway VPN em uma VNet separada e redirecionar metade dos usuários manualmente, distribuindo a carga antes da janela de manutenção
C) Aguardar a janela de manutenção programada na sexta-feira para executar o upgrade, pois a operação de resize causa indisponibilidade temporária e deve ser feita em horário controlado
D) Aumentar o número de conexões P2S configuradas no gateway atual sem alterar o SKU, ajustando o parâmetro de limite de conexões nas configurações avançadas do portal
Cenário 3 — Causa Raiz
Um administrador relata que clientes remotos com Windows 11 estão conseguindo se conectar via VPN P2S normalmente, mas clientes com macOS Ventura recebem a seguinte mensagem ao tentar estabelecer a conexão:
VPN Connection Failed
Error: The network connection between your computer and the VPN server
could not be established because the remote server is not responding.
Error code: 800
O gateway está configurado com SKU VpnGw1. O certificado raiz foi exportado corretamente e carregado no gateway. Os clientes macOS receberam o perfil de cliente VPN gerado pelo portal. O administrador verifica que o gateway está operacional e que outros protocolos de rede na VNet funcionam normalmente. Ele também confirma que a assinatura do Azure não atingiu nenhuma cota de gateway.
A equipe informa adicionalmente que o gateway foi criado há dois anos com configuração padrão e nunca foi modificado desde então.
Qual é a causa raiz do problema?
A) O certificado raiz carregado no gateway expirou e precisa ser renovado para que novos clientes possam se autenticar
B) O gateway está configurado para aceitar apenas o protocolo SSTP, que não é suportado nativamente pelo macOS; clientes macOS requerem IKEv2 ou OpenVPN
C) O perfil de cliente VPN para macOS precisa ser gerado separadamente usando o Azure CLI, pois o portal não gera perfis compatíveis com macOS Ventura
D) O SKU VpnGw1 tem um limite de 10 conexões simultâneas para clientes não Windows, e esse limite foi atingido
Cenário 4 — Sequência de Diagnóstico
Um cliente relata que não consegue estabelecer uma conexão P2S com o gateway VPN. O analista de suporte precisa investigar o problema. Abaixo estão cinco passos de diagnóstico possíveis, apresentados fora de ordem:
[P] Verificar se o protocolo configurado no gateway (SSTP, IKEv2 ou OpenVPN)
e compativel com o cliente do usuario
[Q] Verificar se o gateway VPN esta no estado "Running" no portal do Azure
[R] Confirmar se o certificado do cliente foi instalado corretamente
no repositorio correto do sistema operacional
[S] Verificar se o perfil de cliente VPN foi gerado apos a ultima
alteracao de configuracao do gateway
[T] Analisar os logs de diagnostico do gateway para identificar
tentativas de conexao rejeitadas e seus codigos de erro
Qual sequência representa a ordem correta de diagnóstico progressivo?
A) R, P, S, Q, T
B) Q, P, R, S, T
C) T, Q, P, R, S
D) S, R, Q, T, P
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A mensagem de erro é direta e não ambígua: Resize operation is not supported from Basic to VpnGw1. O SKU Basic é uma categoria isolada na hierarquia de SKUs de gateway VPN do Azure. Diferente dos SKUs da família VpnGw1 a VpnGw5, que permitem resize entre si dentro da mesma geração, o Basic não participa desse modelo de upgrade incremental. A única forma de migrar de Basic para qualquer outro SKU é excluir o gateway existente e recriá-lo com o SKU desejado, causando indisponibilidade.
A pista decisiva no enunciado é a própria mensagem de erro, que nomeia explicitamente a restrição de resize. O histórico de seis meses de operação saudável e a ausência de alertas são informações irrelevantes para o diagnóstico: elas descrevem o estado operacional do gateway, não a causa da falha de upgrade.
A alternativa A confunde a causa com um detalhe real, mas incorreto: embora gerações diferentes tenham restrições de compatibilidade, o impedimento aqui não é inter-geração, é a natureza isolada do SKU Basic. A alternativa C é tecnicamente falsa: a presença de conexões ativas não bloqueia operações de resize nos SKUs que as suportam. A alternativa D introduz um requisito de sub-rede que não tem relação com a operação de resize.
O distrator mais perigoso é A, pois leva o analista a investigar geração de gateway e compatibilidade, perdendo tempo antes de executar a ação correta: recriar o gateway.
Gabarito — Cenário 2
Resposta: C
A causa já foi confirmada no enunciado (capacidade excedida), mas as restrições do ambiente determinam a ação correta. O ponto crítico é que a operação de resize em gateways VPN do Azure, mesmo entre SKUs da família VpnGw que a suportam, causa indisponibilidade temporária. Executar essa operação durante o horário de pico em um ambiente com SLA contratual ativo representa um risco desnecessário quando existe uma janela de manutenção disponível em poucos dias.
A solicitação interna urgente é uma informação de pressão contextual, não uma restrição técnica que justifique ignorar o SLA e o risco de indisponibilidade em produção. Diagnósticos e planejamentos sólidos incluem resistir à urgência quando a ação imediata viola contratos ou aumenta o risco.
A alternativa A representa a ação tecnicamente correta aplicada no momento errado: o resize é suportado e eventual, mas executá-lo fora de janela de manutenção em produção é imprudente. A alternativa B descreve uma solução arquitetural válida em outros contextos, mas é complexa, demorada e não resolve o problema dentro das restrições dadas. A alternativa D é falsa: não existe parâmetro de limite de conexões ajustável independente do SKU; a capacidade é determinada pelo SKU escolhido.
Gabarito — Cenário 3
Resposta: B
O sintoma central é a falha exclusiva em clientes macOS, enquanto clientes Windows 11 funcionam normalmente. Esse comportamento assimétrico por sistema operacional é a pista diagnóstica decisiva. O protocolo SSTP é exclusivo para Windows e não é suportado pelo macOS. Se o gateway foi criado com configuração padrão há dois anos e nunca modificado, é altamente provável que a configuração padrão da época tenha habilitado apenas SSTP, que era o protocolo predominante para P2S antes da adoção ampla de IKEv2 e OpenVPN. Clientes macOS precisam de IKEv2 ou OpenVPN para estabelecer conexão P2S.
A informação sobre a assinatura não ter atingido cota e o gateway estar operacional é irrelevante para o diagnóstico: ela apenas confirma que o problema não é de disponibilidade de infraestrutura.
A alternativa A é plausível como causa genérica de falha de autenticação, mas não explicaria por que o problema afeta apenas macOS e não Windows. A alternativa C é falsa: o portal do Azure gera perfis de cliente compatíveis com múltiplos sistemas operacionais. A alternativa D é completamente fictícia: não existe limite diferenciado de conexões por sistema operacional nos SKUs VpnGw.
O distrator mais perigoso é A, pois leva o analista a investigar e renovar certificados, o que não resolverá o problema e consome tempo valioso.
Gabarito — Cenário 4
Resposta: B
A sequência correta é Q, P, R, S, T, que segue a lógica de diagnóstico do mais simples e abrangente para o mais específico e profundo.
O raciocínio progressivo correto é:
- Q — Confirmar que o gateway está operacional antes de qualquer investigação de configuração ou cliente. Se o gateway não estiver em estado "Running", todos os outros passos são irrelevantes.
- P — Verificar compatibilidade de protocolo entre gateway e cliente. Um mismatch de protocolo bloqueará qualquer tentativa independente de certificados ou perfis.
- R — Com protocolo confirmado, verificar se o certificado do cliente está instalado no local correto do sistema operacional, pois esse é um erro frequente de configuração de cliente.
- S — Confirmar se o perfil VPN está atualizado em relação à configuração atual do gateway. Um perfil desatualizado pode conter endereços ou configurações obsoletas.
- T — Somente após esgotar as verificações de configuração, analisar logs de diagnóstico para identificar padrões de rejeição não cobertos pelos passos anteriores.
As alternativas A, C e D invertem ou embaralham essa progressão, fazendo o analista mergulhar em detalhes específicos (certificados, logs) antes de validar pré-requisitos básicos (gateway ativo, protocolo compatível), o que desperdiça tempo e pode gerar diagnósticos incorretos.
Árvore de Troubleshooting: Seleção de SKU de Gateway de Rede Virtual para VPN Point-to-Site
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (decisão verificável) |
| 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 siga as ramificações respondendo cada pergunta diagnóstica com o que você pode verificar diretamente no ambiente. Perguntas fechadas (sim ou não, todos ou alguns) forçam a eliminação de hipóteses antes de avançar para o nível seguinte. Quando você chegar a um nó vermelho, a causa está identificada; o nó verde imediatamente subsequente indica a ação corretiva correspondente. Nós laranja indicam pontos onde a investigação pode se aprofundar antes de concluir o diagnóstico.