Інструкція: окреме підключення двох клієнтів OpenVPN

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

Призначте кожному клієнту повну картку ресурсів

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

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

Тримайте матеріал довіри всередині кожного клієнта

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

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

Розділіть мережі так само, як процеси

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

ss -lunp | grep -E '1194|1195'
openssl verify -CAfile customer-a/ca.crt customer-a/client.pem

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

Доставте відкликання до передачі

Розгортання сертифікатів не завершене, доки відкликання не має шляху доставки. Перевірте видавця CRL і вікно чинності як частину підключення.

openssl crl -in customer-a/crl.pem -noout -lastupdate -nextupdate
systemctl status openvpn@customer-a

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

Потім запустіть приймальну пару: дозволений клієнт досягає своєї служби, а облікові дані A відхиляються слухачем B. Це межа, виражена як тест.