OpenVPN Site-to-Site туннель в pfSense - настройка

OpenVPN site-to-site туннель обеспечивает постоянное зашифрованное соединение между двумя или более площадками, объединяя их локальные сети в единое адресное пространство. В отличие от IPsec, OpenVPN работает в пространстве пользователя поверх SSL/TLS и способен функционировать через TCP 443, что делает его предпочтительным вариантом при работе через сети с жёсткой фильтрацией (корпоративные прокси, гостиничный Wi-Fi, мобильные операторы, блокирующие ESP/IKE).

Данное руководство описывает два режима настройки site-to-site туннеля в pfSense: упрощённый Shared Key и масштабируемый TLS/PKI. Материал рассчитан на сетевых инженеров, имеющих опыт администрирования pfSense и понимание основ маршрутизации.

Когда выбрать OpenVPN вместо IPsec

Выбор между OpenVPN и IPsec для site-to-site соединений зависит от конкретных условий эксплуатации.

Рекомендация: при подключении площадок через ограничительные сети или при отсутствии совместимого IPsec-оборудования на удалённой стороне следует использовать OpenVPN. При необходимости максимальной производительности и совместимости с оборудованием третьих сторон - IPsec site-to-site .

Предварительные требования

Перед настройкой необходимо убедиться в выполнении следующих условий:

1. Публичные IP-адреса или Dynamic DNS на обоих узлах. Минимум одна сторона должна иметь статический адрес или FQDN, доступный из интернета.
2. Непересекающиеся подсети за обоими узлами:
   • Площадка A (сервер): LAN 10.1.0.0/24
   • Площадка B (клиент): LAN 10.2.0.0/24
   • Tunnel Network: 10.8.1.0/30 (для point-to-point достаточно /30)
3. Согласованные параметры - обе стороны должны использовать одинаковые алгоритмы шифрования и протокол (UDP/TCP).

Shared Key режим

Режим Shared Key (Pre-Shared Key) - простейший способ организации site-to-site туннеля между двумя площадками. Вместо PKI-инфраструктуры используется один статический ключ, известный обеим сторонам.

Внимание:

Разработчики OpenVPN объявили режим Shared Key устаревшим. В будущих версиях OpenVPN он будет удалён. Для новых инсталляций рекомендуется использовать TLS/PKI режим.

Ограничения Shared Key

• Поддерживает только одно соединение peer-to-peer (два узла).
• Не масштабируется - для каждой пары площадок необходим отдельный экземпляр с уникальным портом.
• Компрометация ключа ставит под угрозу весь туннель.
• Нет Perfect Forward Secrecy (PFS).
• Несовместим с DCO (Data Channel Offload).

Настройка серверной стороны (Площадка A)

Конфигурация выполняется в разделе VPN > OpenVPN > Servers.

Рис. 1. Список OpenVPN-серверов в pfSense

1. Нажать Add для создания нового сервера.
2. Заполнить параметры:

3. Нажать Save.
4. После сохранения открыть сервер повторно и скопировать содержимое поля Shared Key - оно потребуется для настройки клиентской стороны.

Настройка клиентской стороны (Площадка B)

На pfSense площадки B перейти в VPN > OpenVPN > Clients и нажать Add.

Внимание:

Все криптографические параметры (алгоритмы шифрования, HMAC, Shared Key) должны быть идентичны на обеих сторонах. Несовпадение приведёт к отказу в установлении туннеля без информативного сообщения об ошибке.

TLS/PKI режим

Режим TLS/PKI (Peer to Peer SSL/TLS) использует сертификаты X.509 для аутентификации и обеспечивает масштабируемость, Perfect Forward Secrecy и совместимость с DCO. Это рекомендуемый режим для новых инсталляций.

Подготовка сертификатов

Требуется создать:

1. CA - в разделе System > Certificates > Authorities (если CA ещё не создан).
2. Серверный сертификат - тип Server Certificate, привязанный к CA.
3. Клиентский сертификат - тип User Certificate для каждой удалённой площадки. Создаётся в System > Certificates > Certificates (не через User Manager, поскольку site-to-site не требует учётных записей пользователей).

