Замена ноды в кластере UserGate NGFW без простоя: проверенный алгоритм

Привет, Хабр! Сегодня лечим боли тех, кто администрирует межсетевые экраны UserGate. Представьте: критическая инфраструктура, трафик льется рекой, а одна из нод в кластере под управлением Management Center решила выйти из строя. Замена уже доставлена, но вы не знаете, как подключить ее без остановки системы.
Нужный вам алгоритм — под катом.
Сломался NGFW. Не важно, произошел дисковый сбой или это какой-то баг — служба поддержки вендора рекомендует заменить оборудование, пока они разбираются с проблемой. Новый сетевой экран доставлен, но нода входит в кластер с централизованным управлением. Как ее заменить без остановки системы? Какой алгоритм действий выбрать?
Этот вопрос задал нам заказчик. Нужно было включить инструкцию в рабочую документацию, чтобы администраторы могли быстро решить проблему без звонков в поддержку. Запрос логичный: у заказчика непрерывное производство, которое нельзя просто поставить на паузу, и огромные объемы трафика 24 на 7. Даже небольшой простой — это серьезные денежные потери.
Для отказоустойчивости в крупных инсталляциях мы создаем каждому заказчику кластер, обычно состоящий из двух экземпляров NGFW. Сам кластер — штука простая, его легко собрать и разобрать. Но есть еще система централизованного управления UserGate Management Center (далее — MC). Это отдельный программно-аппаратный комплекс или виртуалка, которая синхронизирует настройки и распределяет новые конфигурации на ноды. И вот правильно вывести и ввести в нее ноду без остановки работы кластера — непростая задача.
Оказалось, что в официальной документации нет четких инструкций на такой случай. Пришлось искать решение самостоятельно.
Дисклеймер:
Мы предлагаем рабочее решение, которое позволяет переключать ноды кластера без простоев. Данный метод работает только на MC и NGFW начиная с версии 7.х (7.1.2, 7.2.0 и т. д.).
Администратору потребуется полный доступ, чтобы без ограничений работать в веб-интерфейсе и консоли. И да, обязательно нужна хотя бы одна рабочая нода в кластере.
Наше решение не обязательно единственно верное. Скорее всего, алгоритм можно усовершенствовать; если вы знаете, как — поделитесь в комментариях.
0. Подготовьтесь к замене ноды
NGFW UserGate поддерживают полнодисковый бекап. Кроме того, можно сформировать конфигурационный файл для восстановления настроек. В идеале сделайте и бэкап, и конфиг — так вы сможете выбрать оптимальный сценарий восстановления при любом сбое.
Существует и третий способ резервного копирования через скрипт с GitHub, который выгружает конфигурацию в JSON-файлы и позволяет загружать ее обратно. Техподдержка иногда его рекомендует, но учтите, что такой способ восстановления потребует много ручной работы.
Кроме того, хотя мы планируем замену ноды без простоя, стоит предупредить пользователей о технических работах или провести замену в нерабочее время. Во время реконфигурации кластера и перезаливки настроек ноды могут работать нестабильно.
1. Переведите новую ноду в Management Center в режим ручной синхронизации

Ручная синхронизация помогает избежать случайной загрузки нежелательных настроек на ноду.
В нашем случае это важно, ведь если момент автоматической синхронизации параметров ноды с MC совпадет с применением любых других настроек, то возникнет дополнительный риск сбоя. Не все настройки могут примениться корректно, и вы столкнетесь с дополнительными проблемами.
2. Установите нужную версию NGFW на новом устройстве
Ноды с разными версиями ПО нельзя объединить в один кластер. Поэтому проверьте версию NGFW на рабочей ноде и залейте такую же прошивку на новое устройство. На сайте вендора есть подробная инструкция. Можно смело действовать по ней.
3. Пропишите порт доступа и локальные настройки на новом NGFW через веб-консоль
Хотя портом управления может быть любой интерфейс, наши заказчики часто выносят port0 в отдельный VRF и используют его в качестве интерфейса управления для администраторов. Это помогает избежать проблем с пересечением маршрутов административной сети и других систем.
4. Вернитесь к исправной ноде в составе старого кластера. Выполните на ней команду execute mc-force-disconnect keep
Эта команда отключит ноду от MC с сохранением всех импортированных из MC объектов и настроек.

