Autenticación de cliente P2S de Azure: Entra, certificado ou RADIUS
O inicio de sesión con Entra, os certificados de cliente e RADIUS requiren clientes e perfís de Azure VPN distintos. Escolla o método, logo o cliente e por último o perfil.
O instalador execútase, o perfil impórtase e a conexión falla no paso de inicio de sesión. A maioría destes casos non son un erro do cliente: unha aplicación compatible con OpenVPN pode transportar o túnel e, aínda así, non saber como realizar un inicio de sesión de Microsoft Entra. A orde que evita o bucle é método, logo cliente e logo perfil. Escolla o método de autenticación para o que está configurada a pasarela, escolla un cliente que Microsoft documente para ese método e só entón xere o perfil que ese cliente espera. Todo o que segue respecta esa orde.
Empece polo método, non polo instalador
A pasarela está configurada cun ou varios tipos de túnel e métodos de autenticación. Ese par, e non a extensión do ficheiro que ten no escritorio, decide que clientes son compatibles.
Anote o par antes de descargar nada, porque a matriz de compatibilidade é estreita e un mal comezo custa unha tarde.
Esta é a asignación que gardo nas notas de despregamento:
| Authentication | Tunnel type | Documented client |
|---|---|---|
| Microsoft Entra ID | OpenVPN | Azure VPN Client on Windows and macOS |
| Client certificate | OpenVPN or IKEv2 | Azure VPN Client, documented OpenVPN client, native IKEv2 client, strongSwan on Linux |
| RADIUS | IKEv2 or OpenVPN, per the current matrix | Native IKEv2 client, strongSwan, or the OpenVPN client the matrix names |
Lea esa táboa como unha restrición, non como un menú. Cada fila é unha combinación documentada, e mesturar un cliente dunha fila co método doutra é exactamente o fallo que este artigo existe para evitar.
Entra ID significa OpenVPN máis Azure VPN Client
Para a autenticación Entra en punto a sitio, a disposición compatible usa o tipo de túnel OpenVPN e o Azure VPN Client. Un diálogo xenérico de usuario e contrasinal non substitúe esa integración, e o IKEv2 nativo de Windows non é unha forma intercambiable de realizar o mesmo inicio de sesión. Se un cliente de terceiros ofrece unha opción Entra ou Azure AD, verifíquea coa documentación actual de Microsoft e non coa etiqueta. A etiqueta é mercadotecnia, mentres que a combinación documentada é o contrato.
En macOS, o Azure VPN Client tamén é a ruta documentada para este método.
Os certificados necesitan unha credencial de cliente, non só unha raíz
A autenticación con certificados é un modelo compatible aparte, e funciona cos clientes OpenVPN que Microsoft documenta e co Azure VPN Client nas plataformas compatibles. En Windows, o Azure VPN Client non é só para Entra: tamén ten un fluxo de certificados documentado. O que necesita é o certificado de cliente previsto cunha clave privada utilizábel, na que confíe a pasarela. A raíz de confianza da pasarela non é unha credencial de cliente, e a clave de sinatura do emisor nunca pertence a un paquete de cliente.
Comprobe a cadea antes de depurar o perfil. Un certificado emitido por unha raíz na que a pasarela non confía produce un fallo que parece un perfil defectuoso e en realidade é un problema de confianza.
Manteña a clave privada non exportábel onde a plataforma o permita, e probe co certificado realmente instalado para o usuario actual.
RADIUS é unha elección de backend coas súas propias combinacións
RADIUS traslada a decisión sobre as credenciais a un servidor que vostede executa, e está documentado con tipos de túnel e clientes concretos. Non é automaticamente a resposta correcta só porque a contorna teña varios sistemas operativos. Determine que pode presentar o cliente real antes de cambiar a política de autenticación da pasarela, porque pasar a pasarela a RADIUS non adapta todos os perfís existentes. O cliente aínda ten que poder solicitar ou proporcionar esas credenciais.
Se o motivo é unha contorna mixta, resólvao por plataforma en lugar de debilitar a política da pasarela para todos.
Linux tras a retirada da versión preliminar en 2026
A guía de Microsoft sobre a retirada de Linux fixa o 31 de agosto de 2026 como data de retirada da versión preliminar de Azure VPN Client para Linux, así que en novembro de 2026 esa versión preliminar xa quedou atrás. As instalacións existentes poden seguir funcionando, pero xa non reciben soporte, actualizacións nin correccións de seguridade. Non entregue un instalador antigo de Linux como despregamento novo compatible. É a retirada dun cliente, non a de Azure VPN Gateway nin a dos clientes de Windows e macOS.
As alternativas documentadas para Linux son un cliente OpenVPN con autenticación por certificado, ou strongSwan con IKEv2 e autenticación por certificado ou RADIUS. Ambas son configuracións distintas que necesitan aprobación organizativa, non unha conversión que se obtén renomeando o perfil Entra antigo.
Se o inicio de sesión con Entra é obrigatorio por motivos de política, o propietario debe escoller unha plataforma compatible ou un deseño alternativo aprobado. Iso é unha decisión, non un rodeo.
Xere o perfil e realice catro comprobacións
Xere a configuración do cliente desde a pasarela prevista unha vez fixada a combinación, e importe a representación documentada para ese cliente e método. O cartafol xenérico de OpenVPN e o perfil XML de Azure VPN Client non son intercambiables. Se a pasarela habilita deliberadamente varios tipos de autenticación, escolla o perfil e a ruta de credenciais correspondentes en lugar de esperar que unha soa conexión os satisfaga todos. Despois realice as comprobacións nesta orde:
- O cliente compatible importa o perfil xerado sen editalo.
- A identidade prevista autentícase co método que ese perfil espera.
- A política de rutas e de resolución requirida aparece no cliente.
- A aplicación permitida chega ao seu recurso privado.
Unha importación correcta non demostra nin a compatibilidade de autenticación nin a autorización do recurso privado, por iso esas catro comprobacións seguen separadas.