Код ошибки 26702 чекпоинт

Обновляем Check Point с R77.30 на 80.20

Подробнейшая инструкция для тех, кому предстоит обновиться до версии 80.20.

Осенью 2019 года Check Point прекратил поддержку версий R77.XX, и нужно было обновляться. О разнице между версиями, плюсах и минусах перехода на R80 сказано уже немало. Давайте лучше поговорим о том, как, собственно, обновить виртуальные appliance Check Point (CloudGuard for VMware ESXi, Hyper-V, KVM Gateway NGTP) и что может пойти не так.

Итак, у нас было 2 инженера CCSE, более десятка виртуальных кластеров Check Point R77.30, несколько облаков, немножечко хотфиксов и целое море разнообразных багов, глюков и всего такого, всех цветов и размеров, а еще очень сжатые сроки. Погнали!

Так выглядит типичная облачная инфраструктура клиента с виртуальным Check Point

Подготовка

Первым делом нужно проверить достаточность ресурсов для обновления. Рекомендованные минимальные требования для R80.20 сейчас выглядят так:

Рекомендации описаны в документе CP_R80.20_GA_Release_Notes.

Но мы будем реалистами. Если в самой минимальной конфигурации этого достаточно, то, как показывает практика, обычно у нас включена https-инспекция, на SMS работает SmartEvent и т. д., что, разумеется, требует совершенно других мощностей. Но в целом не больших, чем для R77.30.

Но есть нюансы. И касаются они, в первую очередь, размеров физической памяти. Многие операции непосредственно в процессе обновления потребуют места на жестком диске.

Для сервера управления размер свободного пространства на диске будет очень сильно зависеть от объема текущих логов (если мы желаем их сохранить) и от количества сохраненных Database Revisions, хотя они-то нам в большом количестве уже не понадобятся. Разумеется, для нод кластера (если только вы не храните логи еще и локально) это все не имеет значения. Вот как можно проверить наличие необходимого места:

Подключаемся к Smart Management Server по ssh, заходим в expert mode и вводим команду:

На выходе мы увидим примерно такую конфигурацию:

Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_splat-lv_current 30G 7.4G 21G 27% /
/dev/sda1 289M 24M 251M 9% /boot
tmpfs 2.0G 0 2.0G 0% /dev/shm
/dev/mapper/vg_splat-lv_log 243G 177G 53G 78% /var/log

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

Также для самого процесса обновления системе понадобится минимум 13 GB нераспределенного места на жестком диске. Проверить его наличие можно командой:

[Expert@cp-sms:0]# pvs

Увидим приблизительно вот такой вывод:

PV VG Fmt Attr PSize PFree
/dev/sda3 vg_splat lvm2 a — 141.69G 43.69G

В данном случае у нас есть 43 GB. Ресурсов хватает. Можно приступать к обновлению.

Обновляем сервер управления Check Point SMS

Перед началом работ нужно сделать следующее:

Далее собираем информацию о сетевых интерфейсах, таблице маршрутизации и выгружаем конфигурацию GAIA:

Увеличиваем timeout SSH сессии до 8 часов. Тут как повезет: в зависимости от размеров экспортируемой базы может продолжаться от нескольких минут до нескольких часов. Для этого:

[Expert@HostName]# export TMOUT=3600 указываем новый timeout expert mode (в секундах), если поставить значение 0, то timeout будет выключен.

Подгружаем и монтируем установочный образ SMS. iso к виртуальной машине.

Перед следующим шагом ОБЯЗАТЕЛЬНО еще раз проверьте, что у вас достаточно нераспределенного места на жестком диске (напоминаю, нужно 13 GB).

Экспорт конфигурации и логов

Экспорт базы SmartEvent

Здесь нам понадобится заранее установленный SMS версии R80. Любой тестовый подойдет.

Обновление

Скачиваем образ и проходим Verifier. В случае необходимости устраняем несоответствия.

В результате должны увидеть вот такое сообщение:

Подключаемся к SMS по SSH и меняем shell нашего пользователя на /bin/bash/:

set user <имя пользователя> shell /bin/bash/

save config (в случае, если мы хотим оставить bin/bash/ как shell по умолчанию и после перезагрузки).

Увеличиваем timeout SSH сессии до 8 часов. Для этого:

[Expert@HostName]# export TMOUT=3600 указываем новый timeout expert mode (в секундах). Если поставить значение 0, то timeout будет выключен.

Наслаждаемся жизнью ближайшие пару часов. НЕ ОТКЛЮЧАЙТЕ SSH-СЕССИЮ во время процедуры. В конце процесс migrate выдаст либо сообщение об успешном завершении операции, либо ошибку.

Чек-лист проверок после обновления

Импорт базы SmartEvent

Обновляем кластер Check Point GW (Active/Backup)

Перед началом работ

Обновление

Чек-лист проверок после обновления

Заключение

В общем-то на этом моменте все – вы обновились.

У нас весь процесс занимал в среднем от 6 до 12 часов, в зависимости от размеров экспортируемых баз. Работы проводили две ночи: одна – для обновления SMS, вторая – для кластера.

Простоя трафика не было, несмотря на то, что все вышеупомянутые ошибки мы проверяли на себе.

Конечно, иногда могут возникнуть и совершенно новые трудности в процессе обновления, но это Check Point, и, как мы все знаем, всегда есть hotfix!