Autenticação de cliente P2S do Azure: Entra, certificado ou RADIUS

O instalador é executado, o perfil é importado e a ligação falha no passo de início de sessão. A maioria destes pedidos não é um erro do cliente: uma aplicação compatível com OpenVPN pode transportar o túnel e, mesmo assim, não saber como efetuar um início de sessão Microsoft Entra. A ordem que evita o ciclo é método, depois cliente, depois perfil. Escolha o método de autenticação para o qual o gateway está configurado, escolha um cliente que a Microsoft documente para esse método e só então gere o perfil que esse cliente espera. Tudo o que se segue respeita essa ordem.

Comece pelo método, não pelo instalador

O gateway está configurado com um ou mais tipos de túnel e métodos de autenticação. É esse par, e não a extensão do ficheiro no ambiente de trabalho, que decide quais clientes são suportados.

Anote o par antes de transferir seja o que for, porque a matriz de suporte é estreita e um início errado custa uma tarde.

Esta é a correspondência que guardo nas notas de implementação:

Leia essa tabela como uma restrição, não como um menu. Cada linha é uma combinação documentada, e misturar um cliente de uma linha com o método de outra é exatamente a falha que este artigo existe para evitar.

Entra ID significa OpenVPN mais Azure VPN Client

Para a autenticação Entra em ponto a site, a disposição suportada usa o tipo de túnel OpenVPN e o Azure VPN Client. Uma caixa de diálogo genérica de nome de utilizador e palavra-passe não substitui essa integração, e o IKEv2 nativo do Windows não é uma forma permutável de efetuar o mesmo início de sessão. Se um cliente de terceiros oferecer uma opção Entra ou Azure AD, verifique-a na documentação atual da Microsoft e não no rótulo. O rótulo é marketing, enquanto a combinação documentada é o contrato.

No macOS, o Azure VPN Client também é o caminho documentado para este método.

Os certificados exigem uma credencial de cliente, não apenas uma raiz

A autenticação por certificado é um modelo suportado à parte, e funciona com os clientes OpenVPN que a Microsoft documenta e com o Azure VPN Client nas plataformas suportadas. No Windows, o Azure VPN Client não é só para Entra: também tem um fluxo de certificados documentado. O que precisa é do certificado de cliente pretendido com uma chave privada utilizável, em que o gateway confie. A raiz de confiança do gateway não é uma credencial de cliente, e a chave de assinatura do emissor nunca pertence a um pacote de cliente.

Verifique a cadeia antes de depurar o perfil. Um certificado emitido por uma raiz em que o gateway não confia produz uma falha que parece um perfil defeituoso e na realidade é um problema de confiança.

Mantenha a chave privada não exportável onde a plataforma o permitir, e teste com o certificado realmente instalado para o utilizador atual.

RADIUS é uma escolha de backend com as suas próprias combinações

O RADIUS transfere a decisão sobre as credenciais para um servidor que você opera, e está documentado com tipos de túnel e clientes específicos. Não é automaticamente a resposta certa só porque o ambiente tem vários sistemas operativos. Determine o que o cliente real consegue apresentar antes de alterar a política de autenticação do gateway, porque mudar o gateway para RADIUS não adapta todos os perfis existentes. O cliente continua a ter de conseguir pedir ou fornecer essas credenciais.

Se o motivo for um ambiente misto, resolva-o por plataforma em vez de enfraquecer a política do gateway para todos.

Linux após a retirada da pré-visualização em 2026

As orientações da Microsoft sobre a retirada do Linux indicam 31 de agosto de 2026 como data de retirada da pré-visualização do Azure VPN Client para Linux, pelo que em novembro de 2026 essa pré-visualização já ficou para trás. As instalações existentes podem continuar a funcionar, mas já não recebem suporte, atualizações ou correções de segurança. Não distribua um instalador Linux antigo como implementação nova suportada. É a retirada de um cliente, não do Azure VPN Gateway nem dos clientes Windows e macOS.

As alternativas Linux documentadas são um cliente OpenVPN com autenticação por certificado, ou strongSwan com IKEv2 e autenticação por certificado ou RADIUS. Ambas são configurações diferentes que exigem aprovação organizacional, não uma conversão obtida ao renomear o perfil Entra antigo.

Se o início de sessão Entra for obrigatório por razões de política, o proprietário tem de escolher uma plataforma suportada ou um desenho alternativo aprovado. Isso é uma decisão, não um contorno.

Gere o perfil e efetue quatro verificações

Gere a configuração do cliente a partir do gateway pretendido depois de definida a combinação, e importe a representação documentada para esse cliente e método. A pasta OpenVPN genérica e o perfil XML do Azure VPN Client não são intermutáveis. Se o gateway ativar deliberadamente vários tipos de autenticação, escolha o perfil e o caminho de credenciais correspondentes em vez de esperar que uma única ligação satisfaça todos. Depois efetue as verificações nesta ordem:

• O cliente suportado importa o perfil gerado sem o editar.
• A identidade pretendida autentica-se com o método que esse perfil espera.
• A política de rotas e de resolução necessária aparece no cliente.
• A aplicação permitida alcança o seu recurso privado.

Uma importação bem-sucedida não prova nem a compatibilidade da autenticação nem a autorização do recurso privado, por isso essas quatro verificações mantêm-se separadas.