ProHoster > Blog > Administrimi > Po azhurnojmë Check Point nga R77.30 në 80.20

Po azhurnojmë Check Point nga R77.30 në 80.20

Po azhurnojmë Check Point nga R77.30 në 80.20

Në vjeshtën e vitit 2019, Check Point ndali mbështetje për versionet R77.XX, dhe ishte e nevojshme të përditësohej. Ka shumë informacione mbi ndryshimet mes versioneve, avantazhet dhe disavantazhet e kalimit në R80. Le të flasim më mirë për mënyrën se si të përditësojmë appliance virtuale Check Point (CloudGuard për VMware ESXi, Hyper-V, KVM Gateway NGTP) dhe çfarë mund të shkojë keq.

Kështu, kishim 2 inxhinierë CCSE, më shumë se një duzinë klastra virtualë Check Point R77.30, disa ambiente cloud, pak hotfix-e dhe një det të madh me lloj-lloj bug-esh, glitjesh dhe të ngjashme, të të gjitha ngjyrave dhe madhësive, përveç afateve shumë të ngushta. Le të fillojmë!

PĂ«rmbajtja:

PĂ«rgatitja
Përditësojmë serverin e menaxhimit
Përditësojmë klastra

Po azhurnojmë Check Point nga R77.30 në 80.20

Kjo është një infrastrukturë tipike cloud e klientit me Check Point virtual.

PĂ«rgatitja

Së pari, duhet të kontrollojmë mjaftueshmërinë e burimeve për përditësimin. Kërkesat minimale të rekomanduara për R80.20 tani duken kështu:

Device

CPU

RAM

HDD

Security Gateway

2 core

4 Gb

Nga 15 GB

SMS

2 core

6 Gb

—

Rekomandimet janë përshkruar në dokumentin CP_R80.20_GA_Release_Notes.

Por do të jemi realistë. Nëse në konfigurimin më minimal kjo është e mjaftueshme, siç e tregon praktika, zakonisht kemi aktivizuar inspektimin https, SmartEvent punon në SMS, etj., që sigurisht kërkon kapacitete krejt ndryshe. Por në përgjithësi, jo më të mëdha se për R77.30.

Por ka nuanca. Dhe ato lidhen, para se gjithash, me madhësinë e memorjes fizike. Shumë operacione gjatë procesit të përditësimit do të kërkojnë hapësirë në disk.

PĂ«r serverin e menaxhimit, madhĂ«sia e hapĂ«sirĂ«s sĂ« lirĂ« nĂ« disk do tĂ« varet shumĂ« nga volumi i log-eve aktuale (nĂ«se dĂ«shirojmĂ« t’i ruajmĂ« ato) dhe numri i Revision-eve tĂ« ruajtur tĂ« Database, megjithĂ«se ato nuk do na duhen shumĂ«. Sigurisht, pĂ«r nodet e klastri (nĂ«se nuk ruani log-et edhe lokal) kjo nuk ka rĂ«ndĂ«si. Ja se si mund tĂ« kontrolloni praninĂ« e hapĂ«sirĂ«s sĂ« nevojshme:

  1. Konektimi në Smart Management Server përmes ssh, kalimi në expert mode dhe futja e komandës:

    [Expert@cp-sms:0]# df -h

  2. Në daljen do të shohim diçka të tillë:

    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

  3. Tani na intereson ndarja /var/log

Keni parasysh se, në varësi të politikës së ruajtjes dhe fshirjes së skedarëve log, si dhe madhësisë së databazës së eksportuar, mund të nevojitet hapësirë më shumë. Nëse gjatë krijimit të arkivit hapësira e lirë bëhet më pak se ajo e cila është caktuar nga politika e ruajtjes së skedarëve log, sistemi do të fillojë të fshijë log-et e vjetra dhe nuk do t'i përfshijë ato në arkiv.

Gjithashtu, për procesin e përditësimit, sistemi do të kërkojë të paktën 13 GB hapësirë të pa atribuara në diskun e ngurtë. Mund ta kontrolloni praninë e saj me komandën:

[Expert@cp-sms:0]# pvs

Do të shohim diçka të tillë:

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

