pfSense як VPN-сервер і клієнт: два шляхи, один маршрутизатор

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

Назвіть дві ролі, перш ніж торкатися будь-якого налаштування

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

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

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

Тримайте відповіді сервера на шляху WAN

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

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

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

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

Не дозволяйте вихідному тунелю з'їсти власну кінцеву точку

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

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

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

Виберіть, які користувачі отримають вихід

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

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

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

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

Вирішіть, що станеться, коли вихід відмовить

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

Вимкніть примірник клієнта, подивіться, до чого підключений користувач ще дістається, потім запустіть його знову. Запит, що вичерпує час, — це результат повного блокування, який ви просили; той, що відповідає адресою WAN, — це повернення, яке ви не задокументували. Повторіть перевірку для IPv6 і для DNS, бо політика, написана для IPv4, нічого не каже про трафік AAAA, а резолвер, просунутий будь-яким тунелем, відповідає звідти, звідки запит справді виходить.

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

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