Які програмні ролі потрібні шлюзу OpenVPN без екрана

Машині, виділеній під шлюз OpenVPN, потрібне підтримуване встановлення сервера й програмне забезпечення для завдань, які вона справді виконує. Меню інсталятора з SSH, веб-хостингом та іншими ролями сервера не є списком вимог OpenVPN. Розгортання без екрана цілком розумне. Головне — розділити три завдання: перенесення тунелю, адміністрування хоста й видавання облікових даних.

Ось порядок інвентаризації, який я використовую, з перевіркою, що закриває кожен крок.

1. Дайте тунельній службі власний пакет і профіль

Посібник з сервера OpenVPN для Ubuntu використовує пакет openvpn дистрибутива з командним рядком і конфігурацією служби. Той самий пакет слугує клієнтом Linux, а роль вибирає конфігурація.

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

2. Визначте шлях адміністрування до тунелю

OpenSSH постачається окремим пакетом openssh-server і працює як власна служба. Він корисний, коли адміністратор має діставатися машини через SSH, але OpenVPN не потребує SSH-сервера для обміну пакетами VPN. Локальна консоль або схвалений канал керування платформою — інший придатний шлях. Вирішіть, на який ви покладаєтеся, перш ніж змінювати маршрутизацію чи фільтрування, бо новий тунель ніколи не повинен бути єдиним неперевіреним способом полагодити себе.

3. Видавайте облікові дані від схваленого власника

Приклад Ubuntu встановлює easy-rsa поруч з OpenVPN, щоб побудувати невеликий PKI, а це роль видавання облікових даних, а не працююча тунельна служба. Якщо в організації вже є схвалений процес видавання, використовуйте його замість створення не пов'язаного CA лише тому, що він є в посібнику. Тримайте власний приватний ключ і сертифікат шлюзу окремо від ключа підпису CA і свідомо вибирайте місце для підпису та резервної копії. Копіювання кожного файлу PKI на кожен хост — не програмна вимога.

4. Залиште настільні плагіни настільним комп'ютерам

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

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

5. Прийміть шлюз справжнім клієнтом

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

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