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

8fd73397081c3fd0d9718003b1505b63.png

Привет, Хабр! Сегодня лечим боли тех, кто администрирует межсетевые экраны 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 в режим ручной синхронизации

788bb74e0bc7928878f85fcdcb7884f4.png

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

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

2. Установите нужную версию NGFW на новом устройстве

Ноды с разными версиями ПО нельзя объединить в один кластер. Поэтому проверьте версию NGFW на рабочей ноде и залейте такую же прошивку на новое устройство. На сайте вендора есть подробная инструкция. Можно смело действовать по ней.

3. Пропишите порт доступа и локальные настройки на новом NGFW через веб-консоль

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

4. Вернитесь к исправной ноде в составе старого кластера. Выполните на ней команду execute mc-force-disconnect keep

Эта команда отключит ноду от MC с сохранением всех импортированных из MC объектов и настроек.

0e8c66d61f3f49b1bedc20a7edb148ca.png

Параметр 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. Удалите неисправную ноду из кластера конфигурации на исправной ноде 

1bb21b2b56f37f3e1a5581d67af586c7.jpg

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

6. Сгенерируйте на исправной ноде секретный код и соберите кластер конфигурации с предварительно настроенной новой нодой

4935e5c64b29f287e41c4cbb231fd968.png

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

574f6c60457a5c28fa3e8e0e0b9b56c1.png

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

32b231d44cefcc0146c66232fbc57e13.png

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

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

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

11. Проверьте работоспособность кластера после успешной синхронизации 

054cdfd48a332325d14fdcd7549cc895.png

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

Первое, на что стоит обратить внимание — вкладка Кластер конфигурации. Здесь ноды обычно отображаются зеленым цветом. Если система теряет связь с нодой, индикатор загорается красным.

Важна также графа Кластер отказоустойчивости. Она показывает, какая нода главная. При возникновении проблем там появляются предупреждающие значки: желтый треугольник или красный круг с восклицательным знаком. 

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

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

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

А что у вас, коллеги? Какие хаки вам приходилось изобретать для поддержания работоспособности инфраструктуры? Делитесь опытом в комментариях!

985ed9da94351d70263c17e7915b8aae.jpgPURP — телеграм-канал, где кибербезопасность раскрывается с обеих сторон баррикад

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

© Habrahabr.ru