Параметр
keep
гарантирует сохранение настроек при отключении от Management Center. Если на активной рабочей ноде случайно ввести неправильную переменную, можно потерять все настройки.Единственное решение в такой ситуации — сразу же заново подключить устройство к Management Center, чтобы все значения восстановились автоматически. Иначе придется все настраивать вручную и серьезно повозиться.
Четвертый пункт инструкции — очень важный момент, который нуждается в пояснении.
Ноды в кластере UserGate именуются по порядку: нода 1, нода 2. Причем эти имена напрямую влияют на процесс настройки. Главная проблема при замене ноды в кластере состоит в том, что из MC нельзя полностью удалить устройство. Можно скрыть информацию об отключенном железе, но фактически оно остается зарегистрированным в центре управления и сохраняет за собой имя.
Если основная нода — номер 1, а сломавшаяся — номер 2, то при подключении нового устройства вы сможете выбрать только ноду 3. Придется переделывать настройки, а это огромный объем ручной работы.
Нельзя просто взять и удалить ноду, предварительно отключив ее от MC. Из-за этого приходится удалять всю группу устройств. Раньше мы даже сбрасывали сами железки до заводских настроек, потому что NGFW считал, что подключен к MC, хотя на самом деле это было уже не так. Заводской сброс и последующая сборка кластера отнимает много времени. К тому же после нужно заново заливать конфигурацию и проверять корректность ее применения.
Но команда mc-force-disconnect keep
, появившаяся в седьмой версии UserGate NGFW, помогает упростить процесс. Именно она позволяет выполнить трюк с заменой ноды в кластере без простоев. execute mc-force-disconnect keep
отключает ноду от MC, но при этом ее настройки сохраняются локально и по-прежнему действуют. В результате трафик продолжает идти через ноду как обычно.
5. Удалите неисправную ноду из кластера конфигурации на исправной ноде

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

7. Проверьте работоспособность и убедитесь, что кластер конфигурации собран и новая нода собралась в кластер отказоустойчивости

Когда вы отсоединяете NGFW от MC с помощью команды, устройство сохраняет все настройки, полученные из MC, включая параметры кластера отказоустойчивости. А когда добавляете новую ноду в кластер конфигурации, она автоматически появляется в разделе Кластер отказоустойчивости.

Перед синхронизацией стоит удалить политики, которые могут остаться даже после синхронизации, например, правила межсетевого экрана или фильтрацию контента.
После подключения нового кластера в Management Center «локальные» настройки исправной ноды перезаписываются теми же значениями из менеджмент-центра. Одновременно их получает новая нода, и контроль над кластером восстанавливается.
По сути, локальные настройки заменяются настройками из шаблонов, но в шаблонах находится все то же самое, так что NGFW не меняют своего поведения и работают дальше как обычно.
11. Проверьте работоспособность кластера после успешной синхронизации

В интерфейсе MC есть четкие индикаторы, сигнализирующие о проблемах с нодами.
Первое, на что стоит обратить внимание — вкладка Кластер конфигурации. Здесь ноды обычно отображаются зеленым цветом. Если система теряет связь с нодой, индикатор загорается красным.
Важна также графа Кластер отказоустойчивости. Она показывает, какая нода главная. При возникновении проблем там появляются предупреждающие значки: желтый треугольник или красный круг с восклицательным знаком.
Нужно понимать, что некоторые сбои там все же не отражаются, однако их можно отследить, например, по потере пакетов при прохождении трафика через проблемную ноду. Еще один признак: журналы загружаются с перебоями. Кроме того, бывают случаи, когда нода самопроизвольно перезагружается — все это явные поводы для беспокойства.
В заключение хочется сказать, что замена ноды в кластере UserGate может показаться нетривиальной задачей, но разработчики здорово упростили процесс в седьмой версии NGFW и MC. С правильным алгоритмом эту процедуру можно выполнить без простоя системы и с минимальными рисками. Надеемся, статья станет тем самым руководством, которое поможет вам в этом.
Однако прежде чем браться за замену ноды, рекомендуем создать тестовый стенд, если у вас его еще нет. UserGate активно развивается, и тестовая среда поможет вам избежать многих сюрпризов в процессе эксплуатации этого NGFW.
А что у вас, коллеги? Какие хаки вам приходилось изобретать для поддержания работоспособности инфраструктуры? Делитесь опытом в комментариях!

t.me/purp_sec — инсайды и инсайты из мира этичного хакинга и бизнес-ориентированной защиты от специалистов Бастиона