Привет, Хабр! Сегодня лечим боли тех, кто администрирует межсетевые экраны 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 не меняют своего поведения и работают дальше как обычно.
8. Зайдите в MC и удалите старую группу устройств
9. Создайте новую группу устройств и подключите кластер NGFW
10. Проверьте настройки в шаблонах и сделайте ручную синхронизацию, чтобы перезаписать локальные настройки на настройки шаблонов
Перед синхронизацией стоит удалить политики, которые могут остаться даже после синхронизации, например, правила межсетевого экрана или фильтрацию контента.
После подключения нового кластера в Management Center «локальные» настройки исправной ноды перезаписываются теми же значениями из менеджмент-центра. Одновременно их получает новая нода, и контроль над кластером восстанавливается.
По сути, локальные настройки заменяются настройками из шаблонов, но в шаблонах находится все то же самое, так что NGFW не меняют своего поведения и работают дальше как обычно.
11. Проверьте работоспособность кластера после успешной синхронизации
В интерфейсе MC есть четкие индикаторы, сигнализирующие о проблемах с нодами.
Первое, на что стоит обратить внимание — вкладка Кластер конфигурации. Здесь ноды обычно отображаются зеленым цветом. Если система теряет связь с нодой, индикатор загорается красным.
Важна также графа Кластер отказоустойчивости. Она показывает, какая нода главная. При возникновении проблем там появляются предупреждающие значки: желтый треугольник или красный круг с восклицательным знаком.
Нужно понимать, что некоторые сбои там все же не отражаются, однако их можно отследить, например, по потере пакетов при прохождении трафика через проблемную ноду. Еще один признак: журналы загружаются с перебоями. Кроме того, бывают случаи, когда нода самопроизвольно перезагружается — все это явные поводы для беспокойства.
В заключение хочется сказать, что замена ноды в кластере UserGate может показаться нетривиальной задачей, но разработчики здорово упростили процесс в седьмой версии NGFW и MC. С правильным алгоритмом эту процедуру можно выполнить без простоя системы и с минимальными рисками. Надеемся, статья станет тем самым руководством, которое поможет вам в этом.
Однако прежде чем браться за замену ноды, рекомендуем создать тестовый стенд, если у вас его еще нет. UserGate активно развивается, и тестовая среда поможет вам избежать многих сюрпризов в процессе эксплуатации этого NGFW.
А что у вас, коллеги? Какие хаки вам приходилось изобретать для поддержания работоспособности инфраструктуры? Делитесь опытом в комментариях!
PURP — телеграм-канал, где кибербезопасность раскрывается с обеих сторон баррикад
t.me/purp_sec — инсайды и инсайты из мира этичного хакинга и бизнес-ориентированной защиты от специалистов Бастиона