OpenVPN без клієнтського сертифіката: політика сервера, а не профіль

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

Профіль — це не політика

Community OpenVPN 2.6 постачається з обов'язковими клієнтськими сертифікатами, бо verify-client-cert за замовчуванням дорівнює require. Саме встановлення none припиняє вимогу сертифіката й передає автентифікацію клієнта тій схемі з іменем користувача й паролем, яку сервер уже застосовує. Старі посібники тягнуться до client-cert-not-required, застарілого написання тієї самої ідеї, тож використовуйте директиву, яку документує встановлена версія. У будь-якому разі зміна відбувається на сервері, і жоден клієнтський профіль не може її виконати.

Фрагмент нижче — це вся зміна на боці сервера, і сам по собі він не є робочою конфігурацією автентифікації. verify-client-cert none прибирає вимогу сертифіката, а username-as-common-name робить ім'я облікового запису тим ідентифікатором, який бачать пізніші зворотні виклики й файли окремого клієнта. Жоден рядок не перевіряє пароль, тому верифікатор усе одно має існувати.

verify-client-cert none
username-as-common-name

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

Що досі перевіряє сервер

Відмова від клієнтського сертифіката не означає відмови від TLS. Сервер зберігає свій сертифікат і ключ, а клієнт зберігає довіру до CA й перевірки імені хоста, які не дають йому говорити з самозванцем. Видалення remote-cert-tls server або пакета CA через те, що клієнт більше не має сертифіката, — часте й серйозне хибне прочитання, і довідка 2.6 прямо каже, що два напрямки незалежні. Одне доводить сервер клієнтові; інше доводить клієнта серверові.

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

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

Що має робити верифікатор

Після зняття вимоги сертифіката все тримається на верифікаторі: плагіні або скрипті, яким керує auth-user-pass-verify. Він має відхиляти недійсні облікові дані, відхиляти вимкнені або невідповідні облікові записи й відмовляти закрито, коли не може досягти свого бекенду. username-as-common-name часто вмикають поруч, і він змінює ідентифікатор, який бачать пізніші зворотні виклики й файли конфігурації окремого клієнта. Він не перевіряє пароль і не робить невідповідний обліковий запис відповідним. Це різні завдання, і їх змішування — це шлях, яким міграція проходить тест щасливого шляху й зазнає невдачі на першому реальному інциденті.

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

Змінюйте політику, профіль і зіставлення разом

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

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

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