OPNsense HA Firewall

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

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

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

Детекция построена так, чтобы переключаться по правильным причинам и только по
ним:

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

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

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

Продукт создаёт и управляет только парой межсетевых экранов (две ВМ, сервисный
аккаунт, группа безопасности и общий секрет-конфиг в 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 — оба узла работают в единственной зоне
  доступности Казахстана (kz1-a) и используют эту 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-подсеть (с NAT) — VPC-подсеть в kz1-a как WAN для обоих узлов
  (управление и выход в интернет через NAT); в Казахстане одна зона доступности.
• Таблица маршрутизации — 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 (МСК) по рабочим дням.