2019 őszén a Check Point leállította az R77.XX verziók támogatását, így frissíteni kellett. Már sokat beszéltek az verziók közötti különbségekről, az R80-ra való áttérés előnyeiről és hátrányairól. Inkább arról beszéljünk, hogyan lehet frissíteni a Check Point virtuális appliance-okat (CloudGuard for VMware ESXi, Hyper-V, KVM Gateway NGTP), és milyen problémák merülhetnek fel.
Tehát két CCSE mérnökünk volt, több mint egy tucat R77.30 virtuális klaszter, néhány felhő, egy kis hotfix, és egy hatalmas mennyiségű bökkenő, bug és hasonló, szinte minden színben és méretben, ráadásul nagyon szoros határidők. Induljunk!
Tartalom:
Így néz ki egy tipikus felhőinfrastruktúra a kliensnél egy virtuális Check Point-tal
Előkészületek
Első lépésként ellenőrizni kell az erőforrások elegendőségét a frissítéshez. Az R80.20-hoz ajánlott minimális követelmények most a következőképpen néznek ki:
Device
CPU
RAM
HDD
Security Gateway
2 mag
4 Gb
15 GB-tól
), és egy adminisztrátor konzol (
2 mag
6 Gb
—
Az ajánlások megtalálhatók a dokumentumban .
De legyünk realisták. Ha a legminimálisabb konfigurációban ez elegendő, a gyakorlat azonban azt mutatja, hogy általában engedélyezve van az https-ellenőrzés, a SmartEvent működik az SMS-en stb., ami természetesen teljesen más teljesítményt igényel. De a legtöbb esetben nem sokkal több, mint az R77.30-hoz.
De vannak árnyalatok. Ezek elsősorban a fizikai memória méretére vonatkoznak. Sok művelet közvetlenül a frissítési folyamat során helyet igényel a merevlemezen.
A kezelő szerver esetében a szabad lemezterület mérete erősen függ a jelenlegi naplófájlok mennyiségétől (ha meg akarjuk őket őrizni) és a megőrzött Database Revision-ok számától, bár ezekből nagy mennyiség már nem szükséges nekünk. Természetesen a klaszter csomópontjai számára (ha csak nem tárolja a naplókat helyben) ez mind nem számít. Így ellenőrizhetjük, hogy van-e elegendő hely:
- Csatlakozzunk a Smart Management Serverhez ssh-n keresztül, lépjünk be expert módban, és írjuk be a parancsot:
[Expert@cp-sms:0]# df -h
- A kimeneten körülbelül ilyen konfigurációt fogunk látni:
File rendszer Méret Használat Elérhető Használat% Csatlakoztatva
/dev/mapper/vg_splat-lv_current 30G 7.4G 21G 27% /
/dev/sda1 289M 24M 251M 9% /boot
Jelenleg minket a partíció érdekel
/dev/mapper/vg_splat-lv_log 243G 177G 53G 78% /var/log - Jelenleg a részleg iránt érdeklődünk /var/log
Figyelembe kell venni, hogy a tárolási és régi naplófájlok törlésének politikájától, valamint az exportált adatbázis méretétől függően több helyre lehet szükség. Ha az archívum létrehozásakor a szabad hely kevesebb lesz, mint ami a naplófájlok tárolási politikájában van megadva, a rendszer elkezdi törölni a régi naplókat, és NEM fogja őket beletenni az archívumba.
A rendszernek a frissítési folyamathoz legalább 13 GB nem használatban lévő lemezterületre van szüksége. Ennek ellenőrzésére használhatja a parancsot:
[Expert@cp-sms:0]# pvs
Körülbelül ilyen kimenetet fogunk látni:
PV VG Fmt Attr PSize PFree
/dev/sda3 vg_splat lvm2 a- 141.69G 43.69G
Ebben az esetben 43 GB áll rendelkezésünkre. A források elegendőek. Kezdhetjük a frissítést.
Frissítjük a Check Point SMS kezelő szervert
A munkálatok megkezdése előtt a következőket kell tennünk:
- Telepítjük a Migration Tools csomagot a kezelő szerverre. Ehhez le kell tölteni a képet a portálról..
- Feltöltjük az archívumot a kezelő szerverre a WinSCP-n keresztül a következő mappába: /var/log/UpgradeR77.30_R80.20 (ha szükséges, előtte létre kell hozni a mappát).
- Csatlakozunk a kezelő szerverhez SSH-n keresztül, és belépünk az archívum mappájába:cd /var/log/UpgradeR77.30_R80.20/
- Kicsomagoljuk a fájlt:tar -zxvf ./.tgz
- Futtatjuk a pre_upgrade_verifier eszközt a következő paranccsal: ./pre_upgrade_verifier -p $FWDIR -c R77 -t R80.20
- A parancs végrehajtása után jelentés készül az inkompatibilis beállításokról. Ez elérhető a következő címen: /opt/CPsuite-R77/fw1/log/pre_upgrade_verification_report.(xls, html, txt). Kényelmesebb a SCP-n keresztül letölteni, és böngészőn keresztül megnézni.
Az összes inkompatibilis beállítás eltávolításához használja a. - Ezután indítsa újra a pre_upgrade_verifier eszközt, hogy megbizonyosodjon róla, hogy az összes inkompatibilitási ok megszüntetésre került.
- Ezután gyűjtsön információt a hálózati interfészekről, az útvonal tábláról, és exportálja a GAIA konfigurációt:
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 - Az így kapott fájlt SCP-n keresztül exportáljuk.
- Snapshot-ot készítünk a virtualizációs szinten.
- Megnöveljük az SSH munkamenet időtúllépését 8 órára. Itt szerencse kérdése: az exportált adatbázis méretétől függően néhány perctől több óráig tarthat. Ehhez:
[Expert@HostName]# clish -c "show inactivity-timeout" ellenőrizzük az aktuális clish időtúllépést,[Expert@HostName]# clish -c "set inactivity-timeout 720" megjegyezzük az új clish időtúllépést (percekben),
[Expert@HostName]# echo $TMOUT ellenőrizzük az aktuális expert mód időtúllépést,
[Expert@HostName]# export TMOUT=3600 beállítjuk az új expert mód időtúllépést (másodpercekben), ha 0-t állítunk be, az időtúllépés ki lesz kapcsolva.
- Betöltjük és csatlakoztatjuk az SMS.iso telepítő képet a virtuális géphez.
A következő lépés előtt KÉRJÜK, ellenőrizze még egyszer, hogy elegendő szabad hely álljon rendelkezésre a merevlemezen (emlékeztetőül, szükséges: 13 GB).
- A konfiguráció exportálása előtt módosítsuk a naplófájlt a következő parancs segítségével: fw logswitch
Konfiguráció és naplók exportálása
- Futtassuk a migrate_export segédprogramot a konfiguráció kiadásához. Ehhez lépjünk a korábban létrehozott mappába: cd /var/log/UpgradeR77.30_R80.20/ és használjuk a következő parancsot: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
vagy
lépjünk a mappába: cd $FWDIR/bin/upgrade_tools/ és
indítsuk el innen a parancsot: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz - Készítsünk checksum-t az archívumról: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
- Mentse el a kapott értéket egy jegyzetfüzetbe.
- Csatlakozzunk az SMS-hez SCP-n keresztül, és töltsük le az archívumot a munkaállomásra. Kérjük, használja a fájlok átvitelét Bináris formátumban.
SmartEvent adatbázis exportálása
Ehhez szükség lesz egy előre telepített SMS verzióra, amely R80-as. Bármilyen tesztelhető verzió megfelelő.
- Az SMS-től szükség van a következő szkriptre:$RTDIR/bin/eva_db_backup.csh
- SCP-n keresztül töltse fel a szkriptet eva_db_backup.csh a mappába: /var/log/UpgradeR77.30_R80.20/
- Csatlakozzunk SSH-n keresztül az SMS-hez. Másolja a fájlt a mappába: cp /var/log/UpgradeR77.30_R80.20/eva_db_backup.csh
$RTDIR/bin/eva_db_backup.csh - Módosítsa a kódolást: dos2unix $RTDIR/bin/eva_db_backup.csh
- Adja hozzá a tulajdonost: chown -v admin:root $RTDIR/bin/eva_db_backup.csh
- Adja hozzá a jogokat: chmod -v 0755 $RTDIR/bin/eva_db_backup.csh
- Indítsuk el a SmartEvent adatbázis exportálását: $RTDIR/bin/eva_db_backup.csh
- Töltsük le az elkészített fájlokat SCP-n keresztül: $RTDIR/bin/-db-backup.backup és $RTDIR/bin/eventiaUpgrade.tar a munkaállomásra.
Frissítés
- Lépjünk a következőre WebUI GAIA SMS → CPUSE → Minden csomag megjelenítése.
- Ha a CPUSE kapcsolatot kér a Check Point felhőhöz, ellenőrizzük a DGW-t, a DNS-t és a Proxy beállításokat.
- Ha minden rendben van, és a hiba nem szűnik meg, szükséges a CPUSE kézi frissítése a következő szerint:.
- Töltse le a képet, és lépjen tovább. Ellenőrző. Szükség esetén távolítsa el az eltéréseket.
Az eredményként egy ilyen üzenetet kell látnunk:
- Kiválasztás R80.20 Friss telepítés és frissítés a biztonsági menedzsmenthez.
- Az frissítési folyamat során válassza a Tiszta telepítést. A telepítés után a rendszer újraindul.
- Lépjünk át az Első alkalommal varázslón.
- A hozzáférés megszerzése után ellenőrizzük a fiókokat.
- Csatlakozzunk SSH-n keresztül az SMS-hez, és módosítsuk a felhasználónk shell-jét a következőre:
set user shell /bin/bash/
save config (abban az esetben, ha a bin/bash-t alapértelmezett shell-ként szeretnénk megtartani újraindítás után).
- Ezután csatlakozzunk az SMS-hez SCP-n keresztül, és Bináris módban küldjük át az archívumot a konfigurációval kapcsolatban. SMS_w_logs_export_r77_r80.tgz tartalmát a mappába /var/log/UpgradeR77.30_R80.20/
- Készítsünk checksum-t az archívumról: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz és összehasonlítjuk a korábbi értékkel. A checksumnak egyeznie kell.
- Megnöveljük az SSH session timeout-ját 8 órára. Ehhez:
[Expert@HostName]# clish -c "show inactivity-timeout" ellenőrizzük az aktuális clish időtúllépést,
[Expert@HostName]# clish -c "set inactivity-timeout 720" megjegyezzük az új clish időtúllépést (percekben),
[Expert@HostName]# echo $TMOUT ellenőrizzük az aktuális expert mód időtúllépést,
[Expert@HostName]# export TMOUT=3600 megadjuk az új timeout-ot az expert mode-ban (másodpercekben). Ha 0-át állítunk be, a timeout le lesz tiltva.
- A beállítások importálásához futtassuk a migrate import segédprogramot. Ehhez lépjünk a mappába: cd $FWDIR/bin/upgrade_tools/és indítjuk az importálást: ./migrate imp
ort -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
Élvezzük az életet a következő pár órában. NE KAPCSOLJUK KI AZ SSH-SZESSZIÓNKAT a folyamat során. A migrate végén vagy sikeres üzenetet fog adni a művelet befejezéséről, vagy hibát.
Frissítési ellenőrző lista
- Az erőforrások elérhetősége.
- SIC a GW-vel.
- Licencék. Ha a licencek hibásan jelennek meg vagy nem jelennek meg az SMS-en, futtassuk a parancsot vsec_central_licence a licencek kiosztásához.
- A politika telepítése.
SmartEvent adatbázis importálása
- Aktiválja a SmartEvent blade-et.
- Csatlakozunk a SMS-hez WinSCP-n keresztül, és bináris módban továbbítjuk a korábban exportált fájlokat -db-backup.backup és eventiaUpgrade.tar tartalmát a mappába /var/log/UpgradeR77.30_R80.20/
- Futtassuk a scriptet a következő paranccsal: $RTDIR/bin/eventiaUpgrade.sh -upgrade /var/log/UpgradeR77.30_R80.20/eventiaUpgrade.tar
- Ellenőrizzük az állapotot: watch -n 10 eventiaUpgrade.sh
- Ellenőrizzük a naplókat a SmartEvent-ben. ALVÁS!
Frissítjük a Check Point GW klasztert (Aktív/Háttér)
A munkálatok megkezdése előtt
- Mentjük a GAIA konfigurációt minden klaszternode-ban egy fájlba, ehhez használjuk a következő parancsot: clish -c "show configuration" > ./.txt
- Exportáljuk a fájlokat WinSCP segítségével.
- Csatlakozunk a WebUI-hoz mindkét node-on, és lépjünk a fülre CPUSE → Minden csomag megtekintése.
- Keresünk frissítési csomagot a következő verzióhoz R80.20 Friss telepítés, kattintsunk Letöltés.
- Ellenőrizzük, hogy a CCP protokoll működik-e Broadcast, ehhez futtassuk a parancsot: cphaprob -a if
Ha a mód Multicast, változtassuk meg a parancs segítségével: cphaconf set_ccp broadcast (a parancsot minden node-on végrehajtjuk). - Állítsuk be a Downtime-ot az Ön rendszerének monitorozott node-jai számára.
- Ellenőrizzük, hogy a virtualizáció szintjén engedélyezve vannak a következő paraméterek MAC címváltoztatás és Hamisan továbbított csomagok a sync-hálózat számára.
Frissítés
- Csatlakozunk az Active-nodhoz SSH-n keresztül, és futtassuk a klaszter állapotának monitorozásához a parancsot: watch -n 2 cphaprob stat
- Visszatérünk a WebUI Stanby node-jához a fülre CPUSE és a választott csomagnál R80.20 Friss telepítés indítjuk Ellenőrző.
- Elemezzük a Verifier jelentést. Ha a telepítés engedélyezett, folytatjuk.
- Kiválasztjuk a csomagot R80.20 Friss telepítés és indítjuk FrissítésA frissítés során a rendszer újraindul. A GAIA beállítások megmaradnak. Az újraindítás során figyelemmel kísérjük a klaszter állapotát. Az új csomópont betöltése után a státusznak READY-re kell váltania. Bizonyos esetekben előfordult, hogy a még nem frissített csomópont Active Attention státuszba került, és leállította az új csomópont státuszának megjelenítését. Ne aggódjon – ez a lehetőség szintén megengedett.
- A frissítés befejezése után nyissuk meg SmartDashboard-ot.
- Nyissuk meg a klaszter objektumot, és változtassuk meg a klaszter verzióját R77.30-ról R80.20-ra. Kattintsunk az Ok-ra. Ha a módosítások mentésekor hibaüzenet jelenik meg:
Belső hiba történt. (Kód: 0x8003001D, Nem sikerült fájlhoz hozzáférni írási művelethez),
Kövesse. Ezután mentsük el a módosításokat, és kattintsunk a Telepítés politikája. - A beállítások között vegyük ki a pipát a következő paraméterről: A klaszterekhez való átjárók esetén, ha a telepítés egy klaszter tagon nem sikerül, akkor ne telepítsük azt a klaszterre.
- Telepítjük a politikát. A rendszer hibát ad az Active-nódnak, amely még nem lett frissítve.
- Csatlakozunk az új csomóponthoz SSH-n keresztül, és elindítjuk a klaszter állapotának megfigyelésére szolgáló parancsot: watch -n 2 cphaprob stat
- Csatlakozunk az Active-csomópont WebUI-jához, és átmegyünk a CPUSE → Minden csomag megtekintése.Keresünk frissítési csomagot a következő verzióhoz R80.20 Friss telepítésfülre, kattintsunk Letöltés.
- Állítsuk be a Downtime-ot az Ön rendszerének monitorozott node-jai számára.
- Visszatérünk az Active csomópont WebUI-jához, a CPUSE és a választott csomagnál R80.20 Friss telepítés indítjuk Ellenőrző.
- Elemezzük a Verifier jelentést. Ha a telepítés engedélyezett, folytatjuk.
- Kiválasztjuk a csomagot R80.20 Friss telepítés és indítjuk Frissítés. A frissítés folyamán a rendszer újraindul. A GAIA beállítások megmaradnak. Az új csomópont újraindítása alatt figyelemmel kísérjük a klaszter állapotát. Az újraindítás után a klaszter állapota a frissített csomóponton READY-ról ACTIVE-ra változik.
- Amikor a frissítési folyamat befejeződik, elindítjuk a SmartDashboard-ot és telepítjük a politikát.
Frissítési ellenőrző lista
- Eseménynaplók a SmartLog-ban, VPN-tunel állapot.
- GAIA beállítások.
- A klaszter helyreállítása a tesztelési Failover után.
- Licencék és szerződések. Ha a licencék helytelenül jelennek meg, vagy nem jelennek meg az SMS-en, futtassuk a vsec_central_licence parancsot a licencék elosztásához.
- CoreXL.
- SecureXL.
- Hotfix és CPinfo két csomóponton.
Zárás
Ezen a ponton minden rendben – frissítve lett.
A folyamat átlagosan 6-12 óráig tartott, az exportált adatbázisok méretétől függően. Két éjszakát dolgoztunk: az egyiket az SMS frissítésére, a másikat a klaszterre.
Nem volt forgalmi leállás, annak ellenére, hogy az összes fent említett hibát magunk is teszteltük.
Természetesen előfordulhatnak teljesen új nehézségek a frissítési folyamat során, de ez a Check Point, és ahogyan mindannyian tudjuk, mindig van hotfix!
Sikeres fekete-rózsaszín éjszakákat és frissítéseket kívánok!
Forrás: habr.com