Подробная инструкция по созданию сертификатов приведена в разделе OpenVPN сервер удаленного доступа .

Настройка серверной стороны

Конфигурация выполняется в разделе VPN > OpenVPN > Servers.

Для режима TLS с несколькими клиентами (hub-and-spoke) поле IPv4 Remote Network(s) заполняется подсетями всех удалённых площадок через запятую.

Настройка клиентской стороны

На pfSense удалённой площадки: VPN > OpenVPN > Clients > Add.

Маршрутизация

Корректная маршрутизация - ключевой элемент работающего site-to-site туннеля. OpenVPN использует два механизма передачи информации о маршрутах.

Поле Remote Network(s) vs iroute

• IPv4 Remote Network(s) в настройках сервера - создаёт маршрут на уровне операционной системы, указывающий, что трафик к указанным подсетям следует направлять в OpenVPN-интерфейс.
• iroute в Client Specific Overrides - сообщает процессу OpenVPN, какой клиент обслуживает конкретную подсеть. Без iroute OpenVPN не знает, через какое туннельное соединение отправлять пакеты.

В режиме TLS с несколькими клиентами необходимо настроить оба механизма:

1. В настройках сервера указать все удалённые подсети в IPv4 Remote Network(s).
2. Для каждого клиента создать запись в Client Specific Overrides с директивой iroute:

iroute 10.2.0.0 255.255.255.0;

В режиме Shared Key iroute не используется - маршрутизация определяется полем Remote Network(s) на обеих сторонах.

Статические маршруты на внутренних устройствах

Устройства в локальных сетях обеих площадок должны иметь маршрут к подсетям удалённой стороны через pfSense. Если pfSense является шлюзом по умолчанию, маршруты создаются автоматически. В противном случае необходимо добавить статические маршруты на маршрутизаторах или L3-коммутаторах.

Multi-site hub-and-spoke

Топология hub-and-spoke позволяет подключить несколько удалённых площадок (spoke) к центральному офису (hub) через единый экземпляр OpenVPN-сервера в режиме TLS/PKI.

Архитектура

          ┌──────────────┐
          │   Hub (HQ)   │
          │  10.1.0.0/24 │
          │  OpenVPN     │
          │  Server      │
          └──────┬───────┘
                 │
        ┌────────┼────────┐
        │        │        │
   ┌────▼───┐ ┌──▼────┐ ┌─▼──────┐
   │ Spoke1 │ │ Spoke2│ │ Spoke3 │
   │10.2.0/24│ │10.3.0/24│ │10.4.0/24│
   └────────┘ └───────┘ └────────┘

Настройка Hub

На центральном pfSense создаётся один сервер OpenVPN в режиме Peer to Peer (SSL/TLS) с параметрами:

• IPv4 Tunnel Network: 10.8.1.0/24 - достаточно для адресации всех spoke.
• IPv4 Remote Network(s): 10.2.0.0/24, 10.3.0.0/24, 10.4.0.0/24 - все подсети spoke.

Для каждого spoke создаётся запись в Client Specific Overrides:

Spoke 1 (Common Name: spoke1-cert):

iroute 10.2.0.0 255.255.255.0;

Spoke 2 (Common Name: spoke2-cert):

iroute 10.3.0.0 255.255.255.0;

Spoke 3 (Common Name: spoke3-cert):

iroute 10.4.0.0 255.255.255.0;

Взаимодействие между spoke

По умолчанию spoke-площадки не могут взаимодействовать напрямую - весь трафик проходит через hub. Для этого необходимо:

1. Включить опцию Inter-client communication на сервере (или добавить client-to-client в Custom options).
2. На каждом spoke добавить маршруты к подсетям других spoke через VPN (поле IPv4 Remote Network(s)).

Правила файрвола

Правила на WAN

Аналогично серверу Remote Access - разрешить входящие подключения на порт сервера:

При известном фиксированном IP удалённой площадки рекомендуется указать его в поле Source для ограничения поверхности атаки.

Правила на интерфейсе OpenVPN