Në këtë rast kemi 43 GB. Burimet janë të mjaftueshme. Mund të fillojmë përditësimin.

Përditësojmë serverin e menaxhimit Check Point SMS

Para fillimit të punës duhet të bëni sa vijon:

  1. Instaloni paketën Migration Tools në serverin e menaxhimit. Për këtë, është e nevojshme të shkarkoni imazhin nga portali. Check Point.
  2. Ngarko arkivin në serverin e menaxhimit përmes WinSCP në dosjen /var/log/UpgradeR77.30_R80.20 (nëse është e nevojshme, krijoni më parë dosjen).
  3. Konektimi në serverin e menaxhimit përmes SSH dhe shkoni në dosjen me arkivin:cd /var/log/UpgradeR77.30_R80.20/
  4. Shkarko skedarin:tar -zxvf ./<emri i skedarit>.tgz
  5. Lëshojmë utilitarin pre_upgrade_verifier me komandën: ./pre_upgrade_verifier -p $FWDIR -c R77 -t R80.20
  6. Pas ekzekutimit të komandës do të formohet një raport mbi konfigurimet e papajtueshme. Ajo është e aksesueshme në adresën: /opt/CPsuite-R77/fw1/log/pre_upgrade_verification_report.(xls, html, txt). Më e lehtë është ta shkarkoni përmes SCP dhe ta shikoni përmes shfletuesit.
    Për të eliminuar të gjitha konfigurimet e papajtueshme, përdorni SK117237.
  7. Pas kĂ«saj, riktheni pĂ«r tĂ« ekzekutuar pĂ«rsĂ«ri utilitarin pre_upgrade_verifier, pĂ«r t’u siguruar se tĂ« gjitha arsyet e papajtueshmĂ«risĂ« janĂ« eliminuar.
  8. Pastaj, mbledhim informacion mbi ndërfaqet rrjetore, tabelën e rrugëve dhe shkarkojmë konfigurimin 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
  9. Shkarkoni skedarin e marrë përmes SCP.
  10. Bëni një snapshot në nivelin e virtualizimit.
  11. Rritni timeout-in e sesionit SSH deri në 8 orë. Këtu është si të veproni: në varësi të madhësisë së databazës së eksportuar, mund të zgjasë nga disa minuta deri në disa orë. Për këtë: 
    [Expert@HostName]# clish -c "show inactivity-timeout" shihni timeout-in aktual të clish,

    [Expert@HostName]# clish -c "set inactivity-timeout 720" caktoni një timeout të ri clish (në minuta),

    [Expert@HostName]# echo $TMOUT shihni timeout-in aktual të modit expert,

    [Expert@HostName]# export TMOUT=3600 caktoni një timeout të ri për modin expert (në sekonda), nëse caktoni vlerën 0, atëherë timeout-i do të shfuqizohet.

  12. Ngarko dhe montoni imazhin instalues SMS.iso në makinë virtuale.

    Para hapit tjetër, DOMOSDOSH që të kontrolloni përsëri nëse keni mjaft hapësirë të pa atribuara në diskun e ngurtë (duhet 13 GB). 

  13. Para fillimit të eksportit të konfiguracionit, ndryshoni skedarin e log-ut me komandën: fw logswitch

Eksporti i konfigurimeve dhe logëve

  1. Fillojmë utilitarin migrate_export për eksportimin e konfigurimeve. Për këtë, kalojmë në dosjen e krijuar më parë: cd /var/log/UpgradeR77.30_R80.20/ dhe përdorim urdhrin: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz

    apo

    kalojmë në dosjen: cd $FWDIR/bin/upgrade_tools/ dhe
    e fillojmë urdhrin nga aty: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz

  2. Marrim checksum nga arkiva: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
  3. Ruajmë vlerën e marrë në një shënim.
  4. Lidhemi me SMS përmes SCP dhe eksportojmë arkivën me konfigurimin në stacionin e punës. Sigurohuni të përdorni transferimin e skedarëve në formatin Binary.

Eksporti i bazës së të dhënave SmartEvent

