Чи може з’єднання OpenVPN зі статичним ключем обслуговувати кількох клієнтів?

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

Два вузли, один ключ і жодного стану на клієнта: ця форма — уся історія режиму.

Для чого потрібен режим статичного ключа

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

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

Тому обмеження у два вузли структурне, а не налаштування, яке можна змінити.

Чому client-to-client не є відсутньою частиною

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

Інша поширена плутанина стосується матеріалу tls-crypt або tls-auth. Сервер TLS може спільно використовувати один із цих ключів для всіх клієнтів, бо він захищає канал керування, а не доводить, хто є кожен клієнт. Спільний ключ каналу керування в режимі TLS — це інший об’єкт, ніж спільний статичний ключ даних, хоча обидва надходять як схожі на вигляд файли.

Вибір між режимами зводиться до двох питань. Чи має більше ніж один пристрій підключатися незалежно, і чи потрібне розгортанню відкликання для кожного пристрою? Ні на обидва залишає режим статичного ключа життєздатним; так на будь-яке з них указує на TLS. Немає третього варіанта, де другий клієнт допускається без власної ідентичності.

Побудова сервера для кількох клієнтів

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

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

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

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

Перевірка того, що клієнти справді незалежні

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

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

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

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