Laboratório de Troubleshooting: Specify Azure Requirements for Always On VPN
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma organização implantou o Always On VPN com User Tunnel para cerca de 200 colaboradores remotos. O gateway VPN no Azure utiliza o SKU VpnGw2 e está configurado para autenticação via Microsoft Entra ID com protocolo OpenVPN. Os perfis VPN foram distribuídos via Intune há três semanas e funcionaram corretamente até ontem.
Hoje, aproximadamente 40% dos usuários relatam que o User Tunnel não é estabelecido automaticamente após o logon. Os demais 60% não reportam nenhum problema. A equipe de rede verificou que não houve alterações no gateway VPN nem nos perfis distribuídos pelo Intune. O time de segurança informa que uma política de Microsoft Entra Conditional Access foi atualizada na última noite para exigir dispositivos em conformidade (compliant) para acesso a todos os aplicativos corporativos, incluindo o aplicativo do Azure VPN registrado no Entra ID.
Os usuários afetados relatam o seguinte comportamento ao tentar conectar manualmente:
Connecting to VPN...
Authentication failed. Error: 0x80070522
The VPN connection requires device compliance. Contact your administrator.
O administrador de rede verifica os logs do gateway e não encontra tentativas de conexão rejeitadas do lado do Azure. A equipe de helpdesk informa que todos os dispositivos afetados são modelos recém-adquiridos, ainda em processo de enrollment completo no Intune.
Qual é a causa raiz do problema observado?
A) O SKU VpnGw2 atingiu o limite de conexões P2S simultâneas, causando rejeição intermitente de novas conexões.
B) Os dispositivos afetados não satisfazem a condição de conformidade exigida pela política de Microsoft Entra Conditional Access atualizada, impedindo a autenticação do User Tunnel.
C) O protocolo OpenVPN está com falha no gateway após a atualização da política de Conditional Access, afetando apenas parte dos usuários de forma aleatória.
D) Os perfis VPN distribuídos pelo Intune expiraram após três semanas de uso, exigindo redistribuição para os dispositivos afetados.
Cenário 2 — Decisão de Ação
A equipe de infraestrutura identificou que o Device Tunnel do Always On VPN parou de funcionar em um grupo de dispositivos após uma migração de CA interna. A causa foi confirmada: o certificado raiz da nova CA não foi adicionado como certificado raiz confiável no gateway VPN do Azure. Os dispositivos afetados continuam com o certificado de máquina emitido pela nova CA, mas o gateway rejeita a autenticação.
O ambiente possui as seguintes restrições:
- São 08h30 de uma segunda-feira e o ambiente de produção está em pleno uso
- O Device Tunnel afetado é o único canal pelo qual os controladores de domínio são alcançados para processar Group Policies dos dispositivos remotos
- A equipe de PKI possui o certificado raiz da nova CA em formato
.cerpronto para uso - Recriar o gateway VPN levaria aproximadamente 45 minutos de indisponibilidade total
- Adicionar um certificado raiz confiável ao gateway VPN não exige recriação e não causa interrupção de conexões ativas
Qual é a ação correta a tomar neste momento?
A) Recriar o gateway VPN do Azure com a configuração atualizada incluindo o certificado raiz da nova CA, aceitando os 45 minutos de indisponibilidade.
B) Revogar os certificados emitidos pela nova CA e reemitir todos os certificados de máquina pela CA anterior até que uma janela de manutenção seja agendada.
C) Adicionar o certificado raiz da nova CA como certificado raiz confiável no gateway VPN do Azure imediatamente, sem interrupção das conexões ativas.
D) Aguardar uma janela de manutenção noturna para aplicar qualquer alteração no gateway VPN, pois modificações em produção durante o dia são contraindicadas.
Cenário 3 — Causa Raiz
Um administrador está implantando o Always On VPN pela primeira vez em uma filial com 30 dispositivos Windows 11 ingressados em domínio Active Directory local. A configuração prevê Device Tunnel e User Tunnel. O gateway VPN no Azure utiliza IKEv2 para o Device Tunnel e OpenVPN para o User Tunnel.
Após a distribuição dos perfis via Intune, o User Tunnel funciona corretamente em todos os dispositivos. O Device Tunnel, no entanto, não é estabelecido em nenhum deles. O administrador executa o seguinte comando em um dos dispositivos afetados:
Get-VpnConnection -AllUserConnection
Name : CorpDeviceTunnel
ServerAddress : vpngw-corp.vpn.azure.com
TunnelType : Ikev2
AuthenticationMethod : MachineCertificate
ConnectionStatus : Disconnected
Em seguida, verifica o repositório de certificados:
Get-ChildItem -Path Cert:\LocalMachine\My | Select-Object Subject, EnhancedKeyUsageList
Subject EnhancedKeyUsageList
------- --------------------
CN=DESKTOP-A1B2C3 {Client Authentication}
O administrador também confirma que o perfil do Device Tunnel foi criado como uma conexão de todos os usuários (All User Connection) e que o serviço VPN está em execução. O help desk informa que os dispositivos estão com Windows 11 versão 22H2 e que o antivírus foi atualizado na semana anterior.
Qual é a causa raiz da falha no Device Tunnel?
A) O antivírus atualizado recentemente está bloqueando a comunicação IKEv2 na porta UDP 500, impedindo a negociação do túnel.
B) O perfil do Device Tunnel foi criado como All User Connection, configuração incorreta que impede seu funcionamento; ele deve ser criado como conexão de usuário individual.
C) O certificado de máquina no repositório LocalMachine\My possui o EKU de Client Authentication, mas o Device Tunnel exige que o certificado esteja no repositório LocalMachine\My com o EKU específico de Server Authentication adicionalmente configurado no lado do gateway.
D) O Device Tunnel requer que a conta que executa o serviço VPN possua privilégios de sistema local (SYSTEM), e o perfil como All User Connection é a configuração correta; a causa é que o certificado de máquina não possui o atributo de Subject Alternative Name (SAN) correspondendo ao nome DNS do dispositivo.
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe o relato de que o Always On VPN de um usuário específico não reconecta automaticamente após o dispositivo sair do modo de hibernação. O User Tunnel aparece como desconectado e não tenta reconexão. O Device Tunnel permanece ativo.
Os passos abaixo representam ações de diagnóstico válidas, mas estão fora de ordem:
- Verificar os logs do cliente VPN em
%ProgramData%\Microsoft\VpnClient\Logspara identificar o código de erro retornado na tentativa de reconexão - Confirmar se o perfil do User Tunnel possui a propriedade
AlwaysOndefinida comotrueno XML do perfil distribuído pelo Intune - Verificar se há uma política de Microsoft Entra Conditional Access que exige reauthenticação periódica e se o token do usuário expirou durante a hibernação
- Testar a conectividade manual do User Tunnel para confirmar se o problema é na reconexão automática ou na autenticação em si
- Confirmar que o serviço
RasMan(Remote Access Connection Manager) reiniciou corretamente após a saída da hibernação e está em estado Running
Qual é a sequência correta de investigação?
A) 2 -> 5 -> 1 -> 4 -> 3
B) 1 -> 3 -> 2 -> 5 -> 4
C) 5 -> 1 -> 2 -> 4 -> 3
D) 4 -> 1 -> 5 -> 2 -> 3
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva no enunciado é a combinação de dois fatos: a política de Microsoft Entra Conditional Access foi atualizada para exigir conformidade de dispositivos, e os dispositivos afetados são modelos recém-adquiridos ainda em processo de enrollment incompleto no Intune. Dispositivos sem enrollment completo não possuem estado de conformidade verificável pelo Entra ID, portanto falham na condição de Conditional Access e não conseguem completar a autenticação do User Tunnel via OpenVPN.
A mensagem de erro confirma o diagnóstico: The VPN connection requires device compliance. O fato de o gateway não registrar tentativas rejeitadas reforça que a rejeição ocorre antes de chegar ao gateway, na camada de autenticação do Entra ID.
A informação irrelevante no enunciado é o tempo de funcionamento de três semanas dos perfis Intune. Ela induz o leitor a buscar uma causa relacionada à expiração ou alteração de perfil, mas nenhum perfil Intune expira por tempo de uso.
A alternativa A é um distrator plausível, mas o SKU VpnGw2 suporta centenas de conexões simultâneas e a falha é consistente em um grupo específico de dispositivos, não aleatória. A alternativa C é incorreta porque a Conditional Access opera na camada de identidade, não na camada de protocolo do gateway. A alternativa D descreve um comportamento que não existe na plataforma.
O distrator mais perigoso é o A: um administrador que parte para verificar a capacidade do gateway perderá tempo considerável antes de identificar que o problema é de conformidade de dispositivo.
Gabarito — Cenário 2
Resposta: C
A causa foi identificada e declarada no enunciado: o certificado raiz da nova CA não está presente como confiável no gateway VPN. A solução correta é adicionar esse certificado ao gateway imediatamente, pois o próprio enunciado informa que essa operação não causa interrupção de conexões ativas e não exige recriação do gateway.
As restrições do cenário eliminam as demais alternativas:
A alternativa A propõe recriar o gateway, causando 45 minutos de indisponibilidade total em horário de produção. A operação correta não exige isso, portanto a alternativa A representa escolher uma ação de impacto máximo quando existe uma alternativa sem impacto.
A alternativa B propõe revogar os certificados da nova CA e reemitir pela CA anterior. Além de complexa e demorada, essa ação gera um problema de PKI maior e não resolve a causa raiz de forma adequada.
A alternativa D aplica uma restrição inexistente. Adicionar um certificado raiz confiável ao gateway é uma operação não disruptiva que pode e deve ser realizada imediatamente quando a causa está confirmada e o recurso está disponível.
O risco real de escolher D é manter o Device Tunnel inativo durante toda a jornada de trabalho, impedindo que os dispositivos remotos alcancem controladores de domínio e processem Group Policies, com impacto cumulativo crescente ao longo do dia.
Gabarito — Cenário 3
Resposta: D
O enunciado contém uma informação irrelevante propositalmente incluída: a atualização do antivírus na semana anterior. O Device Tunnel falha em todos os 30 dispositivos de forma uniforme, o que descarta uma causa localizada como bloqueio de antivírus, que raramente afetaria 100% dos dispositivos de forma idêntica.
A pista decisiva está nos dados coletados: o certificado de máquina existe no repositório correto (LocalMachine\My), possui o EKU de Client Authentication, e o perfil está corretamente configurado como All User Connection. O que o output do Get-ChildItem não mostra é a presença do Subject Alternative Name (SAN) no certificado. O Device Tunnel via IKEv2 exige que o certificado de máquina contenha um SAN que corresponda ao nome do computador, pois é por esse atributo que o gateway valida a identidade da máquina durante a negociação IKEv2.
A alternativa A (antivírus) é o distrator baseado na informação irrelevante. A alternativa B está errada porque All User Connection é exatamente o requisito correto para o Device Tunnel. A alternativa C é tecnicamente incorreta porque o Device Tunnel não requer Server Authentication EKU no certificado de máquina do cliente; esse EKU é necessário no certificado do servidor VPN.
O distrator mais perigoso é o A, pois induz o administrador a investigar e potencialmente desabilitar o antivírus em produção sem fundamento, criando um risco de segurança desnecessário.
Gabarito — Cenário 4
Resposta: A
A sequência correta é: 2 -> 5 -> 1 -> 4 -> 3
O raciocínio diagnóstico correto parte do mais simples e verificável para o mais complexo:
O passo 2 vem primeiro porque verifica se o perfil está corretamente configurado com AlwaysOn = true. Se essa propriedade estiver ausente ou falsa, nenhuma reconexão automática ocorrerá, e os demais passos se tornam desnecessários.
O passo 5 vem em seguida porque o serviço RasMan é a dependência de sistema que gerencia as conexões VPN. Se ele não reiniciou corretamente após a hibernação, o túnel não tentará reconectar independentemente da configuração do perfil.
O passo 1 segue porque, com as condições de base confirmadas, os logs fornecerão o código de erro exato, estreitando as hipóteses restantes.
O passo 4 vem após os logs porque confirma empiricamente se o problema é de reconexão automática ou de autenticação, informação necessária para decidir se a investigação vai para o perfil ou para a camada de identidade.
O passo 3 é o último porque exige correlacionar o comportamento com políticas do Entra ID, uma verificação mais trabalhosa que só faz sentido após eliminar as causas mais locais e verificáveis.
A alternativa B inverte a ordem e começa pelos logs antes de verificar as condições básicas, o que é ineficiente. A alternativa C começa pelo serviço, pulando a verificação mais rápida e fundamental do perfil. A alternativa D começa pelo teste manual, que consome mais tempo e não fornece informação diagnóstica sem o contexto dos passos anteriores.
Árvore de Troubleshooting: Specify Azure Requirements for Always On VPN
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 e responda cada pergunta de diagnóstico com base no que é verificável no ambiente. Perguntas sobre certificados devem ser validadas no repositório do dispositivo com PowerShell antes de qualquer ação. Perguntas sobre conformidade devem ser validadas no portal Intune. Perguntas sobre o gateway devem ser verificadas diretamente no portal do Azure. Siga o caminho até um nó de causa identificada antes de executar qualquer ação corretiva, evitando intervenções baseadas em suposição.