Представьте: обычный вторник, и вдруг в корпоративном чате паника — CRM лежит, бухгалтерия не может отправить платежи, сайт не открывается. Где-то в серверной тихо погас светодиод на ключевом коммутаторе. Или, что хуже — весь ЦОД оказался в зоне коммунальной аварии. 

Но что еще хуже — вместе с частью инфраструктуры вышли из строя защитные решения, и появился риск получить вдобавок к аварии еще и кибератаку. Чтобы этот страшный сон не стал явью, инженеры придумали «подложить соломки» при помощи кластеризации.

Сегодня поговорим о том, как превратить точку отказа в отказоустойчивую систему на примере российского NGFW-решения UserGate. Разберем не только техническую сторону (протокол VRRP, режимы Active/Passive и Active/Active, синхронизацию сессий), но и практические моменты: сколько это стоит, как долго настраивать, какие подводные камни ждут на каждом этапе.

Статья будет полезна системным администраторам, которые планируют внедрение отказоустойчивого периметра, и техническим руководителям, которым нужно понимать, во что они ввязываются.

О чем поговорим:

• Этап 0: планирование. Почему подготовка важнее кликов в интерфейсе и как избежать «танцев с бубном» на старте.

• Выбор NGFW-решения. Краткий разбор отечественного ландшафта NGFW: UserGate, «Код Безопасности», «Инфотекс». Чем они отличаются?

• Глубокое погружение в UserGate. Разберем архитектуру кластеризации, логику работы протокола VRRP и два ключевых режима: Active/Passive и Active/Active. Спойлер: у второго есть нюансы.

• Пошаговая инструкция. Пройдем ключевые этапы настройки — от сборки кластера конфигурации до запуска отказоустойчивости на примере UserGate. С объяснением, зачем нужен каждый шаг.

• Жизнь после внедрения. Как правильно тестировать, мониторить и не допускать распространенных ошибок.

Этап 0: планирование — «семь раз отмерь»

Прежде чем погрузимся настройки, поговорим о самом важном. Практика показывает: 90% проблем при внедрении кластера возникает из-за недостаточной подготовки.

Формируем команду и техническое задание

Развертывание кластера — не сольный проект. Для внедрения кластера понадобится слаженная команда из нескольких технических специалистов:

• Инженер внедрения (от интегратора) — ваш главный проводник в мире NGFW.

• Сетевой инженер (со стороны заказчика) — человек, который знает вашу сеть как свои пять пальцев. Ключ к успешной интеграции.

• Системный администратор (со стороны заказчика) — курирует серверы, почту, Active Directory и другие сервисы, которые будут взаимодействовать с кластером.

• Специалист по ЦОД (опционально) — если есть выделенный сотрудник, отвечающий за «железо» в стойках, его участие обязательно.

Грамотное ТЗ начинается с ответов на простые, но ключевые вопросы: 

• Какие системы защищаем? ERP, CRM, биллинг?

• Насколько критичен их простой? Какова его допустимая длительность: минуты, часы? От этого зависит, нужна ли синхронизация сессий.

• Сколько пользователей генерируют трафик и какого он типа?

• Проект — это миграция с существующего решения (например, Cisco или Fortinet) или инсталляция «с чистого листа»?

Ответы на эти вопросы позволят определить архитектуру, сложность политик безопасности и, в конечном счете, сроки проекта. Фраза «внедрение может занять несколько месяцев» пугает, только когда непонятно, из чего эти месяцы состоят. А состоят они из миграции сотен политик, интеграции со сложной сетевой топологией и отладки взаимодействия с десятками внутренних сервисов.

Аудит инфраструктуры

Если «переезжаете» на UserGate с другого устройства, аудит — первый шаг. Нужно досконально изучить текущую конфигурацию. Если это новая инсталляция, сосредоточьтесь на этих моментах:

• IP-адресация — классические «грабли». На каждый интерфейс кластера понадобится минимум три IP-адреса: по одному на физический интерфейс каждой ноды и один виртуальный (VIP). Убедитесь, что есть свободные адреса, иначе в середине проекта придется срочно перекраивать всю сетевую схему.

