Autenticación de cliente P2S de Azure: Entra, certificado o RADIUS

El instalador se ejecuta, el perfil se importa y la conexión falla en el paso de inicio de sesión. La mayoría de estos casos no son un error del cliente: una aplicación compatible con OpenVPN puede transportar el túnel y, aun así, no saber cómo realizar un inicio de sesión de Microsoft Entra. El orden que evita el bucle es método, luego cliente y luego perfil. Elija el método de autenticación para el que está configurada la puerta de enlace, elija un cliente que Microsoft documente para ese método y solo entonces genere el perfil que ese cliente espera. Todo lo que sigue respeta ese orden.

Empiece por el método, no por el instalador

La puerta de enlace está configurada con uno o varios tipos de túnel y métodos de autenticación. Ese par, y no la extensión del archivo que tiene en el escritorio, decide qué clientes son compatibles.

Anote el par antes de descargar nada, porque la matriz de compatibilidad es estrecha y un mal comienzo cuesta una tarde.

Esta es la asignación que guardo en las notas de despliegue:

Lea esa tabla como una restricción, no como un menú. Cada fila es una combinación documentada, y mezclar un cliente de una fila con el método de otra es exactamente el fallo que este artículo existe para evitar.

Entra ID significa OpenVPN más Azure VPN Client

Para la autenticación Entra en punto a sitio, la disposición compatible usa el tipo de túnel OpenVPN y el Azure VPN Client. Un diálogo genérico de usuario y contraseña no sustituye esa integración, y el IKEv2 nativo de Windows no es una forma intercambiable de realizar el mismo inicio de sesión. Si un cliente de terceros ofrece una opción Entra o Azure AD, verifíquela con la documentación actual de Microsoft y no con la etiqueta. La etiqueta es marketing, mientras que la combinación documentada es el contrato.

En macOS, el Azure VPN Client también es la ruta documentada para este método.

Los certificados necesitan una credencial de cliente, no solo una raíz

La autenticación con certificados es un modelo compatible aparte, y funciona con los clientes OpenVPN que Microsoft documenta y con el Azure VPN Client en las plataformas compatibles. En Windows, el Azure VPN Client no es solo para Entra: también tiene un flujo de certificados documentado. Lo que necesita es el certificado de cliente previsto con una clave privada utilizable, en la que confíe la puerta de enlace. La raíz de confianza de la puerta de enlace no es una credencial de cliente, y la clave de firma del emisor nunca pertenece a un paquete de cliente.

Compruebe la cadena antes de depurar el perfil. Un certificado emitido por una raíz en la que la puerta de enlace no confía produce un fallo que parece un perfil defectuoso y en realidad es un problema de confianza.

Mantenga la clave privada no exportable donde la plataforma lo permita, y pruebe con el certificado realmente instalado para el usuario actual.

RADIUS es una elección de backend con sus propias combinaciones

RADIUS traslada la decisión sobre las credenciales a un servidor que usted ejecuta, y está documentado con tipos de túnel y clientes concretos. No es automáticamente la respuesta correcta solo porque el entorno tenga varios sistemas operativos. Determine qué puede presentar el cliente real antes de cambiar la política de autenticación de la puerta de enlace, porque pasar la puerta de enlace a RADIUS no adapta todos los perfiles existentes. El cliente todavía tiene que poder solicitar o proporcionar esas credenciales.

Si el motivo es un entorno mixto, resuélvalo por plataforma en lugar de debilitar la política de la puerta de enlace para todos.

Linux tras la retirada de la versión preliminar en 2026

La guía de Microsoft sobre la retirada de Linux fija el 31 de agosto de 2026 como fecha de retirada de la versión preliminar de Azure VPN Client para Linux, así que en noviembre de 2026 esa versión preliminar ya ha quedado atrás. Las instalaciones existentes pueden seguir funcionando, pero ya no reciben soporte, actualizaciones ni correcciones de seguridad. No entregue un instalador antiguo de Linux como despliegue nuevo compatible. Es la retirada de un cliente, no la de Azure VPN Gateway ni la de los clientes de Windows y macOS.

Las alternativas documentadas para Linux son un cliente OpenVPN con autenticación por certificado, o strongSwan con IKEv2 y autenticación por certificado o RADIUS. Ambas son configuraciones distintas que necesitan aprobación organizativa, no una conversión que se obtiene renombrando el perfil Entra antiguo.

Si el inicio de sesión con Entra es obligatorio por motivos de política, el propietario debe elegir una plataforma compatible o un diseño alternativo aprobado. Eso es una decisión, no un rodeo.

Genere el perfil y realice cuatro comprobaciones

Genere la configuración del cliente desde la puerta de enlace prevista una vez fijada la combinación, e importe la representación documentada para ese cliente y método. La carpeta genérica de OpenVPN y el perfil XML de Azure VPN Client no son intercambiables. Si la puerta de enlace habilita deliberadamente varios tipos de autenticación, elija el perfil y la ruta de credenciales correspondientes en lugar de esperar que una sola conexión los satisfaga todos. Después realice las comprobaciones en este orden:

• El cliente compatible importa el perfil generado sin editarlo.
• La identidad prevista se autentica con el método que ese perfil espera.
• La política de rutas y de resolución requerida aparece en el cliente.
• La aplicación permitida llega a su recurso privado.

Una importación correcta no demuestra ni la compatibilidad de autenticación ni la autorización del recurso privado, por eso esas cuatro comprobaciones siguen separadas.