Чому копіювання конфігурації сервера OpenVPN у філію не працює

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

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

Дві ролі, які виглядають як один файл

У режимі TLS дві сторони мають взаємодоповнювальні завдання. Одна сторона слухає, тримає сертифікат і ключ сервера та вирішує, які клієнти можуть підключатися. Інша сторона ініціює, перевіряє слухача і пред'являє власну ідентичність.

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

Закритий ключ — найважливіша частина. Клієнт ніколи не повинен носити закритий ключ сервера, і ключ підпису CA йому теж не потрібен. Сертифікат CA — публічний матеріал довіри; ключ підпису належить туди, де видаються сертифікати.

Що має містити профіль філії

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

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

Будьте обережні з робочими процесами пристроїв. Пакет Client Export у pfSense створює профілі для відповідних контекстів Remote Access, і його список серверів включає лише сервери, налаштовані в режимі Remote Access. Сервер «майданчик—майданчик» іншого режиму не з'являється, і ця відсутність — інформація, а не запрошення копіювати секрети сервера.

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

Зв'язка партнера з мережею окрема

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

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

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

Довести, що філія — той партнер, про якого ви думаєте

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

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

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

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