RouterOS OpenVPN і NPS: задайте user-auth-method, а не auth

У RouterOS auth вибирає дайджест тунелю, а user-auth-method вирішує, як перевіряється запит RADIUS. Узгодьте другий параметр із політикою NPS.

RouterOS може доходити до NPS із входом OpenVPN і все одно отримувати відмову, і звичайна причина — два параметри, назви яких обидві звучать як автентифікація. Один вибирає криптографічний дайджест для тунелю; інший вирішує, як облікові дані користувача передаються до RADIUS. Зміна дайджесту ніколи не перетворить запит PAP на MS-CHAPv2, скільки б разів служба не перезапускалася. Наведений нижче контрольний список розділяє ці два, а потім простежує один невдалий вхід через політику NPS, яка його оцінила.

Крок 1: прочитайте обидва параметри, перш ніж змінювати будь-який

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

/interface ovpn-server server print
/interface ovpn-server server export

Поле auth перелічує дайджести, як-от sha1 і sha256, і керує HMAC, що автентифікує пакети тунелю. Поле user-auth-method вибирає pap або mschap2 і вирішує, як маршрутизатор передає облікові дані користувача до RADIUS. Зміна дайджесту не може змінити другу поведінку, тому та сама відмова зберігається після кожного коригування першого.

Зупиніться тут, якщо ваш випуск узагалі не надає user-auth-method. Старіші збірки RouterOS можуть не пропонувати його на сервері OpenVPN, і виправлення належить випуску, який ви можете підтримувати, а не команді, скопійованій із новішого.

Крок 2: знайдіть політику, яка справді відхилила вхід

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

Get-WinEvent -LogName Security -MaxEvents 200 |
  Where-Object { $_.Id -in 6272,6273 } |
  Format-List TimeCreated,Id,Message

Прочитайте в події три речі: назву відповідної політики, метод автентифікації та код причини. Політика, що вимагає MS-CHAPv2, відхиляє запит PAP навіть за правильного пароля, а політика, що вимагає облікового запису домену, відхиляє локальний. Запис клієнта RADIUS також має збігатися з адресою джерела маршрутизатора, інакше запит відкидається ще до звернення до будь-якої політики. Нічого з цього не з'являється в журналі OpenVPN.

Зупиніться тут, якщо запит так і не доходить до NPS. Це проблема спільного секрету, адреси клієнта або UDP 1812, і зміна методів автентифікації її не виправить.

Крок 3: змініть один метод з обох боків

Якщо затверджений проєкт — MS-CHAPv2, задайте його на маршрутизаторі й підтвердьте, що відповідна політика його приймає. Змініть один бік, повторіть тест, потім змініть інший; зміна обох одразу не дасть змоги сказати, який мав значення.

/interface ovpn-server server set user-auth-method=mschap2
/interface ovpn-server server print
/log print where topics~"radius"

Не вмикайте на NPS усі слабші методи, щоб помилка зникла. Внутрішня система повинна мати матеріал, який обраний метод може перевірити: MS-CHAPv2 потребує доступу до пароля або домену, а політика не може вигадати цей матеріал. Розширення політики розширює й те, що зловмисник може спробувати проти того самого облікового запису. Запишіть метод, назву політики й посилання на зміну разом, щоб наступна людина успадкувала рішення, а не здогад.

Залиште перевірку сертифіката тунелю точно такою, якою вона була. Метод облікових даних не замінює ідентичність сервера, а зниження перевірок TLS заради проходження тесту міняє одну проблему на гіршу.

Крок 4: перевірте три входи й один дозвіл

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

/log print where topics~"ovpn"
/radius monitor 0

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

Контрольний список завершено, коли налаштування маршрутизатора й політика NPS називають один і той самий метод, дозволений користувач підключається в новій сесії, неправильний пароль відхиляється, виключений користувач залишається виключеним, а призначена адреса відповідає передбаченому пулу. Усе менше залишає наступний вхід на волю випадку.

Схожі статті