VPN-aanmelding hang ná ’n RADIUS Access-Challenge

Jou wagwoord is reg, die VPN-aanmelding misluk steeds, en die RADIUS-bediener het dalk presies gedoen wat hom opgedra is. Die gateway het waarskynlik ’n Access-Challenge ontvang, niks nuttigs gewys nie en toe uitgetree of daardie antwoord as ’n verwerping hanteer. Van die kliënt se kant lyk dit soos slegte geloofsbriewe of ’n stukkende tonnel. Die oorsaak sit gewoonlik in die middel van ’n gesprek wat niemand vasgevang het nie.

Een aanmelding, twee RADIUS-uitruilings

Wanneer die backend ’n tweede faktor wil hê, antwoord dit nie die eerste versoek met aanvaar of verwerp nie. Dit antwoord met kode 11 en wag vir die gebruiker se volgende antwoord, wat die gateway in ’n opvolgversoek moet terugstuur. Daardie opvolg hoort by dieselfde verifikasi­gesprek, nie by ’n nuwe aanmeldpoging nie.

In ’n werkende opset sien die gebruiker ’n tweede prompt: eers die wagwoord, dan ’n eenmalige kode, of ’n enkele gekombineerde prompt as die operateur een gedokumenteer het. In ’n stukkende opset verskyn die tweede prompt nooit nie en die aanmelding misluk bloot.

Dit is die simptoom om te jaag, en dit is maklik om net van die kliënt se kant af te bevestig: as die VPN-kliënt na presies een geheim vra en dan ’n wagwoord verwerp wat jy weet geldig is, het die uitruiling waarskynlik by die challenge geëindig.

Wat die challenge eintlik dra

Die RADIUS-spesifikasie beskryf kode 11 in afdeling 4.4 en laat twee attribute toe wat hier saak maak. Reply-Message hou teks wat vir die gebruiker bedoel is, en State hou ’n ondeursigtige waarde wat die bediener terugverwagtig het. Die NAS is nie veronderstel om State te interpreteer nie, net om dit onveranderd terug te gee.

Die opvolgversoek gebruik ’n nuwe Identifier en ’n nuwe Request Authenticator, en dit moet dieselfde State-waarde plus die gebruiker se antwoord dra. Die bediener pas dit deur daardie State by die hangende challenge, daarom kan ’n gateway wat die attribuut hergenereer of laat val nie die seremonie voltooi nie. Die response authenticator op elke antwoord moet ook valideer, anders moet die NAS die pakket weggooi.

Afdeling 4.4 voeg die detail by wat die meeste stille foute verklaar: ’n NAS wat nie challenges kan ondersteun nie, hanteer Access-Challenge as ’n verwerping. As jou gateway se VPN-diens daardie ondersteuning voorafgaan of dit weglaat, word die backend se versoek om ’n tweede faktor ’n onmiddellike “verifikasie het misluk” sonder enige prompt.

Waar die gekettingde versoek verlore gaan

Die eerste verdagte is die prompt-pad eerder as die geloofsbrief. ’n Portaal wat ’n OTP-veld vir web-aanmeldings wys, doen dit nie outomaties ook vir die VPN-diens nie, en sommige gateways gee net ’n challenge aan kliënte wat die vermoë adverteer. Toets dieselfde rekening by albei toegangspunte; as die portaal werk en die VPN nie, kyk jy na die oorhandiging, nie na die token nie.

Invoerformaat is die tweede verdagte. Om wagwoord en kode sonder die verskaffer se gedokumenteerde skeier te koppel, of om ’n gestoorde geloofsbrief ’n ou kode te laat hergebruik, misluk op ’n manier wat identies aan ’n verkeerde wagwoord lyk. Gebruik die operateur se gedokumenteerde aparte prompt of gekombineerde formaat, en improviseer nooit ’n skeier nie.

Vrystellingspesifieke foute bestaan wel, maar ’n lys reggemaakte weergawes van jare gelede is nie ’n diagnose vir vandag se ontplooiing nie. Lees die vrystellingsnotas vir die sagteware wat jy werklik gebruik, en hou die waargeneemde stadium van die uitruiling as jou bewyse.

Volg ’n enkele poging van begin tot einde

Reproduseer een keer, met ontfouting aan die bedienerkant aan, en hou elke ander sessie uit die vasvangvenster:

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

In die uitset, kyk na die vorm van die gesprek eerder as na ’n enkele reël. ’n Eerste Access-Request met Identifier 3, ’n Access-Challenge wat State dra, dan ’n tweede Access-Request met Identifier 4 wat daardie State herhaal en die gebruiker se antwoord insluit. As die tweede versoek ontbreek, het die gateway nooit opgevolg nie. As dit sonder State aankom, kan die bediener dit nie by die hangende challenge pas nie en sal dit gewoonlik verwerp.

Verwyder geloofsbriewe, tokens en onnodige identiteitsdata wanneer jy die spoor deel, en korreleer gebeurtenisse uit die een poging in plaas daarvan om herprobeersels uit verskeie blaaier-oortjies te vermeng. Tydstempels is jou vriend hier; ’n challenge wat opdaag nadat die kliënt opgegee het, lyk vir die gebruiker soos ’n verwerping en in die log soos ’n stadige antwoord.

Die voltooide toestand wat jy wil hê, is ’n voltooide, gemagtigde gesprek gevolg deur die beoogde dienstoegang. ’n Antwoord wat van die RADIUS-bediener aankom, bewys veel minder as dit.