pfSense High Availability cluster

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

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

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

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

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

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

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

• Активно-пассивная пара pfSense 2.7.2 в единственной зоне доступности Казахстана (kz1-a).
• Автоматическое двунаправленное переключение через обновление next-hop в таблице маршрутизации VPC — переживает последовательные отказы любого узла.
• Штатная синхронизация конфигурации через XMLRPC поверх HTTPS.
• Симметричный демон переключения на обеих ВМ; пассивный узел опрашивает активный по двум независимым путям (приватный VPC + публичный) и переключается только при отказе обоих, что не даёт сбою одного пути вызвать ложное переключение.
• Детекция с учётом плоскости данных: опрашиваемый 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-подсети pfSense.
• Одна WAN-подсеть в зоне Казахстана (kz1-a) с включённым NAT — в Казахстане одна зона доступности, поэтому оба узла размещаются в этой единственной WAN-подсети. NAT обеспечивает исходящий доступ и связь с control plane Yandex Cloud (API Lockbox, VPC), к которым обращается демон. Подсеть, общая группа безопасности и таблица маршрутизации с переключаемым next-hop должны быть в одной VPC-сети. Выбирайте ту же сеть, что и у route_table_id. Подсеть из другой сети приводит к ошибке деплоя «Security group and subnet have different networks».

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

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

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

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

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

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

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