Weźmy pod uwagę, że w 2019 roku Check Point zaprzestał wsparcia dla wersji R77.XX, więc aktualizacja była konieczna. O różnicach między wersjami, zaletach i wadach przejścia na R80 już wiele napisano. Porozmawiajmy lepiej o tym, jak właściwie zaktualizować wirtualne urządzenia Check Point (CloudGuard dla VMware ESXi, Hyper-V, KVM Gateway NGTP) i co może pójść nie tak.
Mieliśmy dwóch inżynierów CCSE, ponad dziesięć wirtualnych klastrów Check Point R77.30, kilka chmur, trochę hotfixów i całe morze różnorodnych błędów, glitchów i tym podobnych, w różnych kolorach i rozmiarach, a także bardzo napięte terminy. Zaczynajmy!
Zawartość:
Tak wygląda typowa infrastruktura w chmurze klienta z wirtualnym Check Point
Przygotowanie
Najpierw musimy sprawdzić wystarczającą ilość zasobów do aktualizacji. Zalecane minimalne wymagania dla R80.20 wyglądają następująco:
Device
CPU
RAM
HDD
Security Gateway
2 rdzenie
4 Gb
Od 15 GB
SMS
2 rdzenie
6 Gb
—
Zalecenia są opisane w dokumencie .
Jednak bądźmy realistami. Jeśli w najminimalniejszej konfiguracji to wystarcza, to jak pokazuje praktyka, zwykle mamy włączoną inspekcję https, na SMS działa SmartEvent itd., co oczywiście wymaga zupełnie innych mocy. Ale ogólnie nie większych niż dla R77.30.
Jednak są pewne niuanse. Dotyczą one przede wszystkim rozmiarów pamięci fizycznej. Wiele operacji bezpośrednio w trakcie aktualizacji będzie wymagało miejsca na dysku twardym.
Dla serwera zarządzania rozmiar wolnej przestrzeni na dysku będzie bardzo mocno zależał od objętości obecnych logów (jeśli chcemy je zachować) i od liczby zapisanych rewizji bazy danych, chociaż te już w dużej ilości nam nie będą potrzebne. Oczywiście dla węzłów klastra (jeśli nie przechowujesz logów również lokalnie) nie ma to żadnego znaczenia. Oto jak można sprawdzić dostępność potrzebnego miejsca:
- Łączymy się z serwerem Smart Management przez ssh, wchodzimy w tryb expert i wprowadzamy polecenie:
[Expert@cp-sms:0]# df -h
- Na wyjściu zobaczymy mniej więcej taką konfigurację:
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
Obecnie interesuje nas partycja
/dev/mapper/vg_splat-lv_log 243G 177G 53G 78% /var/log - Нас в данный момент интересует раздел /var/log
Należy pamiętać, że w zależności od polityki przechowywania i usuwania starych logów, a także rozmiaru eksportowanej bazy, może być potrzebne więcej miejsca. Jeśli podczas tworzenia archiwum dostępne miejsce zmniejszy się poniżej wartości określonej w polityce przechowywania logów, system zacznie usuwać stare logi i NIE włączy ich do archiwum.
Ponadto do samego procesu aktualizacji systemu będzie potrzebne co najmniej 13 GB nieprzydzielonego miejsca na dysku twardym. Można to sprawdzić za pomocą polecenia:
[Expert@cp-sms:0]# pvs
Zobaczymy mniej więcej taki wynik:
PV VG Fmt Attr PSize PFree
/dev/sda3 vg_splat lvm2 a- 141.69G 43.69G
W tym przypadku mamy 43 GB. Zasobów wystarczy. Możemy przystąpić do aktualizacji.
Aktualizujemy serwer zarządzania Check Point SMS
Przed rozpoczęciem prac należy wykonać następujące kroki:
- Instalujemy pakiet Migration Tools na serwerze zarządzania. W tym celu należy pobrać obraz z portalu.
- Przesyłamy archiwum na serwer zarządzania za pomocą WinSCP do folderu /var/log/UpgradeR77.30_R80.20 (jeśli to konieczne, wcześniej utworzyć folder).
- Łączymy się z serwerem zarządzania przez SSH i przechodzimy do folderu z archiwum:cd /var/log/UpgradeR77.30_R80.20/
- Rozpakowujemy plik:tar -zxvf ./.tgz
- Uruchamiamy narzędzie pre_upgrade_verifier poleceniem: ./pre_upgrade_verifier -p $FWDIR -c R77 -t R80.20
- Po wykonaniu polecenia zostanie wygenerowany raport o niezgodnych konfiguracjach. Jest on dostępny pod adresem: /opt/CPsuite-R77/fw1/log/pre_upgrade_verification_report.(xls, html, txt). Wygodniej jest go pobrać przez SCP i przeglądać w przeglądarce.
Aby usunąć wszystkie niezgodne konfiguracje, użyj. - Następnie ponownie uruchom narzędzie pre_upgrade_verifier, aby upewnić się, że wszystkie przyczyny niezgodności zostały usunięte.
- Dalej zbieramy informacje o interfejsach sieciowych, tabeli routingu i eksportujemy konfigurację 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 - Eksportujemy otrzymany plik przez SCP.
- Robimy snapshot na poziomie wirtualizacji.
- Zwiększamy timeout sesji SSH do 8 godzin. To jest jak się trafi: w zależności od rozmiarów eksportowanej bazy może trwać od kilku minut do kilku godzin. W tym celu:
[Expert@HostName]# clish -c "show inactivity-timeout" sprawdzamy aktualny timeout clish,[Expert@HostName]# clish -c "set inactivity-timeout 720" ustawiamy nowy timeout clish (w minutach),
[Expert@HostName]# echo $TMOUT sprawdzamy aktualny timeout w trybie expert,
[Expert@HostName]# export TMOUT=3600 ustawiamy nowy timeout w trybie expert (w sekundach), jeśli ustawimy wartość 0, timeout będzie wyłączony.
- Podłączamy i montujemy obraz instalacyjny SMS.iso do maszyny wirtualnej.
Przed następnym krokiem, OBOWIĄZKOWO sprawdź jeszcze raz, czy masz wystarczającą ilość nieprzydzielonego miejsca na dysku twardym (przypominam, potrzebne jest 13 GB).
- Przed rozpoczęciem eksportu konfiguracji zmieniamy plik logów poleceniem: fw logswitch
Eksport konfiguracji i logów
- Uruchamiamy narzędzie migrate_export do wyeksportowania konfiguracji. W tym celu przechodzimy do wcześniej utworzonego folderu: cd /var/log/UpgradeR77.30_R80.20/ i używamy polecenia: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
lub
przechodzimy do folderu: cd $FWDIR/bin/upgrade_tools/ i
uruchamiamy stamtąd polecenie: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz - Zdejmujemy checksum z archiwum: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
- Zapisujemy uzyskaną wartość w notatniku.
- Łączymy się z SMS przez SCP i przesyłamy archiwum z konfiguracją na stację roboczą. Koniecznie użyj transmisji plików w formacie Binary.
Eksport bazy SmartEvent
Tutaj potrzebujemy wcześniej zainstalowanego SMS w wersji R80. Każda wersja testowa wystarczy.
- Od SMS potrzebujemy skryptu, który znajduje się tutaj:$RTDIR/bin/eva_db_backup.csh
- Przez SCP przesyłamy skrypt eva_db_backup.csh do folderu: /var/log/UpgradeR77.30_R80.20/
- Łączymy się przez SSH z SMS. Kopiujemy plik do folderu: cp /var/log/UpgradeR77.30_R80.20/eva_db_backup.csh
$RTDIR/bin/eva_db_backup.csh - Zmieniamy kodowanie: dos2unix $RTDIR/bin/eva_db_backup.csh
- Dodajemy właściciela: chown -v admin:root $RTDIR/bin/eva_db_backup.csh
- Dodajemy uprawnienia: chmod -v 0755 $RTDIR/bin/eva_db_backup.csh
- Uruchamiamy eksport bazy SmartEvent: $RTDIR/bin/eva_db_backup.csh
- Przesyłamy uzyskane pliki przez SCP: $RTDIR/bin/-db-backup.backup i $RTDIR/bin/eventiaUpgrade.tar na stację roboczą.
Aktualizacja
- Przechodzimy do WebUI GAIA SMS → CPUSE → Wyświetl wszystkie pakiety.
- W przypadku, gdy CPUSE zgłasza błąd połączenia z chmurą Check Point, sprawdzamy DGW, DNS i ustawienia Proxy.
- Jeśli wszystko jest poprawnie, a błąd nie znika, należy zaktualizować CPUSE ręcznie, korzystając z.
- Ściągamy obraz i przechodzimy Verifier. W razie potrzeby rozwiązujemy niezgodności.
W wyniku powinniśmy zobaczyć takie komunikat:
- Wybieramy R80.20 Świeża instalacja i aktualizacja dla zarządzania bezpieczeństwem.
- Podczas instalacji aktualizacji wybieramy Clean Install. Po instalacji system uruchomi się ponownie.
- Przechodzimy przez First Time Wizard.
- Po uzyskaniu dostępu sprawdzamy konta użytkowników.
- Łączymy się z SMS przez SSH i zmieniamy shell naszego użytkownika na /bin/bash/:
set user shell /bin/bash/
save config (jeśli chcemy pozostawić bin/bash/ jako shell domyślny także po restarcie).
- Następnie łączymy się z SMS przez SCP i w trybie Binary przesyłamy archiwum z konfiguracją SMS_w_logs_export_r77_r80.tgz do folderu /var/log/UpgradeR77.30_R80.20/
- Zdejmujemy checksum z archiwum: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz i porównujemy z wcześniejszą wartością. Suma kontrolna powinna być zgodna.
- Zwiększamy czas oczekiwania sesji SSH do 8 godzin. W tym celu:
[Expert@HostName]# clish -c "show inactivity-timeout" sprawdzamy aktualny timeout clish,
[Expert@HostName]# clish -c "set inactivity-timeout 720" ustawiamy nowy timeout clish (w minutach),
[Expert@HostName]# echo $TMOUT sprawdzamy aktualny timeout w trybie expert,
[Expert@HostName]# export TMOUT=3600 podajemy nowy czas oczekiwania w trybie eksperckim (w sekundach). Ustawienie wartości 0 wyłączy czas oczekiwania.
- Aby zaimportować ustawienia, uruchamiamy narzędzie migrate import. W tym celu przechodzimy do folderu: cd $FWDIR/bin/upgrade_tools/i uruchamiamy import: ./migrate imp
ort -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
Cieszmy się życiem przez najbliższe kilka godzin. NIE WYŁĄCZAJ SESJI SSH podczas procedury. Na koniec proces migrate wyda komunikat o pomyślnym zakończeniu operacji lub błąd.
Lista kontrolna po aktualizacji
- Dostępność zasobów.
- SIC z GW.
- Licencje. Jeśli licencje wyświetlają się niepoprawnie lub nie wyświetlają się na SMS, uruchamiamy polecenie vsec_central_licence do rozdzielania licencji.
- Konfiguracja polityki.
Import bazy SmartEvent
- Aktywuj moduł SmartEvent.
- Łączymy się przez WinSCP z SMS i w trybie binarnym przesyłamy wcześniej wyeksportowane pliki -db-backup.backup i eventiaUpgrade.tar do folderu /var/log/UpgradeR77.30_R80.20/
- Uruchamiamy skrypt poleceniem: $RTDIR/bin/eventiaUpgrade.sh -upgrade /var/log/UpgradeR77.30_R80.20/eventiaUpgrade.tar
- Sprawdzamy status: watch -n 10 eventiaUpgrade.sh
- Sprawdzamy logi w SmartEvent. SON!
Aktualizujemy klaster Check Point GW (Active/Backup)
Przed rozpoczęciem prac
- Zapisujemy konfigurację GAIA z każdej węzła klastra do pliku, w tym celu używamy polecenia: clish -c "show configuration" > ./.txt
- Eksportujemy pliki za pomocą WinSCP.
- Łączymy się z WebUI obu węzłów i przechodzimy do zakładki CPUSE → Pokaż wszystkie pakiety.
- Szukamy pakietu aktualizacji dla wersji R80.20 Fresh Install, klikamy Pobierz.
- Sprawdzamy, czy protokół CCP działa w trybie WBroadcast, w tym celu wprowadzamy polecenie: cphaprob -a if
Jeśli wybrano tryb Multicast, zmień go poleceniem: cphaconf set_ccp broadcast (polecenie wykonywane na każdym węźle). - Ustawiamy Downtime dla używanych węzłów w twoim systemie monitorowania.
- Sprawdzamy, czy na poziomie wirtualizacji włączone są parametry Zmiana adresu MAC i Fałszywe transmisje dla sieci synchronizacji.
Aktualizacja
- Łączymy się przez ssh z węzłem Active i uruchamiamy polecenie do monitorowania stanu klastra: watch -n 2 cphaprob stat
- Wracamy do WebUI węzła Standby na zakładkę CPUSE i dla wybranego pakietu R80.20 Fresh Install uruchamiamy Verifier.
- Analizujemy raport Verifier. Jeśli instalacja jest dozwolona, idziemy dalej.
- Wybieramy pakiet R80.20 Fresh Install i uruchamiamy AktualizacjaW trakcie aktualizacji system zostanie ponownie uruchomiony. Ustawienia GAIA zostają zachowane. W momencie ponownego uruchamiania monitorujemy stan klastra. Po załadowaniu status zaktualizowanego węzła powinien zmienić się na GOTOWY. W pewnych przypadkach mieliśmy sytuację, w której zaktualizowany węzeł przechodził w status Aktywna Uwaga i przestawał wyświetlać status zaktualizowanego węzła. Nie martwcie się – taka opcja jest również dopuszczalna.
- Po zakończeniu aktualizacji otwieramy SmartDashboard.
- Otwieramy obiekt klastra i zmieniamy wersję klastra z R77.30 na R80.20. Klikamy Ok. Jeśli podczas zapisywania zmian pojawia się błąd:
Wystąpił błąd wewnętrzny. (Kod: 0x8003001D, Nie można uzyskać dostępu do pliku w operacji zapisu),
postępuj zgodnie z. Następnie zapisujemy zmiany i klikamy Zainstaluj politykę. - W ustawieniach odznaczamy pole przy parametrze Dla klastrów bramowych, jeśli instalacja na członku klastra się nie powiedzie, nie instaluj na tym klastrze.
- Instalujemy politykę. System zgłosi błąd dla węzła aktywnego, który jeszcze nie został zaktualizowany.
- Łączymy się z zaktualizowanym węzłem przez ssh i uruchamiamy polecenie do monitorowania stanu klastra: watch -n 2 cphaprob stat
- Łączymy się z WebUI węzła aktywnego i przechodzimy do zakładki CPUSE → Pokaż wszystkie pakiety.Szukamy pakietu aktualizacji dla wersji R80.20 Fresh Install, klikamy Pobierz.
- Ustawiamy Downtime dla używanych węzłów w twoim systemie monitorowania.
- Wracamy do WebUI węzła aktywnego na zakładkę CPUSE i dla wybranego pakietu R80.20 Fresh Install uruchamiamy Verifier.
- Analizujemy raport Verifier. Jeśli instalacja jest dozwolona, idziemy dalej.
- Wybieramy pakiet R80.20 Fresh Install i uruchamiamy Aktualizacja. W trakcie aktualizacji system zostanie ponownie uruchomiony. Ustawienia GAIA zostają zachowane. W momencie ponownego uruchamiania monitorujemy stan klastra na już zaktualizowanym węźle. Po ponownym uruchomieniu stan klastra na zaktualizowanym węźle zmieni się z GOTOWY na AKTYWNY.
- Gdy proces aktualizacji się zakończy, uruchamiamy SmartDashboard i instalujemy politykę.
Lista kontrolna po aktualizacji
- Dzienniki zdarzeń w SmartLog, stan tuneli VPN.
- Ustawienia GAIA.
- Odzyskiwanie klastra po testowym Failover.
- Licencje i umowy. W przypadku, gdy licencje są wyświetlane nieprawidłowo lub nie są wyświetlane na SMS, uruchamiamy polecenie. vsec_central_licence w celu dystrybucji licencji.
- CoreXL.
- SecureXL.
- Hotfix i CPinfo na dwóch węzłach.
Podsumowanie
W sumie na tym etapie to wszystko – zaktualizowałeś się.
Cały proces zajmował nam średnio od 6 do 12 godzin, w zależności od rozmiarów eksportowanych baz. Prace przeprowadzaliśmy przez dwie noce: jedna – w celu aktualizacji SMS, druga – dla klastra.
Nie było żadnych przestojów w ruchu, mimo że wszystkie wyżej wymienione błędy sprawdzaliśmy na sobie.
Oczywiście, czasami mogą pojawić się zupełnie nowe trudności w trakcie aktualizacji, ale to Check Point, i jak wiemy, zawsze jest hotfix!
Życzymy udanych czarno-różowych nocy i aktualizacji!
Źródło: habr.com