• Физическое размещение — хватит ли портов на коммутаторах? Есть ли место в стойке для двух (или более) устройств? Не забывайте про выделенный интерфейс для синхронизации (Sync Link) — его лучше подключать напрямую между нодами, минуя коммутаторы. Это не только быстрее, но и исключает коммутатор как единую точку отказа для самого кластера.

• Требования к зонам — для интерфейса, через который ноды будут обмениваться служебной информацией, нужно создать отдельную зону с разрешенным сервисом «Кластер». Вопрос функциональности и безопасности. 

• Ответственность за политики доступа. В случае инсталляции с чистого листа необходимо разобраться, кто именно будет прорабатывать такие политики. В идеале этим должны заниматься штатные безопасники самой компании, но иногда подобная задача ложиться на интегратора. Чтобы не возникло путаницы и перекладывания ответственности, этот момент стоит четко зафиксировать в техническом задании. 

Идеальная схема подключения: WAN и LAN-интерфейсы каждой ноды подключены к разным физическим коммутаторам, а Sync-линк (port4) соединен напрямую. Это позволяет обеспечить максимальную отказоустойчивость.

Обзор российских NGFW-решений: выбираем инструмент

На российском рынке есть три основных игрока, разрабатывающих решения для защиты периметра: UserGate, «Инфотекс» и «Код Безопасности». На первый взгляд они конкуренты, но на самом деле занимают разные ниши.

UserGate — классический NGFW (Next-Generation Firewall). Его сила в глубоком анализе трафика (L7), контроле приложений, IPS, веб-фильтрации и других функциях, которые позволяют строить гранулированные политики безопасности. По сути, это цифровой вышибала на входе в вашу сеть, который проверяет не только «паспорт» (IP-адрес), но и «содержимое карманов» (данные приложений).

«Инфотекс» (продукты ViPNet) и «Код Безопасности» («Континент») — в первую очередь криптошлюзы. Их основная задача — поддерживать защищенные VPN-туннели с использованием ГОСТ-шифрования. Это требование регуляторов для многих государственных и финансовых организаций. Можно сказать, что в их случае NGFW-функционал несколько вторичен. 

Что же выбрать? На практике часто используется гибридный подход. UserGate ставится на периметр для NGFW-фильтрации, а решения от «Инфотекс» или «Код Безопасности» — для организации ГОСТ VPN-туннелей с филиалами или партнерами.

Сегодня фокусируемся на UserGate, так как именно он предлагает несколько более гибкую кластеризацию для задач NGFW.

Как устроен UserGate: погружение в архитектуру

UserGate реализует кластеризацию на двух уровнях. Важно понимать их различие:

• Кластер конфигурации — устройства, объединенные в такой кластер, начинают использовать единые настройки: политики, правила, объекты. Если вы что-то измените на одном узле, настройки тут же реплицируются на все остальные. Это ядро, без которого кластеризация не заработает.

• Кластер отказоустойчивости — уже периферия. Он отвечает за то, чтобы в случае сбоя одного из узлов трафик мгновенно и бесшовно переключился на другой. Эта магия работает благодаря протоколу VRRP (Virtual Router Redundancy Protocol).

VRRP работает как колл-центр. Клиенту всё равно, какой именно оператор ответит — Петр или Мария. Он звонит на общий номер. В VRRP этот «общий номер» — виртуальный IP-адрес (VIP). Все пользователи и системы в сети отправляют трафик именно на него. За этим VIP-адресом скрываются два (или более) физических устройства. Одно из них — Master, оно активно владеет этим IP и обрабатывает весь трафик. Второе — Backup, оно ждет своего часа.

Master-узел постоянно рассылает в сеть специальные пакеты (VRRP Advertisement), говоря: «Я жив, VIP мой!» Если эти пакеты перестают приходить, Backup-узел понимает, что Master «упал», и сам захватывает VIP, становясь новой Master-нодой.

Для конечного пользователя это переключение происходит практически незаметно. Его сессия не разрывается, потоковое видео не прерывается. Отказоустойчивость достигнута.

UserGate поддерживает два режима работы кластера отказоустойчивости.

Режим Active/Passive

