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 и не раскрывает иных данных. Поставляемый набор правил уже ограничивает эту экспозицию лимитами состояний на источник для порта 8443 (не более 20 одновременных соединений и 60 новых соединений в минуту с одного адреса; превысивший порог источник попадает в таблицу перегрузки, его состояния сбрасываются), что оставляет большой запас для одной пробы соседа раз в 5 секунд. Дополнительно рекомендуется ограничивать доступ к порту 8443 на границе сети (доверенными CIDR), если публичный адрес соседа известен и постоянен.

Доступ к WebUI

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

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

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

Обновление приложения

Обновление приложения Cloud Apps пересоздаёт обе ВМ: существующие инстансы удаляются, новые создаются из текущего образа (бакет с резервными копиями конфигурации при обновлении сохраняется). Разделы конфигурации оператора — правила межсетевого экрана, NAT, алиасы, статические маршруты, VPN, DHCP, DNS и подобные — непрерывно сохраняются в зашифрованное объектное хранилище и автоматически восстанавливаются на новый основной узел, однако идентичность узла, сертификаты, учётные данные и состояние времени выполнения генерируются для каждого узла заново и не восстанавливаются. Всегда выгружайте полную резервную копию конфигурации из WebUI OPNsense перед каждым обновлением, чтобы при необходимости вручную восстановить всё, что вне автоматически восстанавливаемых разделов.

Маршрутизация 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).

Что получаете:

• LAN-VM выходят в интернет через OPNsense, NAT’ясь публичным WAN-адресом
  активного узла. При failover таблица переключается на выживший узел, и новые
  соединения идут через него автоматически.
• OPNsense фильтрует и NAT’ит трафик — это полноценный firewall в разрыве, с
  доступными VPN, IDS/IPS и полным набором плагинов.

Для входящих сервисов, опубликованных на LAN-VM, добавьте правило port-forward /
1:1 NAT на публичный WAN-IP экрана; таблица маршрутизации покрывает только
исходящий и транзитный трафик.

Для прода назначьте firewall-VM статические (зарезервированные) публичные IP:
ephemeral-адреса меняются при stop/start, из-за чего меняется egress-IP для
LAN-нагрузок.

Настройка VPN следует той же модели: настройте OpenVPN, IPsec или плагин
WireGuard в WebUI основного узла; конфигурация синхронизируется на резервный
через XMLRPC. При failover туннели восстанавливаются на выжившем узле
(TCP-сессии сбрасываются).

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

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