L’inici de sessió de la VPN s’encalla després d’un Access-Challenge de RADIUS

La contrasenya és correcta, l’inici de sessió de la VPN falla igualment, i el servidor RADIUS pot haver fet exactament el que se li va ordenar. La passarel·la probablement va rebre un Access-Challenge, no va mostrar res d’útil i després va expirar o va tractar aquella resposta com un rebuig. Des del costat del client sembla una credencial incorrecta o un túnel trencat. La causa sol estar al mig d’una conversa que ningú no va capturar.

Un inici de sessió, dos intercanvis RADIUS

Quan el backend vol un segon factor, no respon la primera petició amb acceptació o rebuig. Respon amb el codi 11 i espera la resposta següent de l’usuari, que la passarel·la ha d’enviar en una petició de seguiment. Aquesta petició de seguiment pertany a la mateixa conversa d’autenticació, no a un intent d’inici de sessió nou.

En una configuració que funciona, l’usuari veu un segon missatge: primer la contrasenya, després un codi d’un sol ús, o un únic missatge combinat si l’operador n’ha documentat un. En una configuració trencada, el segon missatge no apareix mai i l’inici de sessió simplement falla.

Aquest és el símptoma que cal perseguir, i és fàcil de confirmar només des del costat del client: si el client de la VPN demana exactament un secret i després rebutja una contrasenya que sabeu que és vàlida, l’intercanvi probablement va acabar al desafiament.

Què porta realment el desafiament

L’especificació de RADIUS descriu el codi 11 a la secció 4.4 i permet dos atributs que importen aquí. Reply-Message conté text adreçat a l’usuari, i State conté un valor opac que el servidor vol rebre de tornada. El NAS no ha d’interpretar State, només retornar-lo sense canvis.

La petició de seguiment fa servir un Identifier nou i un Request Authenticator nou, i ha de portar el mateix valor de State més la resposta de l’usuari. El servidor l’empareja amb el desafiament pendent mitjançant aquest State, i per això una passarel·la que regenera o descarta l’atribut no pot completar la cerimònia. El response authenticator de cada resposta també ha de validar-se, o el NAS hauria de descartar el paquet.

La secció 4.4 afegeix el detall que explica la majoria de fallades silencioses: un NAS que no pot suportar desafiaments tracta Access-Challenge com un rebuig. Si el servei de VPN de la vostra passarel·la és anterior a aquest suport o l’omet, la petició del backend per un segon factor es converteix en un «error d’autenticació» immediat sense cap missatge.

On es perd la petició encadenada

El primer sospitós és el camí del missatge, no la credencial. Un portal que mostra un camp OTP per als inicis de sessió web no ho fa automàticament per al servei de VPN, i algunes passarel·les només passen el desafiament als clients que anuncien la capacitat. Proveu el mateix compte als dos punts d’entrada; si el portal funciona i la VPN no, esteu mirant el lliurament, no el testimoni.

El format d’entrada és el segon sospitós. Concatenar contrasenya i codi sense el separador documentat pel proveïdor, o deixar que una credencial desada reprodueixi un codi antic, falla d’una manera idèntica a una contrasenya incorrecta. Feu servir el missatge separat o el format combinat documentat per l’operador, i no improviseu mai un delimitador.

Els defectes específics de versió existeixen, però una llista de versions corregides de fa anys no és un diagnòstic per al desplegament d’avui. Llegiu les notes de la versió del programari que realment executeu i conserveu l’etapa d’intercanvi observada com a prova.

Resseguiu un sol intent de cap a fi

Reproduïu-lo una vegada, amb la depuració del servidor activada, i manteniu qualsevol altra sessió fora de la finestra de captura:

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

A la sortida, busqueu la forma de la conversa més que una sola línia. Una primera Access-Request amb Identifier 3, una Access-Challenge que porta State, i després una segona Access-Request amb Identifier 4 que repeteix aquell State i inclou la resposta de l’usuari. Si falta la segona petició, la passarel·la no va fer mai el seguiment. Si arriba sense State, el servidor no la pot emparejar amb el desafiament pendent i normalment la rebutjarà.

Oculteu les credencials, els testimonis i les dades d’identitat innecessàries quan compartiu la traça, i correlacioneu els esdeveniments d’un sol intent en lloc de barrejar reintents de diverses pestanyes del navegador. Les marques de temps són la vostra amiga aquí; un desafiament que arriba després que el client s’hagi rendit sembla un rebuig per a l’usuari i una resposta lenta al registre.

L’estat final que voleu és una conversa completada i autoritzada seguida de l’accés previst al servei. Una resposta que arriba del servidor RADIUS demostra molt menys que això.