KĂ«tu na nevojitet njĂ« SMS i instaluar paraprakisht nĂ« versionin R80. Çdo test do tĂ« bĂ«jĂ«. 

  1. Nga SMS na nevojitet skripti, i vendosur këtu:$RTDIR/bin/eva_db_backup.csh
  2. Përmes SCP ngarkohet skripti eva_db_backup.csh në dosjen: /var/log/UpgradeR77.30_R80.20/
  3. Lidhemi përmes SSH me SMS. Kopjojmë skedarin në dosjen: cp /var/log/UpgradeR77.30_R80.20/eva_db_backup.csh
    $RTDIR/bin/eva_db_backup.csh
  4. Ndryshojmë kodimin: dos2unix $RTDIR/bin/eva_db_backup.csh
  5. Shtojmë pronarin: chown -v admin:root $RTDIR/bin/eva_db_backup.csh
  6. Shtojmë të drejtat: chmod -v 0755 $RTDIR/bin/eva_db_backup.csh
  7. Fillojmë eksportimin e bazës SmartEvent: $RTDIR/bin/eva_db_backup.csh
  8. Eksportojmë skedaret e marra përmes SCP: $RTDIR/bin/-db-backup.backup dhe $RTDIR/bin/eventiaUpgrade.tar në stacionin e punës.

Përditësimi

  1. KalojmĂ« nĂ« WebUI GAIA SMS → CPUSE → Shfaq tĂ« gjitha paketat.
  2. Në rastin kur CPUSE jep një gabim lidhjeje me re, kontrolloni DGW, DNS dhe parametrat e Proxy.
  3. Nëse gjithçka është në rregull, dhe gabimi nuk zhduket, duhet të përditësoni CPUSE manualisht, duke iu referuar sk92449.
  4. Shkarkoni imazhin dhe kaloni Verifikuesi. Në rast nevoje, rregulloni mospërputhjet.

    Si rezultat, duhet të shihni këtë mesazh:

    Po azhurnojmë Check Point nga R77.30 në 80.20

  5. Zgjidhni R80.20 Instalimi i Ri dhe Përditësimi për Menaxhimin e Sigurisë.
  6. Kur instaloni përditësimin, zgjidhni Instalimin e Pastruar. Pas instalimit, sistemi do të ri-boot.
  7. Kaloni në First Time Wizard.
  8. Pas marrjes së aksesit, kontrolloni llogaritë.
  9. Lidhemi me SMS përmes SSH dhe ndryshojmë shell-in e përdoruesit tonë në /bin/bash/:

    set user shell /bin/bash

    save config (në rast se dëshirojmë të lëmë bin/bash si shellin e paracaktuar edhe pas ri-boot).

  10. Më pas lidhuni me SMS përmes SCP dhe në modin Binary transferoni arkivën me konfigurimin SMS_w_logs_export_r77_r80.tgz në dosjen /var/log/UpgradeR77.30_R80.20/
  11. Marrim checksum nga arkiva: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz dhe e krahasojmë me vlerën e mëparshme. Checksum duhet të përputhen.
  12. Rritni kohën e skadimit të seancës SSH në 8 orë. Për këtë:

    [Expert@HostName]# clish -c "show inactivity-timeout" shihni timeout-in aktual të clish,

    [Expert@HostName]# clish -c "set inactivity-timeout 720" caktoni një timeout të ri clish (në minuta),

    [Expert@HostName]# echo $TMOUT shihni timeout-in aktual të modit expert,

    [Expert@HostName]# export TMOUT=3600 specifikoni një kohë të re skadimi në modin expert (në sekonda). Nëse vendosni vlerën 0, atëherë skadimi do të fiket.

  13. Për importimin e konfigurimeve, fillojmë utilitarin migrate import. Për këtë, kalojmë në dosjen: cd $FWDIR/bin/upgrade_tools/dhe fillojmë importin: ./migrate import -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
    Shijoni jetĂ«n pĂ«r disa orĂ« tĂ« ardhshme. MOS E ÇMIMNI SEANCEN SSH gjatĂ« procedurĂ«s. NĂ« fund, procesi migrate do tĂ« japĂ« ose njĂ« mesazh pĂ«r pĂ«rfundim tĂ« suksesshĂ«m tĂ« operacionit, ose njĂ« gabim.

Kontroll lista pas përditësimit 

