OPNsense HA Firewall

OPNsense HA разворачивает два межсетевых экрана OPNsense 26.1.9 как активно-пассивную пару в разных зонах доступности с автоматическим переключением и штатной синхронизацией конфигурации. Решение рассчитано на Yandex Cloud, где CARP и pfsync недоступны, и использует управляющий слой облака для перевода трафика на резервный узел при отказе активного.

При загрузке весь трафик обслуживает основной узел. Демон переключения работает на обеих ВМ и определяет свою роль (активная/пассивная) по таблице маршрутизации VPC — единственному источнику истины — переоценивая её каждые
~5 секунд. Пассивный узел в каждом цикле опрашивает активный по двум независимым путям: приватному WAN-адресу внутри VPC и публичному WAN-адресу через интернет.
Цикл засчитывается как отказ только при сбое обоих путей. При устойчивом отказе демон переписывает маршрут по умолчанию на себя; маршрут перемещается только когда активный узел действительно отказал.

Переключение автоматическое и двунаправленное: активный узел остаётся активным, пока не откажет, после чего его подхватывает другой — в любую сторону, поэтому кластер переживает последовательные отказы и после первого не остаётся единой точкой отказа. Возврата на «предпочтительный» узел нет, что вместе с паузой после переключения (cooldown) исключает «дребезг».
Детекция построена так, чтобы переключаться по правильным причинам и только по ним:

• Проба с привязкой к идентичности. Проба обращается к health-эндпоинту демона (TCP 8443), который отдаётся собственным сертификатом каждого узла, и проверяет отпечаток сертификата соседа (SHA-256). Чужак, попавший на переназначенный эфемерный публичный IP, не может выдать себя за соседа и скрыть реальный отказ.
• Готовность с учётом плоскости данных. Health-эндпоинт сообщает «здоров» только когда WAN-шлюз самого узла достижим, поэтому переключение происходит по условию «активный больше не может пересылать трафик наверх», а не по включённому, но бесполезному узлу.
• Защита от split-brain. Разрыв связи между узлами в VPC рвёт приватный путь, но не публичный, поэтому разделённый, но живой активный узел остаётся наблюдаемым и не подхватывается.
• Асимметричные пороги против «дребезга». Пропавший узел переключается быстро (~15-20 секунд от начала до конца); достижимый, но деградировавший узел переключается медленнее (~25-35 секунд), чтобы гасить кратковременные сигналы.

Конфигурация синхронизируется с основного узла на резервный штатным механизмом OPNsense XMLRPC поверх HTTPS (TCP 443), поэтому правила межсетевого экрана, NAT,
VPN и другие настройки, сделанные на основном узле, автоматически переносятся на резервный.

Ключевые возможности

• Активно-пассивная пара OPNsense 26.1.9 в двух зонах доступности.
• Автоматическое двунаправленное переключение через обновление next-hop в таблице маршрутизации VPC — переживает последовательные отказы любого узла.
• Штатная синхронизация конфигурации через XMLRPC поверх HTTPS — правила, NAT и VPN настраиваются только на основном узле, резервный получает их автоматически.
• Симметричный демон переключения на обеих ВМ; пассивный узел опрашивает активный по двум независимым путям (приватный VPC + публичный) и переключается только при отказе обоих, что не даёт сетевому разделению вызвать ложное переключение (защита от split-brain).
• Детекция с учётом плоскости данных: опрашиваемый health-эндпоинт (TCP 8443) сообщает «здоров» только когда узел достигает собственный WAN-шлюз, поэтому переключение следует за потерей пересылки наверх, а не за потерей питания.
• Проба с привязкой к сертификату (отпечаток SHA-256): переназначенный эфемерный публичный IP не может выдать себя за соседа и скрыть реальный отказ.
• Асимметричные пороги: пропавший узел переключается быстро (~15-20 секунд), деградировавший, но достижимый — медленнее (~25-35 секунд), чтобы гасить кратковременные сигналы.
• Полный набор возможностей OPNsense: VPN (OpenVPN, IPsec), IDS/IPS (Suricata), WireGuard, веб-фильтрация и прокси, большая экосистема плагинов. Базовый образ содержит стандартный набор пакетов OPNsense; дополнительные плагины, такие как Suricata и WireGuard, устанавливаются по требованию из каталога OPNsense через WAN-подключение.
• Гибридный outbound-NAT с ручными правилами для RFC1918-источников; one-armed NAT для маршрутизированного трафика рабочих нагрузок на WAN.
• Без SDK и файлов ключей сервисного аккаунта: демон использует IAM-токены из сервиса метаданных инстанса.
• Сервисный аккаунт с минимальными правами (только три роли IAM).
• Полностью автономная загрузка

