Куди потрапляє код статичного виклику під час входу в OpenVPN

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

Почніть із запрошення, яке ваш клієнт справді показує

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

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

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

Що сервер має вже підтримувати

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

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

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

Кодоване поле, яке надсилає інтерфейс керування

Коли інтерфейс керує з'єднанням через інтерфейс керування, пароль і відповідь на виклик пакуються в одне значення перед надсиланням. Довідник з інтерфейсу керування описує формат: префікс, потім пароль і відповідь як окремі компоненти Base64.

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

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

Статичний проти динамічного: різний час

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

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

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

Перевіряйте і успіх, і невдачу, а не лише діалог

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

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