Најавувањето во VPN застанува по Access-Challenge од RADIUS

Вашата лозинка е точна, најавувањето во 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 серверот докажува многу помалку од тоа.