Что создать перед развёртыванием

Продукт создаёт и управляет только парой межсетевых экранов (две ВМ, сервисный аккаунт, группа безопасности и общий секрет-конфиг в Lockbox). Перечисленные ниже ресурсы он намеренно не создаёт: они долгоживущие, общие или чувствительные к безопасности, вы сами управляете их именованием и жизненным циклом, а таблица маршрутизации должна уже существовать, чтобы межсетевой экран встроился в вашу сеть. Создайте их заранее и передайте их ID в форму:

• Секрет Lockbox с паролем admin — оба узла аутентифицируются друг к другу по OPNsense XMLRPC, и вторичный узел читает пароль при загрузке. Он хранится в Lockbox, чтобы пароль не попадал в метаданные ВМ и в логи. Вы создаёте его сами, потому что сами выбираете пароль. См. «Создание секрета с паролем admin» ниже.
• Открытый SSH-ключ для пользователя freebsd — аварийный доступ для отладки; форма прописывает ваш ключ на обе ВМ. Настройка SSH выполняется в самом начале bootstrap, чтобы до узла можно было достучаться, даже если последующие шаги завершатся с ошибкой.
• Таблица маршрутизации VPC — это и есть механизм failover. При переключении демон переписывает next-hop маршрута 0.0.0.0/0 на WAN приватный IP выжившего узла (ваши статические маршруты сохраняются). Таблица должна уже существовать и быть привязана к LAN-подсетям, трафик которых маршрутизируют экраны; продукт только обновляет её.
• Две WAN-подсети в разных зонах доступности с включённым NAT — узлы работают в разных зонах ради устойчивости к отказу зоны, поэтому каждому нужна своя WAN-подсеть. NAT обеспечивает исходящий доступ и связь с control plane Yandex Cloud (API Lockbox, VPC), к которым обращается демон. Обе подсети должны быть в той же VPC-сети, что и таблица маршрутизации.

Создание секрета с паролем admin

Секрет Lockbox должен содержать одну текстовую запись с ключом ровно password и значением — паролем администратора в открытом виде (применяется к учётной записи root OPNsense). Создайте его через CLI Yandex Cloud:

yc lockbox secret create \
  --name opnsense-admin-password \
  --payload '[{"key":"password","text_value":"<пароль-admin>"}]'

В консоли: Lockbox -> Создать секрет -> добавьте запись «ключ/значение» с ключом password и паролем в значении. Скопируйте полученный ID секрета в параметр admin_password_secret_id. Имя ключа должно быть именно password — bootstrap читает ровно этот ключ и завершится с ошибкой, если его нет. Продукт не форсирует минимальную длину, поэтому выберите надёжный пароль.

Параметры развёртывания

Поля, отображаемые в форме развёртывания:

• Имя — префикс имён всех создаваемых ресурсов.
• WAN-подсеть (первая зона доступности) — VPC-подсеть как WAN первого узла для управления и выхода в интернет через NAT.
• WAN-подсеть (вторая зона доступности) — VPC-подсеть как WAN второго узла (другая зона доступности).
• Таблица маршрутизации — VPC route table, next-hop 0.0.0.0/0 которой демон переключает между узлами при failover.
• Секрет с паролем admin — секрет Lockbox с паролем администратора OPNsense (учётная запись root).
• Публичный SSH-ключ (пользователь FreeBSD) — ключ, прописываемый на обе ВМ для аварийного доступа.
• Тип окружения — тип окружения развёртывания (prod / dev)

