Hyrja në VPN ngec pas një Access-Challenge të RADIUS

Fjalëkalimi është i saktë, hyrja në VPN dështon gjithsesi, dhe serveri RADIUS mund të ketë bërë pikërisht atë që iu urdhërua. Porta ka marrë me gjasë një Access-Challenge, nuk tregoi asgjë të dobishme dhe më pas skadoi ose e trajtoi atë përgjigje si refuzim. Nga ana e klientit duket si kredencial i gabuar ose tunel i prishur. Shkaku zakonisht ndodhet në mes të një bisede që askush nuk e kapi.

Një hyrje, dy shkëmbime me RADIUS

Kur backend-i do një faktor të dytë, ai nuk i përgjigjet kërkesës së parë me pranim ose refuzim. Përgjigjet me kodin 11 dhe pret përgjigjen tjetër të përdoruesit, të cilën porta duhet ta kthejë në një kërkesë vijuese. Ajo kërkesë vijuese i takon të njëjtës bisedë vërtetimi, jo një tentative të re hyrjeje.

Në një konfigurim që funksionon, përdoruesi sheh një kërkesë të dytë: fillimisht fjalëkalimin, pastaj një kod njëpërdorimshëm, ose një kërkesë të vetme të kombinuar nëse operatori ka dokumentuar një të tillë. Në një konfigurim të prishur, kërkesa e dytë nuk shfaqet kurrë dhe hyrja thjesht dështon.

Ky është simptoma që duhet ndjekur, dhe është e lehtë të konfirmohet vetëm nga ana e klientit: nëse klienti VPN kërkon saktësisht një sekret dhe më pas refuzon një fjalëkalim që ju e dini se është i vlefshëm, shkëmbimi me gjasë përfundoi te sfida.

Çfarë mbart në të vërtetë sfida

Specifikimi RADIUS përshkruan kodin 11 në seksionin 4.4 dhe lejon dy atribute që kanë rëndësi këtu. Reply-Message mban tekst të destinuar për përdoruesin, dhe State mban një vlerë të errët që serveri dëshiron ta marrë mbrapsht. NAS nuk duhet ta interpretojë State, vetëm ta kthejë të pandryshuar.

Kërkesa vijuese përdor një Identifier të ri dhe një Request Authenticator të ri, dhe duhet të mbartë të njëjtën vlerë State plus përgjigjen e përdoruesit. Serveri e përputh atë me sfidën në pritje përmes atij State, prandaj një portë që e rigjeneron ose e hedh atributin nuk mund ta përfundojë ceremoninë. Edhe response authenticator në çdo përgjigje duhet të vërtetohet, përndryshe NAS duhet ta hedhë paketën.

Seksioni 4.4 shton detajin që shpjegon shumicën e dështimeve të heshtura: një NAS që nuk mund të mbështesë sfidat e trajton Access-Challenge si refuzim. Nëse shërbimi VPN i portës tuaj është më i vjetër se ai mbështetje ose e lë jashtë, kërkesa e backend-it për një faktor të dytë bëhet «vërtetimi dështoi» i menjëhershëm pa asnjë kërkesë.

Ku humbet kërkesa e zinxhiruar

I dyshuari i parë është rruga e kërkesës, jo kredenciali. Një portal që shfaq një fushë OTP për hyrjet në web nuk e bën këtë automatikisht për shërbimin VPN, dhe disa porta e kalojnë sfidën vetëm te klientët që e shpallin këtë aftësi. Provoni të njëjtin llogari në të dyja pikat e hyrjes; nëse portali punon dhe VPN jo, po shikoni dorëzimin, jo tokenin.

Formati i hyrjes është i dyshuari i dytë. Bashkimi i fjalëkalimit dhe kodit pa ndarësin e dokumentuar nga furnizuesi, ose lejimi që një kredencial i ruajtur të riprodhojë një kod të vjetër, dështon në një mënyrë që duket identike me një fjalëkalim të gabuar. Përdorni kërkesën e veçantë ose formatin e kombinuar të dokumentuar nga operatori, dhe kurrë mos sajoni një ndarës.

Defektet specifike për versionin ekzistojnë, por një listë e versioneve të rregulluara prej vitesh nuk është diagnozë për vendosjen e sotme. Lexoni shënimet e publikimit të softuerit që ekzekutoni vërtet, dhe mbani fazën e vëzhguar të shkëmbimit si provën tuaj.

Ndiqni një tentativë të vetme nga fillimi në fund

Riprodhoni atë një herë, me korrigjimin e gabimeve në anën e serverit të aktivizuar, dhe mbani çdo sesion tjetër jashtë dritares së kapjes:

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

Në dalje kërkoni formën e bisedës dhe jo një rresht të vetëm. Një Access-Request i parë me Identifier 3, një Access-Challenge që mbart State, pastaj një Access-Request i dytë me Identifier 4 që përsërit atë State dhe përfshin përgjigjen e përdoruesit. Nëse kërkesa e dytë mungon, porta nuk e ka ndjekur kurrë. Nëse vjen pa State, serveri nuk mund ta përputhë me sfidën në pritje dhe zakonisht e refuzon.

Kur ndani gjurmën, fshihni kredencialet, tokenat dhe të dhënat e panevojshme të identitetit, dhe korreloni ngjarjet nga një tentativë e vetme në vend që të përzieni përsëritje nga disa skeda të shfletuesit. Vulat kohore janë miku juaj këtu; një sfidë që arrin pasi klienti ka hequr dorë duket si refuzim për përdoruesin dhe si përgjigje e ngadaltë në regjistër.

Gjendja përfundimtare që dëshironi është një bisedë e përfunduar dhe e autorizuar, e ndjekur nga aksesi i synuar në shërbim. Një përgjigje që vjen nga serveri RADIUS dëshmon shumë më pak se kaq.