Чому редагування файлу .ovpn не вмикає MFA на сервері

Ви додаєте auth-user-pass до профілю, перепідключаєтеся, і клієнт запитує ім’я користувача та пароль. Здається, що MFA увімкнено. Потім ви вводите код із чужого облікового запису або код, термін дії якого минув десять хвилин тому, а тунель усе одно піднімається. Ось симптом: клієнт змінився, сервер — ні. Одноразовий пароль є фактором лише тоді, коли перевіряч на сервері вирішує, чи дійсний він для тієї особи, яка його вимагає.

Запит доводить лише те, що клієнт запитав, і нічого більше

Файл .ovpn — документ на боці клієнта. Він може наказати клієнтові запитувати облікові дані, кешувати їх або припинити це робити. Він не може зареєструвати користувача, встановити модуль PAM чи змусити сервер вимагати другий фактор, який той зараз не перевіряє.

Встановлення застосунку-автентифікатора на телефон також не створює цього зв’язку. Проєкт Google Authenticator PAM — це компонент перевірки OTP, який може стояти за OpenVPN; це не спосіб приклеїти вхід до акаунта Google до імпортованого профілю.

Реєстрація — це та частина, яку профіль виконати не може

TOTP потребує реєстраційного матеріалу, спільного для застосунку-автентифікатора та його перевіряча. Шість цифр на телефоні — це вихід; зерно за ними — це секрет, і воно належить одній особі.

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

Архітектура на основі PAM не зобов’язана створювати окремий обліковий запис Unix для кожного користувача VPN. Документація модуля підтримує альтернативні шляхи до секретів і окремий обліковий запис для доступу до файлів, тобто ідентичність файлової системи, а не ідентичність входу, яка перевіряється.

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

Прочитайте стек PAM, щоб побачити, що насправді потрібно

Рядок на кшталт account required pam_permit.so не реалізує право доступу до облікового запису й не додає фактор. Він дозволяє цей етап керування обліковими записами PAM, що є твердженням про етап, а не про ваших користувачів.

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

Узгодьте взаємодію клієнта з архітектурою сервера

auth-user-pass

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

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

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

Перепідключення, токени й тест, який усе вирішує

Плануйте, що відбувається після першого успішного входу. Раніше прийнятий код може прострочитися або бути відхиленим як повторення під час наступної автентифікації. auth-nocache керує збереженням облікових даних і не встановлює MFA, а reneg-sec 0 не є визначенням підтримки TOTP, хоч би як часто він з’являвся в темах форумів.

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

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