Входящий трафик открыт на 0.0.0.0/0 по TCP 22 (SSH, только по ключу — парольная аутентификация отключена), TCP 443(WebUI HTTPS; 443 также несёт XMLRPC-синхронизацию конфигурации), TCP 8443 (health-эндпоинт HA-демона, который сосед опрашивает по приватному и публичному путям — он отдаёт только булев флаг 200/503 по TLS-эндпоинту с привязкой к сертификату, без чувствительных данных) и ICMP. Кроме того, разрешены все протоколы из диапазонов
RFC1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), чтобы firewall мог маршрутизировать и NAT’ить ваши LAN-нагрузки. При необходимости ограничьте доступ на уровне группы безопасности или подсети.

Замечание по безопасности (порт 8443): порт 8443 доступен из интернета — это обязательно, так как проверка на split-brain выполняется через публичный IP узла-соседа по сети интернет. Эндпоинт отдаёт только логическое значение готовности (200/503) поверх TLS и не раскрывает иных данных. Рекомендуется применять ограничение частоты запросов и защиту от SYN-флуда, а также по возможности ограничивать доступ к порту 8443 на границе сети (доверенными CIDR).

Доступ к WebUI

После завершения развёртывания (~3-4 минуты):

1. Откройте консоль Yandex Cloud, перейдите в Compute Cloud.
2. Найдите ВМ primary и скопируйте публичный IP-адрес.
3. Откройте https://<primary-ip> в браузере, примите предупреждение о самоподписанном сертификате.
4. Войдите под пользователем root (учётная запись администратора OPNsense) с паролем из секрета Lockbox.

Все изменения конфигурации выполняйте только на primary. Конфигурация автоматически синхронизируется на secondary через XMLRPC.

Маршрутизация LAN-нагрузок через firewall

Пара firewall маршрутизирует и NAT’ит трафик ваших LAN-подсетей. Само развёртывание не привязывает таблицу маршрутизации ни к одной подсети — это нужно сделать вручную, иначе трафик не пойдёт через OPNsense.

Обязательные шаги:

1. Привяжите таблицу маршрутизации к каждой LAN-подсети. route_table_id, переданный при деплое, несёт маршрут по умолчанию (0.0.0.0/0), который демон переключает между основным и резервным узлом. LAN-подсеть начинает ходить через firewall только после ассоциации с этой таблицей:

   yc vpc subnet update <LAN_SUBNET_ID> --route-table-id <route_table_id>
   

Без этого LAN-VM обходят firewall (или остаются без выхода в интернет). Маршрут по умолчанию устанавливается демоном failover автоматически после загрузки.
2. Используйте диапазоны RFC1918 (10.0.0.0/8, 172.16.0.0/12,192.168.0.0/16). Outbound-NAT и группа безопасности firewall настроены под эти диапазоны; другие не NAT’ятся и не пропускаются.
3. Не назначайте публичные IP на LAN-VM. Их единственный путь наружу — через таблицу маршрутизации на OPNsense; публичный IP на LAN-VM вызывает асимметрию (входящий через свой NAT, исходящий через OPNsense) и ломает соединения.
4. LAN-подсети должны быть в той же VPC-сети, что и WAN firewall.

Таблицу маршрутизации HA необходимо привязывать к LAN/рабочим подсетям и НИКОГДА к WAN-подсети: маршрут по умолчанию на WAN-подсети направит шлюз узла на самого
себя и заблокирует собственный исходящий трафик узла (SSH, Lockbox, YC API).

• Создание VPN-соединения для удаленного доступа к ресурсам или для связи физической и облачной инфраструктуры.
• Защита сервисов и приложений.
• Трансляция адресов.
• Фильтрация трафика.
• Маршрутизация в интернете.

OpenNix осуществляет техническую поддержку пользователей OPNsense в Yandex Cloud. Вы можете связаться с технической поддержкой по электронной почте support@opennix.ru. Время работы технической поддержки с 9:00 до 18:00 (МСК) по рабочим дням.