Disponueshmëria e burimeve.

  1. SIC me GW.
  2. Licencat. Nëse licencat shfaqen gabim ose nuk shfaqen në SMS, ekzekutoni urdhrin
  3. vsec_central_licence për shpërndarjen e licencave. Instalimi i politikës.
  4. Importi i bazës SmartEvent 

Aktivizoni bleydin SmartEvent.

  1. Lidhuni përmes WinSCP me SMS dhe në modin binary transferoni skedarët e eksportuar më parë
  2. -db-backup.backup eventiaUpgrade.tar dhe Filloni skriptin me urdhrin: në dosjen /var/log/UpgradeR77.30_R80.20/
  3. $RTDIR/bin/eventiaUpgrade.sh -upgrade /var/log/UpgradeR77.30_R80.20/eventiaUpgrade.tar Kontrolloni statusin:
  4. watch -n 10 eventiaUpgrade.sh Kontrolloni logët në SmartEvent.
  5. SON! Përditësoni klasterin Check Point GW (Active/Backup)

Para fillimit të punëve

Ruani konfigurimin GAIA nga çdo nyje të klasterit në një skedar, për këtë përdorni urdhrin:

  1. clish -c "show configuration" > ./.txt Eksportoni skedaret përmes WinSCP.
  2. Lidhuni me WebUI të dy nyjeve dhe kaloni në tab
  3. CPUSE → Shfaq tĂ« gjitha paketat. Gjeni paketĂ«n e pĂ«rditĂ«simeve pĂ«r versionin
  4. R80.20 Instalimi i Ri Shkarko., klikoni Kontrolloni që protokolli CCP funksionon në modalitetin
  5. Broadcast , për këtë futni urdhrin:cphaprob -a if Nëse është zgjedhur modaliteti
    , ndryshojeni me urdhrin: Multicastcphaconf set_ccp broadcast (urdhri ekzekutohet në çdo nyje). Caktoni Downtime për nyjet e përfshira në sistemin tuaj të monitorimit.
  6. Kontrolloni që në nivelin e virtualizimit janë aktivizuar parametrat
  7. Ndryshimi i Adresës MAC Transmetime të Dëshiruara dhe për rrjetin sync. Lidhuni përmes ssh me nyjën aktive dhe ekzekutoni urdhrin për monitorimin e gjendjes së klasterit:

