Підключення RADIUS до OpenVPN: плагін чи скрипт-хук?

Плагін досі радять у темах, старших за поточні збірки, а на сервері, зібраному вчора, він падає під час завантаження. Це не помилка конфігурації, яку можна виправити шляхом. Плагін і скрипт-хук вирішують ту саму задачу на різних рівнях, і перехід з одного на інший змінює те, що треба встановити, що працює з правами сервера і що насправді каже невдалий вхід.

Міф: плагін — це підтримуваний шлях

Плагін — це спільний об'єкт, завантажений у процес OpenVPN, тому він має відповідати інтерфейсу, який цей процес надає. Збірки змінюються, пакування змінюється, і бібліотека, скомпільована для старішого інтерфейсу, просто відмовляється завантажуватися. Ніщо в конфігурації сервера не може подолати цю прогалину, тому порада «просто встановіть radiusplugin» закінчується сервером, який не запускається.

Скрипт-хук натомість стоїть поза процесом. OpenVPN запускає програму, передає їй облікові дані й читає вердикт. Саме це розділення дозволяє йому переживати оновлення і робить його вашою відповідальністю так, як плагін ніколи не був.

Жоден підхід не безпечніший за своєю конструкцією. Один виконує чужий код усередині демона; інший виконує ваш код поруч, тримаючи облікові дані в руках. Правильне питання — який із цих двох ризиків ви справді можете експлуатувати.

Що плагін зв'язував

Плагін мав власний файл конфігурації з хостом RADIUS, спільним секретом, кількістю повторів і тайм-аутом, а конфігурація сервера посилалася на нього одним рядком. Обробка облікових даних залишалася всередині серверного процесу, тобто пароль ніколи не перетинав межу процесу, яку адміністратор мав захистити.

Ціною була зв'язаність. Кожне оновлення OpenVPN ризикувало несумісним інтерфейсом, а кожен дистрибутив, що перезбирав пакет, ризикував бібліотекою, яка більше не підходить. Коли це стається, збій гучний і миттєвий, і це єдина милість цієї конструкції.

Якщо такий плагін ще завантажується на вашій збірці, він може бути меншою операційною поверхнею. Підтвердьте інтерфейс, під який його зібрано, тримайте його прикріпленим до перевіреної збірки й трактуйте будь-яке оновлення як зміну, що вимагає повного тесту входу, а не як рутинне оновлення пакета.

Чому скрипт-хук насправді довіряє

Хук налаштовується через auth-user-pass-verify і механізм доставки: змінні середовища або тимчасовий файл. У формі середовища OpenVPN вимагає script-security 3 — документований рівень, що дозволяє розкривати пароль скриптам. Цей рівень є навмисним ослабленням типового значення, і до нього слід ставитися як до дозволу з доданим обґрунтуванням.

Усе, чого скрипт торкається, успадковує цю довіру. Він має належати root, не бути записуваним для групи чи інших, зазначатися абсолютним шляхом і не мати місця, де недовірене значення потрапляє в оболонку. Беріть кожну змінну в лапки, відхиляйте неочікувані символи й ніколи не будуйте команду з наданого імені користувача. Скрипт, що працює як root під час кожної спроби входу, вартий одного перегляду саме через ці чотири властивості.

ls -l /usr/local/sbin/radius-auth.sh
stat -c '%U %a' /usr/local/sbin/radius-auth.sh

Форма доставки файлом обходить проблему успадкування середовища й передає облікові дані скрипту через тимчасовий файл з обмеженими правами. Якщо ваш клієнт це підтримує, зазвичай це кращий типовий варіант, хоча додає ще один об'єкт для прибирання в разі збою.

Коди виходу вирішують, чи будете ви збоєм відкритим

Код виходу скрипта — це вердикт: нуль приймає, не-нуль відхиляє. Схема, що створює проблеми, — це shell-скрипт, який приймає лише тоді, коли відповідь RADIUS містить певний токен прийняття, а для всього іншого повертає збій, бо так три різні події зливаються в одну відповідь. Неправильний пароль, недосяжний сервер і викривлена відповідь стають однією й тією ж відмовою.

Розділяйте ці випадки в скрипті, навіть якщо хук уміє повертати лише прийняти чи відхилити. Записуйте результат бекенду окремо, подавайте сигнал про тайм-аути й помилки транспорту і робіть у моніторингу очевидним, коли автентифікація падає через недоступність сервісу, а не через помилки користувачів.

Дві звички зберігають решту розумною. Якщо RADIUS — авторитет, він має бути єдиним місцем перевірки пароля, бо тіньова таблиця створює дві відповіді на одне питання, а друга — поверхня атаки, за якою ніхто не стежить. І пам'ятайте, що хук викликається знову при кожній спробі, тож повільний скрипт із нетерплячим клієнтом стає підсилювачем підбору паролів, якщо не додати затримку або політику на боці RADIUS.

Чим ви жертвуєте, коли сертифікат зникає

Багато розгортань такої форми повністю вимикають перевірку клієнтського сертифіката, залишаючи ім'я користувача й пароль як усе твердження клієнта. Те, що зникає з цим налаштуванням, — ідентичність на основі сертифіката. Канал залишається зашифрованим, але єдине, що називає клієнта, — вердикт RADIUS. Усе нижче за течією, що раніше спиралося на суб'єкт сертифіката, тепер має спиратися на ім'я користувача.

Зберігайте захист керівного каналу, щоб неавтентифікований партнер не міг досліджувати чи заливати рукостискання, і використовуйте username-as-common-name, коли конфігурація для користувача залежить від спільного імені. Керовані шлюзи часто вирішують це інакше, завершуючи автентифікацію сертифікатом на шлюзі, що говорить EAP-TLS з RADIUS, і в такому разі жодна з цих серверних директив не діє. Копіюйте модель, яку документує ваша платформа, а не модель сусіднього продукту. Важливі директиви різняться настільки, що їх змішування дає конфігурацію, яка розбирається і потім нікого не автентифікує.