Por qué editar un archivo .ovpn no puede activar MFA en el servidor

Añades auth-user-pass a un perfil, vuelves a conectarte y el cliente pide un nombre de usuario y una contraseña. Parece que MFA está activado. Luego escribes un código de la cuenta equivocada, o un código que caducó hace diez minutos, y el túnel sigue levantándose. Ese es el síntoma: el cliente cambió, el servidor no. Una contraseña de un solo uso solo es un factor cuando un verificador en el servidor decide si es válida para la identidad que la reclama.

La solicitud solo demuestra que el cliente preguntó, nada más

Un archivo .ovpn es un documento del lado del cliente. Puede decirle al cliente que solicite credenciales, que las guarde en caché o que deje de hacerlo. No puede registrar a un usuario, instalar un módulo PAM ni hacer que el servidor exija un segundo factor que ahora no comprueba.

Instalar una aplicación de autenticación en un teléfono tampoco crea esa relación. El proyecto Google Authenticator PAM es un componente de verificación de OTP que puede situarse detrás de OpenVPN; no es una forma de pegar el inicio de sesión de la cuenta de Google a un perfil importado.

El registro es la parte que un perfil no puede hacer

TOTP necesita material de registro compartido entre la aplicación de autenticación y su verificador. Los seis dígitos del teléfono son la salida; la semilla que hay detrás es el secreto, y pertenece a una sola identidad.

Por eso el operador necesita un proceso de registro que vincule la semilla correcta a la identidad VPN correcta, además de una ruta de sustitución verificada para un teléfono perdido. Dejar que los usuarios suban un archivo con su propio nombre convierte el registro en una oportunidad de apropiación de cuenta, y cifrar la subida no lo cambia.

Un diseño basado en PAM no tiene que crear una cuenta Unix separada por cada usuario VPN. La documentación del módulo admite rutas alternativas para los secretos y una cuenta dedicada para el acceso a archivos, que es una identidad del sistema de archivos y no la identidad de inicio de sesión que se verifica.

El error habitual es una ruta de secreto fija que termina en un solo nombre de usuario, copiada de un ejemplo para un solo usuario. Eso es una demostración de una identidad, no una búsqueda por usuario, y usarla para cada solicitud no le da a nadie una aplicación de autenticación registrada de forma independiente. Escribe el mapeo de identidades, protege los archivos de semillas y mantén las comprobaciones de contraseña, certificado y cuenta en la misma pila de autenticación.

Lee la pila PAM para ver qué se exige realmente

Una línea como account required pam_permit.so no implementa la elegibilidad de la cuenta ni añade un factor. Permite esa etapa de gestión de cuentas de PAM, que es una afirmación sobre una etapa y no sobre tus usuarios.

Lo mismo se aplica a las opciones de registro permisivas. Aceptar usuarios sin ningún secreto registrado puede ser una decisión deliberada de despliegue, pero no es prueba de que MFA sea obligatorio, y debería anotarse como una excepción temporal con fecha de fin.

Ajusta la interacción del cliente al diseño del servidor

auth-user-pass

Esa directiva pide introducir nombre de usuario y contraseña. No configura PAM, no crea un registro de inscripción ni le dice al servidor que el campo de contraseña contiene un valor TOTP. La integración del servidor y el cliente tienen que acordar una interacción que el despliegue realmente admita: un desafío, un formato de credenciales combinado y documentado, o un flujo específico del producto.

No añadas un código a la contraseña solo porque el cliente muestre un único campo. Eso funciona únicamente donde el complemento del servidor espera exactamente ese formato, y falla de forma confusa en todos los demás sitios.

Mantén las semillas y el material QR fuera de los perfiles compartidos y de los registros de diagnóstico rutinarios. Un código enviado por el canal de inicio de sesión autenticado no es el mismo objeto que la semilla entregada durante un registro controlado, y mezclarlos en un ticket de soporte es la forma en que se escapan los secretos.

Reconexiones, tokens y la prueba que lo resuelve

Planifica qué ocurre después del primer inicio de sesión correcto. Un código aceptado antes puede haber caducado o ser rechazado como repetición en la siguiente autenticación. auth-nocache controla la retención de credenciales y no instala MFA, y reneg-sec 0 no es una definición de compatibilidad con TOTP, por mucho que aparezca en hilos de foro.

Algunos despliegues emiten tokens de autenticación tras la comprobación inicial para que las reconexiones no vuelvan a preguntar. Es una decisión de diseño con su propia ventana de validez y su propia historia de revocación, no un valor predeterminado que heredas.

Luego prueba la política de admisión con el cliente que la gente usa de verdad. Un usuario registrado con la contraseña, el certificado y el código actual correctos debería conectarse. Un código incorrecto, un usuario sin registro y una cuenta prohibida deberían fallar cada uno, y el motivo debería verse en el registro del servidor. Hasta que hayas visto esos rechazos, tienes una solicitud, no una política.