Влизането във 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, доказва много по-малко от това.