VPN prijava zastaje nakon RADIUS Access-Challenge

Lozinka je ispravna, VPN prijava ipak ne uspijeva, a RADIUS server je možda učinio tačno ono što mu je rečeno. Pristupnik je vjerojatno primio Access-Challenge, nije pokazao ništa korisno, a zatim je istekao ili je taj odgovor tretirao kao odbijanje. Sa strane klijenta to izgleda kao loši podaci za prijavu ili pokvaren tunel. Uzrok obično leži u sredini razgovora koji nitko nije snimio.

Jedna prijava, dvije RADIUS razmjene

Kada pozadinski sustav želi drugi faktor, on ne odgovara na prvi zahtjev prihvaćanjem ili odbijanjem. Odgovara kodom 11 i čeka sljedeći odgovor korisnika, koji pristupnik mora poslati natrag u naknadnom zahtjevu. Taj naknadni zahtjev pripada istoj razgovoru autentifikacije, a ne novom pokušaju prijave.

U ispravnoj postavci korisnik vidi drugi upit: prvo lozinku, zatim jednokratni kod, ili jedan objedinjeni upit ako ga je operater dokumentirao. U pokvarenoj postavci drugi upit se nikada ne pojavi i prijava jednostavno ne uspije.

To je simptom koji treba loviti, i lako ga je potvrditi samo sa strane klijenta: ako VPN klijent traži tačno jednu tajnu i zatim odbije lozinku za koju znate da je ispravna, razmjena je vjerojatno završila na izazovu.

Što izazov zapravo nosi

RADIUS specifikacija opisuje kod 11 u odjeljku 4.4 i dopušta dva atributa koja su ovdje važna. Reply-Message drži tekst namijenjen korisniku, a State drži neprozirnu vrijednost koju server želi dobiti natrag. NAS ne smije tumačiti State, samo ga vratiti nepromijenjenog.

Naknadni zahtjev koristi novi Identifier i novi Request Authenticator, i mora nositi istu vrijednost State plus korisnikov odgovor. Server ga povezuje s izazovom koji čeka kroz taj State, zato pristupnik koji regenerira ili odbaci atribut ne može dovršiti ceremoniju. Response authenticator u svakom odgovoru također mora biti valjan, inače NAS mora odbaciti paket.

Odjeljak 4.4 dodaje detalj koji objašnjava većinu tihih neuspjeha: NAS koji ne može podržati izazove tretira Access-Challenge kao odbijanje. Ako VPN usluga vašeg pristupnika prethodi tom vremenu ili ne uključuje tu podršku, zahtjev pozadine za drugim faktorom postaje trenutna «autentifikacija nije uspjela» bez ikakvog upita.

Gdje se lančani zahtjev gubi

Prvi osumnjičeni je putanja upita, a ne podaci za prijavu. Portal koji prikazuje OTP polje za web prijave ne čini to automatski i za VPN uslugu, a neki pristupnici prosljeđuju izazov samo klijentima koji tu mogućnost najavljuju. Testirajte isti račun na oba pristupna mjesta; ako portal radi a VPN ne, gledate primopredaju, ne token.

Format unosa je drugi osumnjičeni. Spajanje lozinke i koda bez proizvođačevog dokumentiranog razdjelnika, ili puštanje spremljenih podataka da ponove stari kod, ne uspijeva na način koji izgleda identično pogrešnoj lozinci. Koristite operaterom dokumentirani odvojeni upit ili objedinjeni format i nikada ne izmišljajte razdjelnik.

Defekti specifični za izdanje postoje, ali popis popravljenih verzija od prije mnogo godina nije dijagnoza za današnju instalaciju. Čitajte bilješke izdanja softvera koji stvarno pokrećete i držite promatranu fazu razmjene kao svoj dokaz.

Pratite jedan pokušaj od početka do kraja

Reproducirajte jednom, s uključenim otklanjanjem pogrešaka na serveru, i držite svaku drugu sesiju izvan prozora snimanja:

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

U izlazu tražite oblik razgovora, a ne jedan redak. Prvi Access-Request s Identifier 3, Access-Challenge koji nosi State, zatim drugi Access-Request s Identifier 4 koji ponavlja taj State i uključuje korisnikov odgovor. Ako drugi zahtjev nedostaje, pristupnik nikada nije nastavio. Ako stigne bez State, server ga ne može povezati s izazovom koji čeka i obično će ga odbiti.

Uklonite podatke za prijavu, tokene i nepotrebne identitetske podatke kada dijelite trag, i povežite događaje iz jednog pokušaja umjesto da miješate ponovne pokušaje iz nekoliko kartica preglednika. Vremenske oznake su vam ovdje prijatelj; izazov koji stigne nakon što je klijent odustao korisniku izgleda kao odbijanje, a u zapisu kao spor odgovor.

Završno stanje koje želite jest dovršen, autoriziran razgovor nakon kojeg slijedi predviđeni pristup usluzi. Odgovor koji stigne s RADIUS servera dokazuje mnogo manje od toga.