VPN prisijungimas stringa po RADIUS Access-Challenge

Jūsų slaptažodis teisingas, VPN prisijungimas vis tiek nepavyksta, o RADIUS serveris galbūt padarė būtent tai, kas jam buvo liepta. Šliuzas tikriausiai gavo Access-Challenge, nieko naudingo neparodė ir tada baigėsi laikas arba jis tą atsakymą palaikė atmetimu. Iš kliento pusės tai atrodo kaip neteisingi prisijungimo duomenys arba sugedęs tunelis. Priežastis paprastai slypi pokalbio viduryje, kurio niekas neužfiksavo.

Vienas prisijungimas, du RADIUS apsikeitimai

Kai backend nori antrojo veiksnio, jis į pirmą užklausą neatsako priėmimu ar atmetimu. Jis atsako kodu 11 ir laukia kito vartotojo atsakymo, kurį šliuzas turi išsiųsti atgal tolesnėje užklausoje. Ta tolesnė užklausa priklauso tam pačiam autentifikavimo pokalbiui, o ne naujam prisijungimo bandymui.

Veikiančioje konfigūracijoje vartotojas mato antrą raginimą: pirmiausia slaptažodį, tada vienkartinį kodą, arba vieną sujungtą raginimą, jei operatorius tokį dokumentavo. Sugedusioje konfigūracijoje antras raginimas niekada nepasirodo ir prisijungimas tiesiog nepavyksta.

Tai simptomas, kurį reikia persekioti, ir jį lengva patvirtinti vien iš kliento pusės: jei VPN klientas prašo tiksliai vienos paslapties ir tada atmeta slaptažodį, kurį žinote esant galiojantį, apsikeitimas tikriausiai baigėsi ties iššūkiu.

Ką iššūkis iš tikrųjų neša

RADIUS specifikacija aprašo kodą 11 4.4 skyriuje ir leidžia du atributus, kurie čia svarbūs. Reply-Message laiko vartotojui skirtą tekstą, o State laiko nepermatomą reikšmę, kurią serveris nori gauti atgal. NAS neturėtų interpretuoti State, tik grąžinti jį nepakeistą.

Tolesnė užklausa naudoja naują Identifier ir naują Request Authenticator, ir ji turi nešti tą pačią State reikšmę bei vartotojo atsakymą. Serveris susieja ją su laukiančiu iššūkiu būtent per tą State, todėl šliuzas, kuris atkuria arba numeta atributą, negali užbaigti ceremonijos. Kiekvieno atsakymo response authenticator taip pat turi būti patvirtintas, kitaip NAS turėtų išmesti paketą.

4.4 skyrius prideda detalę, paaiškinančią daugumą tylių gedimų: NAS, kuris negali palaikyti iššūkių, Access-Challenge traktuoja kaip atmetimą. Jei jūsų šliuzo VPN paslauga yra senesnė už tą palaikymą arba jo neturi, backend prašymas dėl antrojo veiksnio tampa momentiniu «autentifikavimas nepavyko» be jokio raginimo.

Kur pasimeta grandininė užklausa

Pirmas įtariamasis yra raginimo kelias, o ne prisijungimo duomenys. Portalas, kuris rodo OTP lauką web prisijungimams, automatiškai to nedaro VPN paslaugai, o kai kurie šliuzai iššūkį perduoda tik tiems klientams, kurie paskelbia šią galimybę. Išbandykite tą pačią paskyrą abiejuose įėjimuose; jei portalas veikia, o VPN ne, jūs žiūrite į perdavimą, o ne į tokeną.

Įvesties formatas yra antras įtariamasis. Slaptažodžio ir kodo sujungimas be tiekėjo dokumentuoto skyriklio arba leidimas išsaugotiems duomenims kartoti seną kodą nepavyksta taip, kad atrodo identiškai neteisingam slaptažodžiui. Naudokite operatoriaus dokumentuotą atskirą raginimą arba sujungtą formatą ir niekada neišgalvokite skyriklio.

Leidimui būdingų defektų būna, tačiau prieš kelerius metus pataisytų versijų sąrašas nėra šiandieninio diegimo diagnozė. Skaitykite programinės įrangos, kurią iš tikrųjų naudojate, leidimo pastabas ir stebėtą apsikeitimo etapą laikykite savo įrodymu.

Sekite vieną bandymą nuo pradžios iki pabaigos

Atkurkite jį vieną kartą, įjungę serverio pusės derinimą, ir laikykite visas kitas sesijas už fiksavimo lango:

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

Išvestyje ieškokite pokalbio formos, o ne vienos eilutės. Pirmoji Access-Request su Identifier 3, State nešantis Access-Challenge, tada antroji Access-Request su Identifier 4, kuri kartoja tą State ir apima vartotojo atsakymą. Jei antrosios užklausos nėra, šliuzas niekada nesekė. Jei ji ateina be State, serveris negali jos susieti su laukiančiu iššūkiu ir paprastai atmes.

Dalindamiesi pėdsaku paslėpkite prisijungimo duomenis, tokenus ir nereikalingus tapatybės duomenis, o įvykius koreliuokite iš vieno bandymo, o ne maišykite kartojimus iš kelių naršyklės skirtukų. Laiko žymos čia yra jūsų draugas; iššūkis, kuris ateina po to, kai klientas pasidavė, vartotojui atrodo kaip atmetimas, o žurnale kaip lėtas atsakymas.

Norima galutinė būsena yra užbaigtas, autorizuotas pokalbis ir po jo numatyta prieiga prie paslaugos. Iš RADIUS serverio atėjęs atsakymas įrodo daug mažiau.