Вхід у 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, доводить значно менше.