Qué cliente puede completar un inicio de sesión SAML en AWS Client VPN

Dos personas hacen la misma pregunta sobre AWS Client VPN y SAML, y obtienen respuestas opuestas. Una inicia sesión desde un portátil Ubuntu cada mañana; la otra tiene un teléfono, un perfil descargado y un cliente que rechaza una línea de ese perfil. La diferencia no es suerte ni un interruptor oculto en el panel. Todo se reduce a tres condiciones: si la plataforma es una de las que AWS admite para su propio cliente, si la herramienta que tiene en la mano puede realizar el intercambio federado en el navegador y si el extremo está configurado para SAML. Falle una de las tres y el inicio de sesión se detiene en un punto distinto.

Tres condiciones deciden si el inicio de sesión puede terminar

La plataforma va primero. AWS distribuye su propio cliente Client VPN para Windows, macOS y Ubuntu en AMD64, y a finales de octubre de 2026 la página de requisitos de Linux nombra Ubuntu 22.04, 24.04 y 26.04. Una compilación reempaquetada, un paquete convertido o una distribución distinta pueden funcionar, pero no es una plataforma admitida, y cuando se rompe, la línea de soporte es usted.

El cliente va segundo. El inicio de sesión federado no es una opción del perfil que analice cualquier aplicación compatible con OpenVPN. El cliente proporcionado abre su proveedor de identidad en un navegador, recibe la respuesta de autenticación firmada y envía esa respuesta al extremo. Una aplicación que solo lee el perfil y levanta un túnel no realiza este paso, por limpio que se vea su registro de conexión.

El extremo va tercero. Un extremo con credenciales de Active Directory o certificados mutuos tiene un planteamiento completamente distinto, y cambiar de cliente no lo modificará. Confirme el modo de autenticación con quien emitió el perfil antes de depurar cualquier otra cosa.

En conjunto, las tres condiciones dan una breve tabla de decisión:

Por qué una importación OpenVPN se detiene en auth-federate

Un perfil exportado de AWS Client VPN lleva una directiva que dice al cliente que la autenticación ocurre fuera del túnel, mediante federación. Un cliente OpenVPN genérico o rechaza la línea de plano o la ignora y entonces no tiene ninguna credencial que ofrecer. Aquí terminan la mayoría de los intentos en Android: el perfil se importa, la aplicación protesta o la conexión muere con un error de configuración antes de que salga un solo paquete del dispositivo.

Borrar auth-federate es el siguiente movimiento tentador, y convierte un fallo claro en uno confuso. Quitar una directiva no convierte un extremo SAML en autenticación con usuario y contraseña. El extremo sigue esperando una respuesta SAML firmada y rechaza lo que el cliente envía en su lugar. La contraseña de su cuenta, el perfil descargado y una aserción copiada no son credenciales intercambiables.

Iniciar sesión en el proveedor de identidad en Chrome en el teléfono solo demuestra que el proveedor de identidad aceptó al usuario. No dice nada sobre si la respuesta llega a un cliente que pueda devolverla al extremo. Los requisitos de autenticación federada hacen que el cliente proporcionado forme parte del flujo justamente por eso: el paso del navegador es necesario y no suficiente.

Cómo es la ruta admitida para el escritorio Linux

Instale el paquete que AWS publica para Ubuntu AMD64 con el gestor de paquetes del sistema y luego abra la conexión desde ese cliente en lugar de importar el perfil en una aplicación VPN genérica. Use el perfil que su administrador exportó para este extremo; no sustituya ninguna URL de retorno ni ningún identificador de cliente de una guía antigua, aunque el cliente lo acepte.

Inicie la conexión, complete el inicio de sesión y cualquier solicitud de MFA en el navegador que se abra, y deje que el flujo de retorno del navegador al cliente termine. Después solicite la dirección privada que realmente necesita, de nuevo. Una página que anuncia un inicio de sesión correcto no es prueba de que el túnel haya subido.

El cliente de Linux reserva los puertos TCP locales del 8096 al 8115 para las respuestas SAML. Cuando el traspaso se cuelga después de que el proveedor de identidad le haya aceptado, mire qué está escuchando ya en ese rango:

ss -ltnp | grep -E ":809[6-9]|:81(0[0-9]|1[0-5])"

Un puerto ocupado, o un software de seguridad del extremo que bloquea el oyente de bucle local, produce un inicio de sesión que parece completarse y luego nunca conecta. Mantenga ese rango local. Es una ruta de retorno del lado del cliente, no algo que se abra en un grupo de seguridad de EC2 o en una regla de cortafuegos de puerta de enlace, y abrirlo a internet añade exposición sin arreglar nada.

Lea la etapa que falla antes de cambiar nada

Culpar al cliente es el reflejo habitual, pero cada punto de fallo pertenece a un propietario distinto. Averigüe primero dónde está usted realmente.

• No se abre ninguna ventana del navegador. Revise el modo de autenticación del perfil, la conexión que eligió y la integración con el navegador predeterminado del escritorio.
• El proveedor de identidad rechaza la cuenta. Asignación de cuenta, inscripción en MFA o configuración de la aplicación SAML, todo territorio del administrador.
• El navegador termina pero el cliente nunca conecta. Una respuesta de autenticación caducada o inservible, un puerto de retorno bloqueado o un traspaso fallido.
• El túnel está levantado pero la aplicación es inalcanzable. Rutas del extremo, reglas de autorización, grupos de seguridad, DNS. Repetir el inicio de sesión en el navegador no puede añadir un permiso de red que falta.

Guarde el texto del error del cliente y la hora del intento cuando escale. La afirmación de que SAML está roto y la afirmación de que el cliente nunca recibió una respuesta de autenticación válida llevan a la gente a lugares completamente distintos.

Cuando el requisito es Android de todos modos

Android no es una plataforma para la que AWS publique su cliente, así que la respuesta honesta es que no hay ningún cliente móvil admitido que instalar. Es una limitación de diseño, no un rompecabezas que resolver en el teléfono editando el perfil hasta que algo conecte.

Lo que puede cambiar es el diseño de acceso que hay detrás, y esa decisión pertenece al administrador: una ruta de acceso a aplicaciones aprobada hacia el único servicio interno que el teléfono necesita, un producto VPN con soporte móvil que la organización ya opere, o un escritorio admitido para el extremo que solo usa SAML. Cada opción trae su propia configuración de extremo, inscripción de identidad y reglas de autorización, y el usuario no puede crear nada de eso a partir de un perfil descargado.

Las herramientas de terceros que afirman cerrar esa brecha necesitan una revisión explícita de soporte y seguridad que cubra MFA, gestión de respuestas, política de dispositivos y ritmo de actualizaciones. Su existencia no las convierte en un cliente Android proporcionado por AWS, y no debería mover material de autenticación reutilizable a un teléfono para hacer funcionar una de ellas.

Dé al administrador tres hechos en lugar de un hilo largo sobre directivas: el modo de autenticación del extremo, el recurso privado que el teléfono debe alcanzar y la fecha límite. Con eso basta para elegir entre un escritorio, una ruta de acceso a aplicaciones y un producto VPN nuevo.

Compruebe las condiciones en orden antes de abrir otro ticket: plataforma en la lista de clientes proporcionados, una herramienta que pueda completar el intercambio en el navegador, un extremo realmente configurado para federación y, en Linux, el rango de puertos de bucle local. El primer elemento que falla es el que hay que arreglar. Todo lo demás es conjetura.