Разрешить трафик между подсетями площадок:

Для ограничения доступа следует создать правила, разрешающие только необходимые протоколы и порты. Подробнее - в разделе Правила файрвола в pfSense .

Сравнение с IPsec

Выбор между OpenVPN и IPsec site-to-site зависит от конкретного сценария.

Когда OpenVPN предпочтительнее

• NAT-проблемы - удалённая площадка находится за двойным NAT, или провайдер блокирует протокол ESP.
• TCP-фолбэк - необходимость работы через TCP 443 при блокировке UDP.
• Простота настройки - Shared Key режим требует минимального количества параметров.
• Однородное оборудование - на обеих сторонах установлен pfSense или другая система с поддержкой OpenVPN.
• Динамические IP - OpenVPN корректно работает при смене IP-адресов с обеих сторон (при использовании DDNS).

Когда IPsec предпочтительнее

• Производительность - IPsec обрабатывается на уровне ядра с аппаратным ускорением (AES-NI). Для каналов свыше 500 Mbit/s IPsec значительно эффективнее.
• Совместимость - подключение к оборудованию третьих сторон (Cisco, Juniper, облачные провайдеры), не поддерживающему OpenVPN.
• Стандартизация - корпоративные политики могут требовать использования стандартизированных протоколов (IKEv2, ESP).
• Mesh-топология - IPsec с VTI обеспечивает более гибкую маршрутизацию между множеством площадок.

Подробнее о настройке IPsec - в разделе IPsec Site-to-Site VPN .

Устранение неполадок

Туннель поднялся, но трафик не проходит

1. Проверить маршруты - на обеих сторонах выполнить Diagnostics > Routes и убедиться в наличии маршрутов к удалённым подсетям через OpenVPN-интерфейс.
2. Проверить iroute - в режиме TLS с несколькими клиентами убедиться, что для каждого клиента настроена директива iroute в Client Specific Overrides.
3. Проверить правила файрвола - на интерфейсе OpenVPN должны присутствовать правила, разрешающие трафик из удалённой подсети.
4. Проверить обратную маршрутизацию - устройства на удалённой площадке должны иметь маршрут обратно к локальной подсети через pfSense.

Туннель не устанавливается

1. Проверить логи OpenVPN - Status > System Logs > OpenVPN на обеих сторонах.
2. Убедиться в доступности порта - Diagnostics > Packet Capture на WAN, фильтр по порту сервера.
3. Проверить совпадение параметров - алгоритмы шифрования, HMAC, протокол, tunnel network должны быть идентичны.
4. Проверить сертификаты (режим TLS) - оба сертификата должны быть подписаны одним CA, сроки действия не истекли.
5. Проверить Shared Key (режим PSK) - ключ должен быть скопирован полностью, без пробелов в начале/конце.

Проблемы с MTU

Симптомы: мелкие пакеты (ping, DNS) проходят, крупные (HTTP, SMB) - нет. Решение:

1. Добавить в Custom options на обеих сторонах:

fragment 1400;
mssfix 1400;

2. Если туннель проходит через сети с пониженным MTU (PPPoE, MPLS), уменьшить значение до 1300.
3. Альтернативно - установить MSS Clamping в правилах файрвола pfSense.

Периодические разрывы соединения

1. Проверить keepalive - убедиться, что параметры ping/ping-restart согласованы на обеих сторонах. Рекомендуемые значения: ping 10; ping-restart 60.
2. Проверить rekeying - если при смене ключей туннель разрывается, увеличить reneg-sec или убедиться, что обе стороны поддерживают одинаковые алгоритмы.
3. Проверить ISP - некоторые провайдеры сбрасывают долгоживущие UDP-сессии. Переключение на TCP может решить проблему.

Связанные разделы

• OpenVPN сервер удалённого доступа - настройка OpenVPN для подключения удалённых сотрудников
• Экспорт клиентских конфигураций - генерация конфигурационных файлов через пакет openvpn-client-export
• IPsec Site-to-Site VPN - альтернативный вариант site-to-site через IPsec
• Правила файрвола в pfSense - управление правилами для VPN-трафика