Классическая и самая надежная схема. Один узел (Master) обрабатывает 100% трафика. Второй (Passive) простаивает, но находится в полной боевой готовности и постоянно синхронизирует состояние сессий с мастером.

Переключение происходит, если Master-нода перестает отвечать, рвется интернет-канал или происходит сбой ПО.

• Плюсы: предсказуемость, надежность, легче диагностировать проблемы.

• Минусы: вторую ноду, по сути, не используете. Её ресурсы простаивают.

Режим Active/Active

Схема для тех, кто хочет выжать максимум из своего «железа». В ней оба узла активны и обрабатывают трафик. Master-узел выполняет балансировку нагрузки, распределяя новые сессии между всеми нодами кластера поочередно (механизм Round-robin для ARP-ответов).

Если один из узлов вдруг выходит из строя, оставшийся в живых берет на себя всю нагрузку. Поэтому важно убедиться, что его производительности хватит, чтобы выдержать пиковый трафик в одиночку.

• Плюсы: эффективное использование ресурсов обоих устройств.

• Минусы: сложнее в настройке и диагностике. Не все функции UserGate (например, некоторые виды VPN или сложная маршрутизация) идеально работают в этом режиме. Нет «двойного прироста» трафика при одновременной работе двух нод из-за отсутствия в UserGate встроенного балансировщика. Особенно это критично, когда один узел выходит из строя, а второй вынужден обрабатывать весь трафик в одиночку и «держать в голове», что это кластер Active/Active. Для полноценной работы отказоустойчивой системы в таком режиме требуется отдельное решение для балансировки нагрузки.

Построение кластера: пошаговое руководство

Итак, теория позади, переходим к практике. Вот упрощенная последовательность действий.

Этап 1. Сборка кластера конфигурации

1. Подготовка кластерного интерфейса на первой ноде (будущем Master)

Заходим в веб-интерфейс первого устройства. Выбираем интерфейс для синхронизации (традиционно это port4). Назначаем ему статичный IP-адрес и помещаем в специальную зону (например, «Cluster-Sync»), в которой в разделе Контроль доступа включен сервис Кластер.

Через этот интерфейс ноды будут обмениваться конфигурациями и служебной информацией. Изоляция этого трафика в отдельную зону — хорошая практика безопасности.

2. Инициализация кластера на первой ноде

Переходим в раздел Кластеры → Кластер конфигурации. Нажимаем «Инициализировать». Система попросит перезагрузиться. После перезагрузки генерируем секретный код.

Таким образом мы превращаем одиночное устройство в «Мастер» кластера конфигурации. Секретный код — одноразовый ключ, с помощью которого другие ноды смогут к нему подключиться.

3. Подключение второй ноды

Подключаемся к веб-интерфейсу второго устройства. Настраиваем на нем интерфейс управления. При первоначальной инициализации выбираем «Подключиться к кластеру». Указываем IP-адрес кластерного интерфейса Master-ноды и вводим сгенерированный ранее секретный код.

Вторая нода «спрашивает» у первой разрешение на подключение и, получив его, полностью скачивает всю конфигурацию, становясь ведомой.

Бинго! Кластер конфигурации собран. Теперь оба устройства — единое целое с точки зрения настроек.

Этап 2. Сборка кластера отказоустойчивости (нервная система)

1. Включение VRRP на «боевых» интерфейсах

На Master (конфигурация синхронизируется) заходим в настройки сетевых интерфейсов, которые «смотрят» в локальную сеть (LAN) и во внешнюю (WAN). Для каждого из них в разделе VRRP ставим галочку «Включить VRRP».

Зачем это нужно: даем команду этим интерфейсам «участвовать в выборах» Master-узла и быть готовыми подхватить виртуальный IP-адрес.

2. Создание кластера отказоустойчивости

Переходим в Кластеры → Кластер отказоустойчивости.

Создаем новый кластер, выбираем режим (например, Active/Passive) и даем ему имя.

3. Назначение нод и виртуальных IP-адресов

Добавляем в созданный кластер обе наши ноды из кластера конфигурации. Для каждой пары интерфейсов (например, port1 на обеих нодах, который смотрит в LAN) задаем общий виртуальный IP-адрес (VIP). Этот адрес и будет шлюзом по умолчанию для ваших пользователей. То же самое повторяем для WAN-интерфейса.