Përditësimi

  1. watch -n 2 cphaprob stat Kthehuni në WebUI të nyjës Standby në tab
  2. CPUSE dhe për paketën e zgjedhur në filloni Shkarko. Analizoni raportin e Verifier. Nëse instalimi lejohet, kaloni më tej. Verifikuesi.
  3. Zgjidhni paketën
  4. dhe filloni Shkarko. . GjatĂ« procesit tĂ« Upgrade, sistemi do tĂ« ri-boot. Parametrat e GAIA ruhen. NĂ« momentin e ri-boot, ndiqni gjendjen e klasterit. Pas ngarkimit, statusi i nyjĂ«s sĂ« pĂ«rditĂ«suar duhet tĂ« kalojĂ« nĂ« READY. NĂ« disa raste, kemi hasur njĂ« moment, kur nyja e pa pĂ«rditĂ«suar kalonte nĂ« statusin Active Attention dhe ndalonte sĂ« shfaquri statusin e nyjĂ«s sĂ« pĂ«rditĂ«suar. Mos u shqetĂ«soni – njĂ« variant i tillĂ« Ă«shtĂ« gjithashtu i pranueshĂ«m. UpgradePas pĂ«rfundimit tĂ« pĂ«rditĂ«simit, hapni
  5. SmartDashboard. SmartDashboard.
  6. Hapnimë objektin e klasterit dhe ndryshojmë versionin e klasterit nga R77.30 në R80.20. Shtypim Ok. Nëse para ruajtjes së ndryshimeve shfaqet gabimi:
    Një gabim i brendshëm ka ndodhur. (Kodi: 0x8003001D, Nuk mund të aksesohet skedari për operacionin e shkruar),
    ndiqni SK119973. Pas kësaj, ruajmë ndryshimet dhe shtypim Instaloni Politikat.
  7. Në konfigurime hiqni markimin nga parametri Për klasteret e portave, nëse instalimi në një anëtar të klasterit dështon, mos e instaloni në atë klaster.
  8. Instalojmë politikën. Sistemi do të japë një gabim për nodën aktive, e cila nuk është përditësuar ende.
  9. Paradisim te nodi i përditësuar përmes ssh dhe ekzekutojmë komandën për monitorimin e gjendjes së klasterit: Kthehuni në WebUI të nyjës Standby në tab
  10. Paradisim te WebUI e nodës aktive dhe kalojmë në skedën Gjeni paketën e përditësimeve për versioninR80.20 Instalimi i Ri Shkarko., shtypim Kontrolloni që protokolli CCP funksionon në modalitetin
  11. Kontrolloni që në nivelin e virtualizimit janë aktivizuar parametrat
  12. Kthehemi te WebUI e nodës aktive në skedën dhe për paketën e zgjedhur në filloni Shkarko. Analizoni raportin e Verifier. Nëse instalimi lejohet, kaloni më tej. Verifikuesi.
  13. Zgjidhni paketën
  14. dhe filloni Shkarko. . GjatĂ« procesit tĂ« Upgrade, sistemi do tĂ« ri-boot. Parametrat e GAIA ruhen. NĂ« momentin e ri-boot, ndiqni gjendjen e klasterit. Pas ngarkimit, statusi i nyjĂ«s sĂ« pĂ«rditĂ«suar duhet tĂ« kalojĂ« nĂ« READY. NĂ« disa raste, kemi hasur njĂ« moment, kur nyja e pa pĂ«rditĂ«suar kalonte nĂ« statusin Active Attention dhe ndalonte sĂ« shfaquri statusin e nyjĂ«s sĂ« pĂ«rditĂ«suar. Mos u shqetĂ«soni – njĂ« variant i tillĂ« Ă«shtĂ« gjithashtu i pranueshĂ«m. PĂ«rditĂ«simi. NĂ« procesin e PĂ«rditĂ«simit, sistemi do tĂ« ri-ngarkohet. CilĂ«simet GAIA ruhen. NĂ« momentin e ri-ngarkimit, monitorojmĂ« gjendjen e klasterit te nodi tashmĂ« tĂ« pĂ«rditĂ«suar. Pas ri-ngarkimit, gjendja e klasterit te nodi i pĂ«rditĂ«suar do tĂ« ndryshojĂ« nga READY nĂ« ACTIVE.
  15. Kur të përfundojë procesi i Përditësimit, hapim SmartDashboard dhe vendosim politikën.

Disponueshmëria e burimeve.

  • DĂ«shmimi i ngjarjeve nĂ« SmartLog, gjendja e VPN-tunelĂ«ve.
  • CilĂ«simet GAIA.
  • Rikthimi i klasterit pas njĂ« testimi Failover.
  • Licencat dhe kontratat. NĂ« rast se licencat shfaqen gabimisht ose nuk shfaqen nĂ« SMS, ekzekutojmĂ« komandĂ«n. vsec_central_licence pĂ«r shpĂ«rndarjen e licencave.
  • CoreXL.
  • SecureXL.
  • Hotfix dhe CPinfo nĂ« dy node.

PĂ«rfundimi

NĂ« pĂ«rgjithĂ«si, nĂ« kĂ«tĂ« pikĂ«, gjithçka Ă«shtĂ« e mbyllur – jeni pĂ«rditĂ«suar.

Procesi ynë zgjati mesatarisht nga 6 deri në 12 orë, në varësi të madhësive të bazave të eksportuara. Punimet u zhvilluan gjatë dy netëve: një për përditësimin e SMS, tjetra për klasterin.

Nuk pati ndalim të trafikut, megjithëse të gjitha gabimet e përmendura më lart i provuam vetë.

Sigurisht, ndonjëherë mund të shfaqen edhe vështirësi krejtësisht të reja gjatë procesit të përditësimit, por kjo është Check Point, dhe, siç e dimë të gjithë, gjithmonë ka hotfix!

Ju urojmë natë të përshtatshme të zezë-rozë dhe përditësime!

Burimi: habr.com

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster