Осенью 2019 года Check Point прекратил поддержку версий R77.XX, и нужно было обновляться. О разнице между версиями, плюсах и минусах перехода на R80 сказано уже немало. Давайте лучше поговорим о том, как, собственно, обновить виртуальные appliance Check Point (CloudGuard for VMware ESXi, Hyper-V, KVM Gateway NGTP) и что может пойти не так.
Итак, у нас было 2 инженера CCSE, более десятка виртуальных кластеров Check Point R77.30, несколько облаков, немножечко хотфиксов и целое море разнообразных багов, глюков и всего такого, всех цветов и размеров, а еще очень сжатые сроки. Погнали!
Но мы будем реалистами. Если в самой минимальной конфигурации этого достаточно, то, как показывает практика, обычно у нас включена https-инспекция, на SMS работает SmartEvent и т.д., что, разумеется, требует совершенно других мощностей. Но в целом не больших, чем для R77.30.
Но есть нюансы. И касаются они, в первую очередь, размеров физической памяти. Многие операции непосредственно в процессе обновления потребуют места на жестком диске.
Для сервера управления размер свободного пространства на диске будет очень сильно зависеть от объема текущих логов (если мы желаем их сохранить) и от количества сохраненных Database Revisions, хотя они-то нам в большом количестве уже не понадобятся. Разумеется, для нод кластера (если только вы не храните логи еще и локально) это все не имеет значения. Вот как можно проверить наличие необходимого места:
Подключаемся к Smart Management Server по ssh, заходим в expert mode и вводим команду:
Учитывайте, что в зависимости от политики хранения и удаления старых лог-файлов, а также размера экспортируемой базы может понадобиться больше места. Если при создании архива свободного места станет меньше, чем указано в политике хранения лог-файлов, система начнет стирать старые логи и НЕ включит их в архив.
Также для самого процесса обновления системе понадобится минимум 13 GB нераспределенного места на жестком диске. Проверить его наличие можно командой:
По выполнению команды будет сформирован отчет о несовместимых настройках. Он доступен по адресу: /opt/CPsuite-R77/fw1/log/pre_upgrade_verification_report.(xls, html, txt). Удобнее выгрузить его через SCP и смотреть через браузер.
Для устранения всех несовместимых настроек используйте ШАҲРИ ҚӮРҒОНТЕППА.
После повторно запустить утилиту pre_upgrade_verifier, чтобы убедиться, что все причины несовместимости устранены.
Далее собираем информацию о сетевых интерфейсах, таблице маршрутизации и выгружаем конфигурацию GAIA: ip a > /var/log/UpgradeR77.30_R80.20/cp-sms-config.txt
ip r > /var/log/UpgradeR77.30_R80.20/cp-sms-config.txt
clish -c "show configuration" > /var/log/UpgradeR77.30_R80.20/cp-sms-config.txt
Выгружаем полученный файл через SCP.
Делаем snapshot на уровне виртуализации.
Увеличиваем timeout SSH сессии до 8 часов. Тут как повезет: в зависимости от размеров экспортируемой базы может продолжаться от нескольких минут до нескольких часов. Для этого: [Expert@HostName]# clish -c "show inactivity-timeout" смотрим текущий timeout clish,
[Expert@HostName]# clish -c "set inactivity-timeout 720" указываем новый timeout clish (в минутах),
[Expert@HostName]# export TMOUT=3600 указываем новый timeout expert mode (в секундах), если поставить значение 0, то timeout будет выключен.
Подгружаем и монтируем установочный образ SMS.iso к виртуальной машине.
Перед следующим шагом ОБЯЗАТЕЛЬНО еще раз проверьте, что у вас достаточно нераспределенного места на жестком диске (напоминаю, нужно 13 GB).
Перед началом экспорта конфигурации меняем лог файл командой: fw logswitch
Экспорт конфигурации и логов
Запускаем утилиту migrate_export для выгрузки конфигурации. Для этого проходим в ранее созданную папку: cd /var/log/UpgradeR77.30_R80.20/ и используем команду: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
ё
проходим в папку: cd $FWDIR/bin/upgrade_tools/ и
запускаем оттуда команду: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
Снимаем checksum с архива: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
Сохраняем в блокнот полученное значение.
Подключаемся к SMS через SCP и выгружаем архив с конфигурацией на рабочую станцию. Обязательно использовать передачу файлов в формате Binary.
Экспорт базы SmartEvent
Здесь нам понадобится заранее установленный SMS версии R80. Любой тестовый подойдет.
От SMS нам нужен скрипт, расположенный здесь:$RTDIR/bin/eva_db_backup.csh
Через SCP загружаем скрипт eva_db_backup.csh в папку: /var/log/UpgradeR77.30_R80.20/
Подключаемся по SSH к SMS. Скопировать файл в папку: cp /var/log/UpgradeR77.30_R80.20/eva_db_backup.csh
$RTDIR/bin/eva_db_backup.csh
Запускаем экcпорт базы SmartEvent: $RTDIR/bin/eva_db_backup.csh
Выгружаем полученные файлы через SCP: $RTDIR/bin/<дата>-db-backup.backup и $RTDIR/bin/eventiaUpgrade.tar на рабочую станцию.
Навсозӣ
Бирав ба WebUI GAIA SMS → CPUSE → Show all packages.
В случае, когда CPUSE выдает ошибку подключения к облаку Check Point, проверяем DGW, DNS и настройки Proxy.
Если все верно, а ошибка не исчезает, то нужно обновить CPUSE вручную, руководствуясь sk92449.
Скачиваем образ и проходим Тасдиқкунанда. В случае необходимости устраняем несоответствия.
В результате должны увидеть вот такое сообщение:
Мо интихоб мекунем R80.20 Fresh Install and Upgrade for Security Management.
При установке обновления выбираем Clean Install. После инсталляции система перезагрузится.
Проходим First Time Ҷодугар.
После получения доступа проверяем учетные записи.
Подключаемся к SMS по SSH и меняем shell нашего пользователя на /bin/bash/:
set user <имя пользователя> shell /bin/bash/
конфигуратсияро захира кунед (в случае, если мы хотим оставить bin/bash/ как shell по умолчанию и после перезагрузки).
Далее подключаемся к SMS через SCP и в режиме Binary передаем архив с конфигурацией SMS_w_logs_export_r77_r80.tgz ба папка /var/log/UpgradeR77.30_R80.20/
Снимаем checksum с архива: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz и сравниваем с предыдущим значением. Checksum должны совпадать.
Увеличиваем timeout SSH сессии до 8 часов. Для этого:
[Expert@HostName]# export TMOUT=3600 указываем новый timeout expert mode (в секундах). Если поставить значение 0, то timeout будет выключен.
Для импорта настроек запускаем утилиту migrate import. Для этого переходим в папку: cd $FWDIR/bin/upgrade_tools/и запускаем импорт: ./migrate imp
ort -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
Наслаждаемся жизнью ближайшие пару часов. НЕ ОТКЛЮЧАЙТЕ SSH-СЕССИЮ во время процедуры. В конце процесс migrate выдаст либо сообщение об успешном завершении операции, либо ошибку.
Чек-лист проверок после обновления
Мавҷудияти захираҳо.
SIC с GW.
Лицензии. Если лицензии отображаются неверно либо не отображаются на SMS, запускаем команду vsec_central_licence для распределения лицензий.
Установка политики.
Импорт базы SmartEvent
Активируйте блейд SmartEvent.
Подключаемся через WinSCP к SMS и в режиме binary передаем выгруженные ранее файлы <дата>-db-backup.backup и eventiaUpgrade.tar ба папка /var/log/UpgradeR77.30_R80.20/
Сохраняем конфигурацию GAIA с каждой ноды кластера в файл, для этого воспользоваться командой: clish -c "show configuration" > ./<Название файла>.txt
Выгружаем файлы при помощи WinSCP.
Подключаемся к WebUI обеих нод и переходим на вкладку CPUSE → Show all packages.
Находим пакет обновлений для версии R80.20 Fresh Install, матбуот Зеркашӣ кунед.
Проверяем, что CCP-протокол работает в режиме Вroadcast, для этого вводим команду: cphaprob -a if
Если выбран режим Мултикаст, смените его командой: cphaconf set_ccp broadcast (команда выполняется на каждой ноде).
Устанавливаем Downtime для задействованных нод в вашей системе мониторинга.
Проверяем, что на уровне виртуализации включены параметры MAC Address Change и Forged Transmits для sync-сети.
Навсозӣ
Подключаемся по ssh к Active-ноде и запускаем команду для мониторинга состояния кластера: watch -n 2 cphaprob stat
Возвращаемся в WebUI Stanby ноды на вкладку CPUSE и для выбранного пакета R80.20 Fresh Install оғоз Тасдиқкунанда.
Анализируем отчет Verifier. Если установка разрешена, идем дальше.
Выбираем пакет R80.20 Fresh Install и запускаем азнавсозӣ. В процессе Upgrade система будет перезагружена. Настройки GAIA сохраняются. В момент перезагрузки отслеживаем состояние кластера. После загрузки статус обновленной ноды должен смениться на READY. В ряде случаев у нас возникал момент, когда еще не обновленная нода переходила в статус Active Attention и переставала отображать статус обновленной ноды. Не пугайтесь – такой вариант также допустим.
По завершению обновления открываем SmartDashboard.
Открываем кластерный объект и меняем версию кластера с R77.30 на R80.20. Жмем Ок. Если при сохранении изменений появляется ошибка: An internal error has occurred. (Code: 0x8003001D, Could not access file for write operation),
следуйте ШАҲРИ ҚӮРҒОНТЕППА. После этого сохраняем изменения и жмем Install Policy.
В настройках убираем галочку с параметра For gateway clusters, if installation on a cluster member fails, do not install on that cluster.
Устанавливаем политику. Система выдаст ошибку для Active-ноды, которая еще не обновлена.
Подключаемся к обновленной ноде по ssh и запускаем команду для мониторинга состояния кластера: watch -n 2 cphaprob stat
Подключаемся к WebUI Active-ноды и переходим во вкладку CPUSE → Show all packages.Находим пакет обновлений для версии R80.20 Fresh Install, жмем Зеркашӣ кунед.
Устанавливаем Downtime для задействованных нод в вашей системе мониторинга.
Возвращаемся в WebUI Active-ноды на вкладку CPUSE и для выбранного пакета R80.20 Fresh Install оғоз Тасдиқкунанда.
Анализируем отчет Verifier. Если установка разрешена, идем дальше.
Выбираем пакет R80.20 Fresh Install и запускаем Навсозӣ. В процессе Upgrade система будет перезагружена. Настройки GAIA сохраняются. В момент перезагрузки отслеживаем состояние кластера на уже обновленной ноде. После перезагрузки состояние кластера на обновленной ноде изменится с READY на ACTIVE.
Когда завершится процесс Upgrade, запускаем SmartDashboard и устанавливаем политику.
Чек-лист проверок после обновления
Журналы событий в SmartLog, состояние VPN-туннелей.
Настройки GAIA.
Восстановление кластера после тестового Failover.
Лицензии и контракты. В случае если лицензии отображаются неверно либо не отображаются на SMS, запускаем команду. vsec_central_licence для распределения лицензий.
CoreXL.
SecureXL.
Hotfix и CPinfo на двух нодах.
хулоса
В общем-то на этом моменте все – вы обновились.
У нас весь процесс занимал в среднем от 6 до 12 часов, в зависимости от размеров экспортируемых баз. Работы проводили две ночи: одна – для обновления SMS, вторая – для кластера.
Простоя трафика не было, несмотря на то, что все вышеупомянутые ошибки мы проверяли на себе.
Конечно, иногда могут возникнуть и совершенно новые трудности в процессе обновления, но это Check Point, и, как мы все знаем, всегда есть hotfix!