Client Export проти вихідного екземпляра OpenVPN на pfSense

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

Вирішіть, хто починає, перш ніж щось встановлювати

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

Якщо pfSense підключається до чужої служби VPN, міжмережевий екран є клієнтом, а віддалений оператор володіє кінцевою точкою, до якої ви підключаєтеся.

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

Експортер — це помічник на боці сервера

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

Саме тому список показує лише сервери в режимі Remote Access. Без такого сервера нема чого експортувати, і порожній список — це точний звіт, а не несправність. Спершу створіть сервер віддаленого доступу, і список заповниться сам. Цей порядок плутає людей частіше, ніж будь-яке налаштування всередині пакета.

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

Вихідний екземпляр — це окрема конфігурація

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

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

Тримайте дві конфігурації в окремих уявних коробках. Одна відповідає іншим пристроям; інша просить тунель в іншого сервера.

Виберіть формат експорту, який пристрій може використати

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

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

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

Site-to-site потребує ролей і маршрутів, а не пакета

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

Client Export не має думки про маршрути філії, дозвіл на пересилання чи зворотний шлях, бо підготовка матеріалу клієнта віддаленого доступу — уся його робота.

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