Dónde va el código de desafío estático en un inicio de sesión de OpenVPN

El cliente muestra un segundo cuadro tras el campo de contraseña, usted escribe el código del token de hardware y el inicio de sesión sigue fallando con un error de autenticación. Ese cuadro existe, así que el perfil lo pidió. Si el servidor llegó a recibir el valor en una forma que entiende es otra pregunta, y es la que conviene responder primero.

Empiece por el mensaje que su cliente muestra realmente

Un perfil puede llevar una directiva de desafío estático con una cadena de mensaje y un indicador que controla si la respuesta se muestra mientras escribe. El mensaje es lo que ve en el diálogo; el indicador es una preferencia de visualización para esa misma entrada. Ninguno de los dos le dice al servidor cómo verificar nada.

Cuente los campos que realmente le dieron. Un campo para un nombre de usuario más un campo enmascarado es un inicio de sesión normal con contraseña y sin ningún desafío. Un segundo campo que aparece después de la contraseña, con su propia etiqueta, es el cliente implementando la interacción del desafío.

Si el segundo cuadro nunca aparece en el cliente que usa, puede que ese cliente no implemente la interacción, o que solo la implemente mediante otra interfaz, como una interfaz de gestión. Comprobar el cliente es más barato que reescribir el perfil, y suele ser donde realmente está la discrepancia.

Lo que el servidor ya tiene que admitir

El perfil describe lo que el cliente debe recoger. No habilita la verificación en el servidor, y un servidor sin la integración de autenticación correspondiente simplemente recibirá una contraseña que no reconoce. Por eso algunos despliegues muestran el mensaje y rechazan todos los códigos, y por eso la respuesta del operador sobre qué mecanismo hace la comprobación es la que importa.

Pregunte al operador qué mecanismo hace la comprobación. Puede ser un complemento que habla con PAM, un gancho de script que valida la respuesta contra un servicio de tokens, o una integración basada en gestión que analiza ella misma el valor empaquetado. Cada uno espera una entrada algo distinta.

Aquí también hay que calibrar las expectativas. Un segundo mensaje es un mecanismo de entrada, no la prueba de que se aplique un segundo factor, porque la aplicación ocurre en el lado del servidor y solo se nota al probar un código incorrecto.

El campo codificado que envía la interfaz de gestión

Cuando una interfaz impulsa la conexión a través de la interfaz de gestión, la contraseña y la respuesta al desafío se empaquetan en un solo valor antes del envío. La referencia de la interfaz de gestión documenta el formato: un prefijo y luego la contraseña y la respuesta como componentes Base64 separados.

Base64 es una codificación, no una protección. No oculta nada a quien pueda leer el campo, y no convierte un código de un solo uso en algo reutilizable. El valor empaquetado merece el mismo trato que una contraseña: fuera de los perfiles compartidos, fuera de las líneas de comandos y fuera de los registros de diagnóstico.

Esa codificación es también la fuente de confusión más habitual, porque ahora hay tres formas que se parecen y no son intercambiables. Un archivo de credenciales simple contiene una contraseña. Una concatenación literal de contraseña y código contiene una cadena distinta. La respuesta empaquetada de un cliente de gestión contiene una tercera. Confirme cuál espera su ruta de verificación antes de cambiar un campo solo porque un error desapareció.

Estático frente a dinámico: distinto momento

Un desafío estático se conoce antes de enviar la primera credencial, así que el cliente puede pedirlo por adelantado. Un desafío dinámico llega más tarde, enviado por el flujo de autenticación después de que ya haya comenzado un intercambio, y necesita un cliente capaz de gestionar una petición a mitad de la conversación.

El soporte de uno no le da el otro. Una directiva de perfil que configura un mensaje estático no implementa un desafío iniciado por el servidor, y una interfaz que gestiona peticiones dinámicas puede seguir sin mostrar uno estático. Leer qué lado inició la petición es la forma más rápida de distinguirlos.

La operación desatendida es donde esto se convierte en una cuestión de diseño y no de interfaz. Un código guardado no es una credencial duradera de arranque, y una reconexión horas después necesitará una entrada nueva salvo que el despliegue admita una disposición de tokens que el operador haya habilitado a propósito.

Pruebe el éxito y el fallo, no solo el diálogo

Ejecute las dos mitades de la prueba. Unas credenciales correctas con una respuesta válida deberían funcionar; unas credenciales correctas con una respuesta deliberadamente incorrecta deberían ser rechazadas. Si ambas funcionan, el cliente recoge una entrada que nada verifica, y el diálogo se ha confundido con un control. Esa única prueba detecta más despliegues que cualquier revisión de perfil.

Luego repita la conexión tras una reconexión, con una cuenta que no esté inscrita y a través del cliente que sus usuarios usen realmente. Que aparezca el mensaje es un comportamiento del cliente; que se rechace un código incorrecto es el servidor aplicando algo.