pfSense High Availability cluster

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

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

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

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

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

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

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

• Активно-пассивная пара pfSense 2.7.2 в двух зонах доступности.
• Автоматическое двунаправленное переключение через обновление next-hop в
  таблице маршрутизации VPC — переживает последовательные отказы любого узла.
• Штатная синхронизация конфигурации через XMLRPC поверх HTTPS.
• Симметричный демон переключения на обеих ВМ; пассивный узел опрашивает активный
  по двум независимым путям (приватный VPC + публичный) и переключается только
  при отказе обоих, что не даёт сетевому разделению вызвать ложное переключение
  (защита от split-brain).
• Детекция с учётом плоскости данных: опрашиваемый health-эндпоинт (TCP 8443)
  сообщает «здоров» только когда узел достигает собственный WAN-шлюз, поэтому
  переключение следует за потерей пересылки наверх, а не за потерей питания.
• Проба с привязкой к сертификату (отпечаток SHA-256): переназначенный эфемерный
  публичный IP не может выдать себя за соседа и скрыть реальный отказ.
• Асимметричные пороги: пропавший узел переключается быстро (~15-20 секунд),
  деградировавший, но достижимый — медленнее, чтобы гасить кратковременные
  сигналы.
• Без SDK и файлов ключей сервисного аккаунта: демон использует IAM-токены из
  сервиса метаданных инстанса.
• Сервисный аккаунт с минимальными правами (только три роли IAM).

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

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

• Секрет Lockbox с паролем admin — оба узла аутентифицируются друг к другу
  по pfSense XMLRPC паролем admin, и вторичный узел читает его при загрузке.
  Он хранится в 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-сети — единая группа безопасности,
  таблица маршрутизации с переключаемым next-hop и обнаружение соседа работают в
  пределах одной сети. Выбирайте ту же сеть, что и у route_table_id. Подсети из
  разных сетей приводят к ошибке деплоя «Security group and subnet have different
  networks».

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

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

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

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

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

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

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

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

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

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

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

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 (или остаются без выхода в интернет).
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. Их единственный путь наружу — через
   таблицу маршрутизации на pfSense; публичный IP на LAN-VM вызывает асимметрию
   (входящий через свой NAT, исходящий через pfSense) и ломает соединения.
4. LAN-подсети должны быть в той же VPC-сети, что и WAN firewall.

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

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

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

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

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

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