Таким образом определяем, какие физические интерфейсы будут бороться за какой виртуальный адрес. Именно этот VIP и обеспечивает «бесшовность» переключения. После сохранения настроек кластер начнет свою работу. Master-узел захватит VIP-адреса, и трафик потечет через него.

Жизнь после внедрения: мониторинг и тестирование

Собрать кластер — полдела. Важно убедиться, что он сработает в реальных аварийных ситуациях, а не только в лабораторных условиях.

Распространенная ошибка: собрать кластер, увидеть, что всё работает, и забыть про него. Тестируйте сценарии отказов регулярно. Кластер, который работает полгода без проверок — это лотерея. Может сработать, а может и нет.

Инструменты мониторинга:

• Встроенные средства UserGate. Дашборды и логи самого устройства — первый источник информации. Настройте оповещения по почте о важных событиях.

• SNMP и Syslog. Интегрируйте кластер с централизованной системой мониторинга (Zabbix, Grafana и т.д.). Стандарт де-факто для серьезного продакшена. Вендор предоставляет MIB-файлы для удобной настройки.

• Линуксовые скрипты. Не игнорируйте сторонние инструменты, которые иногда рекомендует сам вендор или сообщество. Существуют готовые скрипты для мониторинга состояния кластера, которые можно легко развернуть на отдельной виртуальной машине.

Тест 1: классический failover

Самый наглядный тест — имитация сбоя. Запустите непрерывный пинг на какой-нибудь внешний ресурс (ping 8.8.8.8 -t) с компьютера в вашей сети. Затем просто выдерните питание из Master-ноды.

Если всё настроено правильно, вы увидите потерю одного-двух пакетов, после чего пинг восстановится. Это означает, что Backup-узел подхватил роль и трафик пошел через него.

Тест 2: обрыв связи между файрволами

Самый страшный баг кластеров, когда связь между нодами пропала, и обе считают себя главными. В сети появляется два устройства с одинаковыми IP-адресами. В результате соединения рвутся, а коммутаторы не понимают, куда слать трафик.

Чтобы проверить этот сценарий, подключите файрволы напрямую друг к другу отдельным кабелем. Не через коммутатор — это важно. Включите tie-breaker, приоритеты, link-monitor. Настройте приоритеты и правила, которые определяют, кто должен остаться главным при потере связи.

Теперь разорвите только sync-линк. WAN/LAN не трогайте. Параллельно лейте умеренный трафик через кластер, держите открытые TCP-сессии.

Наблюдайте за поведением. Главным должен остаться только один файрвол. У второго в логах должна появиться запись типа «потерял связь с напарником, остаюсь резервным». Верните sync и проследите, не возник ли MAC-flapping на коммутаторах.

Тест 3: сбой автоматического переключения между нодами 

Оборудование узла может попросту глючить, и тогда автоматическое переключение между нодами в случае сбоев не выполняется. Например, так бывает при большом износе и плачевном состоянии железа одной из ноды. В таком случае выход один: всё проверить и переключиться между узлами в ручном режиме.

Вместо заключения

Кластеризация — это как страховка от пожара. Пока дом не горит, кажется, что деньги потрачены впустую. Но когда случается беда, понимаешь: это лучшие деньги, которые ты когда-либо тратил.

Российские решения, такие как UserGate NGFW, прошли долгий путь и сегодня предлагают зрелый и функциональный инструментарий для обеспечения защиты и непрерывности бизнеса даже в условиях сбоев. Да, у них есть свои особенности, и они не всегда могут похвастаться отполированностью зарубежных аналогов, но при грамотном планировании и прямых руках они позволяют выстроить надежную и отказоустойчивую систему защиты.

И это уже не просто импортозамещение. Это прагматичный выбор.

P.S. Если у кого-то есть боевой опыт с другими российскими NGFW — делитесь в комментариях. Особенно интересно сравнение производительности в кластерных конфигурациях.

Бастион — защищаем бизнес от киберугроз

t.me/bastiontech — делимся собственным опытом, экспертизой, результатами исследований и прогнозами