Пријава на VPN се зауставља након RADIUS Access-Challenge

Лозинка је тачна, пријава на VPN ипак не успева, а RADIUS сервер је можда урадио тачно оно што му је наређено. Пролаз је вероватно примио Access-Challenge, није приказао ништа корисно и затим је истекао или је тај одговор третирао као одбијање. Са стране клијента то изгледа као погрешни акредитив или покварен тунел. Узрок обично лежи у средини разговора који нико није снимио.

Једна пријава, две размене са RADIUS

Када позадински систем жели други фактор, он не одговара на први захтев прихватањем или одбијањем. Одговара кодом 11 и чека следећи одговор корисника, који пролаз мора да пошаље назад у наредном захтеву. Тај наредни захтев припада истом разговору аутентификације, а не новом покушају пријаве.

У исправном подешавању корисник види други упит: прво лозинку, затим једнократни код, или један комбиновани упит ако га је оператер документовао. У поквареном подешавању други упит се никада не појављује и пријава једноставно не успева.

То је симптом који треба пратити, и лако га је потврдити само са стране клијента: ако VPN клијент тражи тачно једну тајну и затим одбије лозинку за коју знате да је важећа, размена је вероватно завршена на изазову.

Шта изазов заправо носи

Спецификација RADIUS описује код 11 у одељку 4.4 и дозвољава два атрибута која су овде важна. Reply-Message садржи текст намењен кориснику, а State садржи непровидан вредност коју сервер жели да добије назад. NAS не треба да тумачи State, само да га врати непромењеног.

Наредни захтев користи нови Identifier и нови Request Authenticator и мора да носи исту вредност State плус одговор корисника. Сервер га повезује са изазовом који чека управо преко тог State, зато пролаз који поново ствара или одбацује атрибут не може да доврши церемонију. И response authenticator у сваком одговору мора да се валидира, иначе NAS треба да одбаци пакет.

Одељак 4.4 додаје детаљ који објашњава већину тихих неуспеха: NAS који не може да подржи изазове третира Access-Challenge као одбијање. Ако је VPN услуга вашег пролаза старија од те подршке или је изоставља, захтев позадинског система за други фактор постаје тренутно «аутентификација није успела» без икаквог упита.

Где се губи ланчани захтев

Први осумњичени је пут захтева, а не акредитив. Портал који приказује поље за OTP при веб пријавама то не чини аутоматски за VPN услугу, а неки пролази прослеђују изазов само клијентима који најављују ту могућност. Тестирајте исти налог на оба улаза; ако портал ради, а VPN не, гледате пренос, а не токен.

Формат уноса је други осумњичени. Спајање лозинке и кода без добављачевог документованог раздвајача, или допуштање сачуваним акредитивима да понове стари код, не успева на начин који изгледа идентично погрешној лозинки. Користите документовани одвојени упит или комбиновани формат оператера и никада не измишљајте раздвајач.

Недостаци специфични за издање постоје, али списак исправљених верзија од пре више година није дијагноза за данашње постављање. Читајте напомене о издању софтвера који заиста покрећете и задржите запажену фазу размене као свој доказ.

Пратите један покушај од почетка до краја

Поновите га једном са укљученим отклањањем грешака на серверу и држите сваку другу сесију изван прозора снимања:

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

У излазу тражите облик разговора, а не један ред. Први Access-Request са Identifier 3, Access-Challenge који носи State, затим други Access-Request са Identifier 4 који понавља тај State и укључује одговор корисника. Ако други захтев недостаје, пролаз никада није наставио. Ако стигне без State, сервер не може да га повеже са изазовом који чека и обично га одбија.

Када делите траг, сакријте акредитиве, токене и непотребне податке о идентитету и повежите догађаје из једног покушаја уместо да мешате понављања из више језичака прегледача. Временске ознаке су овде ваш пријатељ; изазов који стигне након што је клијент одустао изгледа као одбијање за корисника, а у дневнику као спор одговор.

Жељено крајње стање је довршен, ауторизован разговор и потом предвиђени приступ услузи. Одговор који стигне са RADIUS сервера доказује много мање од тога.