Onde vai o código de desafío estático nun inicio de sesión de OpenVPN

O cliente mostra un segundo cadro tras o campo do contrasinal, vostede escribe o código do token de hardware e o inicio de sesión segue fallando cun erro de autenticación. Ese cadro existe, así que o perfil pediuno. Se o servidor chegou a recibir o valor nunha forma que entende é outra pregunta, e é a que convén responder primeiro.

Comece pola mensaxe que o seu cliente mostra realmente

Un perfil pode levar unha directiva de desafío estático cunha cadea de mensaxe e un indicador que controla se a resposta se mostra mentres escribe. A mensaxe é o que ve no diálogo; o indicador é unha preferencia de visualización para esa mesma entrada. Ningún dos dous lle di ao servidor como verificar nada.

Conte os campos que realmente lle deron. Un campo para un nome de usuario máis un campo enmascarado é un inicio de sesión normal con contrasinal e sen ningún desafío. Un segundo campo que aparece despois do contrasinal, coa súa propia etiqueta, é o cliente implementando a interacción do desafío.

Se o segundo cadro nunca aparece no cliente que usa, pode que ese cliente non implemente a interacción, ou que só a implemente mediante outra interface, como unha interface de xestión. Comprobar o cliente é máis barato que reescribir o perfil, e adoita ser onde está realmente a discrepancia.

O que o servidor xa ten que admitir

O perfil describe o que o cliente debe recoller. Non activa a verificación no servidor, e un servidor sen a integración de autenticación correspondente simplemente recibirá un contrasinal que non recoñece. Por iso algúns despregamentos mostran a mensaxe e rexeitan todos os códigos, e por iso a resposta do operador sobre que mecanismo fai a comprobación é a que importa.

Pregunte ao operador que mecanismo fai a comprobación. Pode ser un complemento que fala con PAM, un gancho de script que valida a resposta contra un servizo de tokens, ou unha integración baseada na xestión que analiza ela mesma o valor empaquetado. Cada un espera unha entrada algo distinta.

Aquí tamén hai que calibrar as expectativas. Unha segunda mensaxe é un mecanismo de entrada, non a proba de que se aplique un segundo factor, porque a aplicación ocorre no lado do servidor e só se nota ao probar un código incorrecto.

O campo codificado que envía a interface de xestión

Cando unha interface impulsa a conexión a través da interface de xestión, o contrasinal e a resposta ao desafío empaquétanse nun só valor antes do envío. A referencia da interface de xestión documenta o formato: un prefixo e despois o contrasinal e a resposta como compoñentes Base64 separados.

Base64 é unha codificación, non unha protección. Non oculta nada a quen poida ler o campo, e non converte un código dun só uso en algo reutilizable. O valor empaquetado merece o mesmo trato que un contrasinal: fóra dos perfís compartidos, fóra das liñas de ordes e fóra dos rexistros de diagnóstico.

Esa codificación é tamén a fonte de confusión máis habitual, porque agora hai tres formas que se parecen e non son intercambiables. Un ficheiro de credenciais simple contén un contrasinal. Unha concatenación literal de contrasinal e código contén unha cadea distinta. A resposta empaquetada dun cliente de xestión contén unha terceira. Confirme cal espera a súa ruta de verificación antes de cambiar un campo só porque un erro desapareceu.

Estático fronte a dinámico: distinto momento

Un desafío estático coñécese antes de enviar a primeira credencial, así que o cliente pode pedilo por adiantado. Un desafío dinámico chega máis tarde, enviado polo fluxo de autenticación despois de que xa comezase un intercambio, e necesita un cliente capaz de xestionar unha petición a metade da conversa.

O soporte dun non lle dá o outro. Unha directiva de perfil que configura unha mensaxe estática non implementa un desafío iniciado polo servidor, e unha interface que xestiona peticións dinámicas pode seguir sen mostrar unha estática. Ler que lado iniciou a petición é a forma máis rápida de distinguilos.

O funcionamento desatendido é onde isto se converte nunha cuestión de deseño e non de interface. Un código gardado non é unha credencial duradeira de arranque, e unha reconexión horas despois necesitará unha entrada nova salvo que o despregamento admita unha disposición de tokens que o operador habilitase a propósito.

Probe o éxito e o fallo, non só o diálogo

Executar as dúas metades da proba. Unhas credenciais correctas cunha resposta válida deberían funcionar; unhas credenciais correctas cunha resposta deliberadamente incorrecta deberían ser rexeitadas. Se ambas funcionan, o cliente recolle unha entrada que nada verifica, e o diálogo confundiuse cun control. Esa única proba detecta máis despregamentos que calquera revisión de perfil.

Despois repita a conexión tras unha reconexión, cunha conta que non estea inscrita e a través do cliente que os seus usuarios usen realmente. Que apareza a mensaxe é un comportamento do cliente; que se rexeite un código incorrecto é o servidor aplicando algo.