Laboratório de Troubleshooting: Select and Configure a Tunnel Type
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de rede reporta que a conexão site-to-site entre o ambiente on-premises e o Azure foi estabelecida com sucesso por vários meses. Após uma manutenção de rotina no firewall perimetral on-premises, a conexão VPN parou de subir. O gateway VPN do Azure está com status Connected no portal, mas o túnel aparece como Disconnected do lado on-premises.
O administrador coleta as seguintes informações:
# Saída do diagnóstico no gateway on-premises
IKE Phase 1: FAILED
Error: No proposal chosen
Local proposal: IKEv2, AES-256, SHA-256, DH Group 14
Remote proposal: IKEv2, AES-128, SHA-1, DH Group 2
# Configuração do Azure VPN Gateway (custom IPsec policy)
IkeEncryption: AES256
IkeIntegrity: SHA256
DhGroup: DHGroup14
IpsecEncryption: AES256
IpsecIntegrity: SHA256
PfsGroup: PFS14
O firewall on-premises foi atualizado para um novo firmware durante a manutenção. O fabricante do firewall confirmou que a versão anterior suportava os mesmos algoritmos configurados no Azure. A interface WAN do firewall está ativa e com conectividade à internet confirmada via ping para IPs externos.
Qual é a causa raiz da falha no túnel?
A) O status "Connected" no portal do Azure indica que o gateway Azure reiniciou durante a manutenção e perdeu a configuração da política IPsec customizada
B) O novo firmware do firewall on-premises não está aplicando a proposta IKE configurada anteriormente, enviando parâmetros incompatíveis com a política IPsec do Azure
C) A interface WAN do firewall apresenta problema de MTU após o firmware, causando fragmentação dos pacotes IKE e falha na negociação
D) O Azure VPN Gateway entrou em modo de failover e está rejeitando novas conexões até ser reiniciado manualmente
Cenário 2 — Decisão de Ação
A equipe de segurança identificou que o túnel point-to-site da organização utiliza o tipo SSTP como único protocolo configurado. A causa foi confirmada: a política de segurança corporativa foi atualizada para exigir que todos os clientes remotos, incluindo usuários de macOS e Linux, se autentiquem via Microsoft Entra ID sem uso de certificados individuais por dispositivo.
O ambiente atual é:
Gateway SKU: VpnGw2
Tunnel Type: SSTP
Authentication: Certificate (Root CA + Client Certificate)
Active P2S clients: 47 sessões ativas no momento
VPN Gateway: em uso por aplicações críticas de produção
A janela de manutenção programada é em 6 horas. Alterar o tipo de túnel exige reconfiguração do gateway e redistribuição do perfil VPN a todos os clientes.
Qual é a ação correta a tomar neste momento?
A) Adicionar OpenVPN como tipo de túnel adicional e configurar autenticação via Microsoft Entra ID imediatamente, sem aguardar a janela de manutenção, pois a adição de um novo protocolo não derruba as sessões SSTP existentes
B) Substituir o tipo de túnel de SSTP para IKEv2 imediatamente, pois IKEv2 suporta autenticação via Microsoft Entra ID e a mudança pode ser feita sem impacto nas sessões ativas
C) Aguardar a janela de manutenção, adicionar OpenVPN ao gateway, configurar autenticação via Microsoft Entra ID e planejar a distribuição do novo perfil VPN aos clientes
D) Desabilitar o SSTP imediatamente e reconfigurar o gateway para OpenVPN, notificando os 47 usuários ativos para reconectar após a mudança
Cenário 3 — Causa Raiz
Um administrador configurou uma nova conexão VNet-to-VNet entre duas VNets em regiões diferentes. Após a configuração, os recursos em ambas as VNets não conseguem se comunicar. O administrador verifica o portal e observa o seguinte:
Gateway A (East US):
Type: VPN
VPN Type: PolicyBased
SKU: Basic
Status: Connected
Gateway B (West Europe):
Type: VPN
VPN Type: RouteBased
SKU: VpnGw1
Status: Connected
O administrador confirma que os address spaces das duas VNets não se sobrepõem, que as connection objects foram criadas nos dois sentidos e que a shared key foi configurada de forma idêntica nos dois lados. O status de ambas as conexões aparece como Connected no portal.
O peering entre as VNets não foi configurado, pois a decisão arquitetural foi usar VPN Gateway. As NSGs aplicadas às subnets não bloqueiam o tráfego entre os ranges de IP das duas VNets.
Qual é a causa raiz da falha na comunicação?
A) O peering de VNet não foi configurado e, sem ele, a comunicação entre VNets em regiões diferentes via VPN Gateway não funciona mesmo com as connections criadas
B) Gateways do tipo PolicyBased suportam apenas uma conexão simultânea e não são compatíveis com conexões VNet-to-VNet, tornando a topologia inválida independentemente do status exibido
C) A shared key foi configurada de forma idêntica nos dois lados, o que é incorreto: cada lado deve ter uma chave diferente em conexões VNet-to-VNet
D) NSGs aplicadas nas subnets estão bloqueando o tráfego de retorno, pois regras de entrada permissivas sem regras de saída correspondentes causam falha assimétrica
Cenário 4 — Sequência de Diagnóstico
Um usuário remoto relata que seu cliente VPN point-to-site não consegue se conectar ao Azure VPN Gateway. O tipo de túnel configurado é IKEv2 e o cliente está em um notebook com Windows 11. O administrador precisa diagnosticar o problema.
Os seguintes passos de investigação estão disponíveis, fora de ordem:
[P] Verificar se o certificado raiz está carregado no Azure VPN Gateway
[Q] Verificar se o perfil VPN foi gerado e distribuído após a última
alteração de configuração do gateway
[R] Testar conectividade de rede do cliente para o endpoint público
do gateway na porta UDP 500
[S] Verificar se o certificado do cliente foi gerado a partir da
CA raiz correta e está instalado no store correto do Windows
[T] Revisar os logs do cliente VPN para identificar em qual fase
da negociacao IKE a falha ocorre
Qual é a sequência correta de investigação?
A) T, R, P, S, Q
B) R, T, P, S, Q
C) P, Q, S, R, T
D) R, P, Q, S, T
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista definitiva está no log de diagnóstico: a proposta IKE enviada pelo dispositivo on-premises usa AES-128, SHA-1 e DH Group 2, enquanto a política customizada do Azure exige AES-256, SHA-256 e DH Group 14. O erro "No proposal chosen" é o indicador clássico de incompatibilidade de proposta IKE Phase 1. O firmware atualizado não está aplicando a configuração anterior, enviando uma proposta padrão diferente da esperada.
A informação sobre a interface WAN estar ativa e com ping funcionando é irrelevante para este diagnóstico: o problema não é de conectividade de rede, mas de incompatibilidade de parâmetros criptográficos. Ela foi incluída para desviar o raciocínio para MTU ou roteamento.
O distrator mais perigoso é a alternativa A. O status "Connected" no portal do Azure pode confundir quem associa esse estado à configuração estar intacta. Na realidade, o portal pode manter o status anterior em cache por alguns minutos e o gateway Azure não reinicia nem perde configuração durante manutenções no lado on-premises.
Agir com base no distrator A levaria o administrador a reiniciar o gateway Azure sem necessidade, causando interrupção nas demais conexões do gateway.
Gabarito — Cenário 2
Resposta: C
A restrição crítica do cenário é a existência de 47 sessões ativas em ambiente de produção e uma janela de manutenção disponível em 6 horas. A ação correta é aguardar essa janela para adicionar o OpenVPN ao gateway e configurar autenticação via Microsoft Entra ID.
A alternativa A parece tecnicamente correta mas ignora uma restrição real: alterações no tipo de túnel ou na configuração de autenticação do gateway P2S exigem que os clientes baixem e reinstaleem o perfil VPN atualizado. A adição do OpenVPN, por si só, não derruba sessões SSTP existentes, mas o processo de redistribuição e a potencial instabilidade durante a mudança justificam usar a janela de manutenção.
A alternativa B está tecnicamente errada: IKEv2 não suporta autenticação via Microsoft Entra ID em conexões P2S. Esse é o equívoco conceitual mais comum neste tema.
A alternativa D representa a ação correta na essência, mas executada no momento errado, sem respeitar as restrições de produção. Derrubar 47 sessões ativas sem janela de manutenção é uma decisão operacionalmente incorreta.
Gabarito — Cenário 3
Resposta: B
Gateways do tipo PolicyBased têm restrições fundamentais: suportam apenas IKEv1, admitem uma única conexão simultânea e não são compatíveis com conexões VNet-to-VNet. Esse tipo de gateway foi projetado exclusivamente para conexões site-to-site legadas com dispositivos específicos. O status "Connected" exibido no portal não significa que o tráfego de dados está fluindo corretamente; ele reflete apenas o estado da negociação do túnel de controle.
A informação sobre os NSGs permitindo o tráfego, os address spaces não sobrepostos e a shared key idêntica são dados corretos e irrelevantes para a causa raiz: foram incluídos para desviar o diagnóstico para verificações de segurança e roteamento.
O distrator mais perigoso é a alternativa A. O peering de VNets não é necessário quando a comunicação ocorre via VPN Gateway: as duas abordagens são mutuamente exclusivas na arquitetura. Um administrador que escolhe A desperdiçará tempo configurando peering sem resolver o problema real, que é a incompatibilidade do tipo de gateway.
Gabarito — Cenário 4
Resposta: B
A sequência correta é R, P, Q, S, T, que segue a lógica de eliminação progressiva do externo para o interno:
- R — Verificar conectividade de rede primeiro. Se UDP 500 está bloqueado, nenhuma etapa posterior faz sentido.
- P — Confirmar que o certificado raiz está presente no gateway. Sem ele, nenhum cliente pode autenticar.
- Q — Verificar se o perfil VPN foi regenerado e distribuído após mudanças no gateway. Um perfil desatualizado causará falha mesmo com configuração correta.
- S — Validar o certificado do cliente: CA de origem correta e store correto no Windows.
- T — Somente após confirmar que infraestrutura, certificados e perfil estão corretos, analisar os logs para identificar em qual fase IKE a falha ocorre.
A alternativa A (T primeiro) representa o erro de pular direto para logs sem validar os pré-requisitos, o que frequentemente leva a diagnósticos inconclusivos porque a falha nos logs aponta para um sintoma, não para a causa raiz. A alternativa C (P primeiro antes de R) ignora que sem conectividade de rede, todas as demais verificações são inócuas.
Árvore de Troubleshooting: Select and Configure a Tunnel Type
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul médio | Pergunta diagnóstica (decisão) |
| 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 e responda cada pergunta com base no que você observou no ambiente. Siga o caminho que corresponde ao seu cenário: site-to-site, VNet-to-VNet ou point-to-site. A cada bifurcação, responda apenas com o que é verificável naquele momento, sem presumir causas. O caminho termina em um nó vermelho que nomeia a causa e em um nó verde que indica a ação. Se a causa identificada não resolve o problema após a ação corretiva, retorne ao nó de pergunta anterior e siga o caminho alternativo.