O inicio de sesión da VPN bloquéase tras un Access-Challenge de RADIUS

O contrasinal é correcto, o inicio de sesión da VPN falla igualmente, e o servidor RADIUS pode ter feito exactamente o que se lle ordenou. A pasarela probablemente recibiu un Access-Challenge, non mostrou nada útil e logo expirou ou tratou esa resposta como un rexeitamento. Desde o lado do cliente parece unha credencial incorrecta ou un túnel roto. A causa adoita estar no medio dunha conversa que ninguén capturou.

Un inicio de sesión, dous intercambios RADIUS

Cando o backend quere un segundo factor, non responde á primeira petición con aceptación ou rexeitamento. Responde co código 11 e espera a seguinte resposta do usuario, que a pasarela debe enviar nunha petición de seguimento. Esa petición de seguimento pertence á mesma conversa de autenticación, non a un intento de inicio de sesión novo.

Nunha configuración que funciona, o usuario ve un segundo aviso: primeiro o contrasinal, despois un código dun só uso, ou un único aviso combinado se o operador documentou un. Nunha configuración rota, o segundo aviso nunca aparece e o inicio de sesión simplemente falla.

Ese é o síntoma que hai que perseguir, e é fácil de confirmar só desde o lado do cliente: se o cliente da VPN pide exactamente un segredo e logo rexeita un contrasinal que vostede sabe válido, o intercambio probablemente rematou no desafío.

Que leva realmente o desafío

A especificación de RADIUS describe o código 11 na sección 4.4 e permite dous atributos que importan aquí. Reply-Message contén texto dirixido ao usuario, e State contén un valor opaco que o servidor quere recibir de volta. O NAS non debe interpretar State, só devolvelo sen cambios.

A petición de seguimento usa un Identifier novo e un Request Authenticator novo, e debe levar o mesmo valor de State máis a resposta do usuario. O servidor emparella con o desafío pendente mediante ese State, e por iso unha pasarela que rexenera ou descarta o atributo non pode completar a cerimonia. O response authenticator de cada resposta tamén debe validar, ou o NAS debería descartar o paquete.

A sección 4.4 engade o detalle que explica a maioría dos fallos silenciosos: un NAS que non pode soportar desafíos trata Access-Challenge como un rexeitamento. Se o servizo de VPN da súa pasarela é anterior a ese soporte ou o omite, a petición do backend dun segundo factor convértese nun «autenticación fallida» inmediato sen ningún aviso.

Onde se perde a petición encadeada

O primeiro sospeitoso é a ruta do aviso, non a credencial. Un portal que mostra un campo OTP para os inicios de sesión web non o fai automaticamente para o servizo de VPN, e algunhas pasarelas só pasan un desafío aos clientes que anuncian a capacidade. Probe a mesma conta nos dous puntos de entrada; se o portal funciona e a VPN non, está mirando a entrega, non o token.

O formato de entrada é o segundo sospeitoso. Concatenar contrasinal e código sen o separador documentado polo provedor, ou deixar que unha credencial gardada reproduza un código antigo, falla dun xeito que parece idéntico a un contrasinal incorrecto. Use o aviso separado ou o formato combinado documentado polo operador, e nunca improvise un delimitador.

Os defectos específicos de versión existen, pero unha lista de versións corrixidas de hai anos non é un diagnóstico para o despregamento de hoxe. Lea as notas da versión do software que realmente executa e conserve a etapa de intercambio observada como a súa evidencia.

Rastree un só intento de principio a fin

Reproduzao unha vez, coa depuración do servidor activada, e manteña calquera outra sesión fóra da fiestra de captura:

$ sudo radsniff -i eth0 -x -f 'udp port 1812'
$ sudo freeradius -X
$ radtest alice 'password' 127.0.0.1 0 testing123

Na saída, busque a forma da conversa máis que unha soa liña. Un primeiro Access-Request con Identifier 3, un Access-Challenge que leva State, e despois un segundo Access-Request con Identifier 4 que repite ese State e inclúe a resposta do usuario. Se falta a segunda petición, a pasarela nunca fixo o seguimento. Se chega sen State, o servidor non pode emparellala co desafío pendente e normalmente rexeitaraa.

Oculte credenciais, tokens e datos de identidade innecesarios cando comparta a traza, e correlacione os acontecementos dun só intento en vez de mesturar reintentos de varias lapelas do navegador. As marcas de tempo son a súa amiga aquí; un desafío que chega despois de que o cliente se rendeu parece un rexeitamento para o usuario e unha resposta lenta no rexistro.

O estado final que desexa é unha conversa completada e autorizada seguida do acceso previsto ao servizo. Unha resposta que chega do servidor RADIUS demostra moito menos ca iso.