In het najaar van 2019 stopte Check Point met de ondersteuning van versies R77.XX en was een update nodig. Er is al veel gezegd over het verschil tussen de versies, de voor- en nadelen van het overstappen naar de R80. Laten we het beter hebben over hoe u de virtuele apparaten van Check Point (CloudGuard voor VMware ESXi, Hyper-V, KVM Gateway NGTP) daadwerkelijk kunt updaten en wat er mis kan gaan.
We hadden dus twee CCSE-ingenieurs, meer dan een dozijn virtuele Check Point R2-clusters, verschillende clouds, een paar hotfixes en een hele zee van verschillende bugs, glitches en zo, in alle kleuren en maten, en ook zeer strakke deadlines. Laten we gaan!
Inhoud:
Zo ziet de cloudinfrastructuur van een typische klant met virtueel Check Point eruit
Opleiding
De eerste stap is om te controleren of er voldoende bronnen zijn voor de update. De aanbevolen minimumvereisten voor R80.20 zien er momenteel als volgt uit:
Apparaat
CPU
RAM
HDD
Beveiligingsgateway
2 kern
4 Gb
Vanaf 15GB
SMS
2 kern
6 Gb
-
Aanbevelingen worden beschreven in het document .
Maar we zullen realistisch zijn. Als dit voldoende is in de meest minimale configuratie, dan hebben we, zoals de praktijk laat zien, meestal https-inspectie ingeschakeld, SmartEvent draait op sms, enz., Wat uiteraard totaal andere capaciteiten vereist. Maar over het algemeen niet meer dan voor R77.30.
Maar er zijn nuances. En ze hebben in de eerste plaats betrekking op de omvang van het fysieke geheugen. Voor veel handelingen direct tijdens het updateproces is ruimte op de harde schijf nodig.
Voor de beheerserver zal de grootte van de vrije schijfruimte sterk afhangen van het volume van de huidige logs (als we ze willen opslaan) en van het aantal opgeslagen databaserevisies, hoewel we ze niet langer in grote hoeveelheden nodig zullen hebben. Voor clusternodes (tenzij je logs ook lokaal opslaat) maakt dit uiteraard allemaal niet uit. Zo kunt u controleren of u over de benodigde ruimte beschikt:
- We maken via ssh verbinding met Smart Management Server, gaan naar de expertmodus en voeren het commando in:
[Expert@cp-sms:0]# df -h
- Aan de uitvoer zullen we zoiets als deze configuratie zien:
Bestandssysteemgrootte gebruikt Beschikbaar gebruik% Aangekoppeld
/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 - We zijn momenteel geïnteresseerd in de sectie / Var / log
Houd er rekening mee dat afhankelijk van het beleid voor het opslaan en verwijderen van oude logbestanden en de grootte van de geëxporteerde database mogelijk meer ruimte nodig is. Als er bij het maken van een archief minder vrije ruimte is dan gespecificeerd in het opslagbeleid voor logbestanden, zal het systeem beginnen met het wissen van oude logbestanden en deze NIET in het archief opnemen.
Voor het updateproces zelf heeft het systeem bovendien minimaal 13 GB niet-toegewezen ruimte op de harde schijf nodig. U kunt de aanwezigheid ervan controleren met het commando:
[Expert@cp-sms:0]# pvs
We zullen zoiets als dit zien:
PV VG Fmt Attr PSgrootte PGratis
/dev/sda3 vg_splat lvm2 a- 141.69G 43.69G
In dit geval hebben we 43 GB. Er zijn voldoende middelen. U kunt beginnen met updaten.
Updaten van de Check Point SMS-beheerserver
Voordat u met het werk begint, moet u het volgende doen:
- Installeer het Migration Tools-pakket op de beheerserver. Om dit te doen, moet u de afbeelding downloaden van de portal.
- Upload het archief via WinSCP naar de beheerserver in de map /var/log/UpgradeR77.30_R80.20 (maak indien nodig eerst een map aan).
- Maak via SSH verbinding met de beheerserver en ga naar de map met het archief:cd /var/log/UpgradeR77.30_R80.20/
- Pak het bestand uit:tar -zxvf ./<bestandsnaam>.tgz
- We starten het hulpprogramma pre_upgrade_verifier met de opdracht: ./pre_upgrade_verifier -p $FWDIR -c R77 -t R80.20
- Na uitvoering van de opdracht wordt er een rapport over incompatibele instellingen gegenereerd. Het is verkrijgbaar bij: /opt/CPsuite-R77/fw1/log/pre_upgrade_verification_report.(xls, html, txt). Handiger is om het via SCP te uploaden en via een browser te bekijken.
Gebruik om eventuele incompatibele instellingen op te lossen. - Voer vervolgens het hulpprogramma pre_upgrade_verifier opnieuw uit om er zeker van te zijn dat alle oorzaken van incompatibiliteit zijn geëlimineerd.
- Vervolgens verzamelen we informatie over netwerkinterfaces, de routeringstabel en uploaden we de GAIA-configuratie:
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 "toon configuratie" > /var/log/UpgradeR77.30_R80.20/cp-sms-config.txt - Upload het resulterende bestand via SCP.
- We maken een momentopname op virtualisatieniveau.
- We verhogen de time-out van de SSH-sessie naar 8 uur. Het hangt af van uw geluk: afhankelijk van de grootte van de geëxporteerde database kan dit enkele minuten tot enkele uren duren. Voor deze:
[Expert@HostName]# clish -c "toon inactiviteit-time-out" kijk naar de huidige time-out clish,[Expert@HostName]# clish -c "set inactivity-timeout 720" geef de nieuwe time-outclish op (in minuten),
[Expert@Hostnaam]# echo $TMOUT kijk naar de huidige time-out-expertmodus,
[Expert@Hostnaam]# export TMOUT=3600 specificeer de nieuwe time-outexpertmodus (in seconden). Als u de waarde instelt op 0, wordt de time-out uitgeschakeld.
- We downloaden en koppelen de SMS.iso-installatiekopie aan de virtuele machine.
Controleer vóór de volgende stap of u voldoende niet-toegewezen ruimte op uw harde schijf hebt (onthoud dat u 13 GB nodig heeft).
- Voordat u begint met het exporteren van de configuratie, wijzigt u het logbestand met de opdracht: fw logschakelaar
Configuratie en logboeken exporteren
- Voer het migratie_export-hulpprogramma uit om de configuratie te downloaden. Ga hiervoor naar de eerder gemaakte map: cd /var/log/UpgradeR77.30_R80.20/ en gebruik het commando: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
of
ga naar de map: cd $FWDIR/bin/upgrade_tools/ и
voer vanaf daar de opdracht uit: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz - We verwijderen de controlesom uit het archief: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
- Sla de resulterende waarde op in Kladblok.
- We maken verbinding met SMS via SCP en uploaden het archief met de configuratie naar het werkstation. Zorg ervoor dat u bestandsoverdracht in binair formaat gebruikt.
SmartEvent-database exporteren
Hier hebben we de vooraf geïnstalleerde SMS-versie R80 nodig. Elke test is voldoende.
- Van SMS hebben we een script nodig dat zich hier bevindt:$RTDIR/bin/eva_db_backup.csh
- Laad het script via SCP eva_db_backup.csh naar map: /var/log/UpgradeR77.30_R80.20/
- Maak verbinding via SSH met sms. Bestand naar map kopiëren: cp /var/log/UpgradeR77.30_R80.20/eva_db_backup.csh
$RTDIR/bin/eva_db_backup.csh - De codering wijzigen: dos2unix $RTDIR/bin/eva_db_backup.csh
- De eigenaar toevoegen: chown -v beheerder:root $RTDIR/bin/eva_db_backup.csh
- Rechten toevoegen: chmod -v 0755 $RTDIR/bin/eva_db_backup.csh
- Laten we beginnen met het exporteren van de SmartEvent-database: $RTDIR/bin/eva_db_backup.csh
- Upload de ontvangen bestanden via SCP: $RTDIR/bin/<datum>-db-backup.backup и $RTDIR/bin/eventiaUpgrade.tar naar het werkstation.
Bijwerken
- Ga naar WebUI GAIA SMS → CPUSE → Toon alle pakketten.
- Als CPUSE een foutmelding geeft bij het verbinden met de Check Point-cloud, controleer dan de DGW-, DNS- en Proxy-instellingen.
- Als alles correct is en de fout niet verdwijnt, moet u CPUSE handmatig bijwerken, begeleid door.
- Download de afbeelding en ga door Verificateur. Indien nodig elimineren we inconsistenties.
Als gevolg hiervan zou u dit bericht moeten zien:
- kiezen R80.20 Nieuwe installatie en upgrade voor beveiligingsbeheer.
- Selecteer bij het installeren van de update Schone installatie. Na de installatie zal het systeem opnieuw opstarten.
- We slagen voor de eerste keer Wizard.
- Nadat wij toegang hebben verkregen, controleren wij de rekeningen.
- We maken verbinding met SMS via SSH en veranderen de shell van onze gebruiker in /bin/bash/:
stel gebruiker <gebruikersnaam> shell /bin/bash/ in
configuratie opslaan (voor het geval we bin/bash/ als standaardshell willen laten na het opnieuw opstarten).
- Vervolgens maken we via SCP verbinding met SMS en dragen we het archief over met de configuratie in binaire modus SMS_w_logs_export_r77_r80.tgz naar map /var/log/UpgradeR77.30_R80.20/
- We verwijderen de controlesom uit het archief: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz en vergelijk met de vorige waarde. Controlesom moet overeenkomen.
- We verhogen de time-out van de SSH-sessie naar 8 uur. Voor deze:
[Expert@HostName]# clish -c "toon inactiviteit-time-out" kijk naar de huidige time-out clish,
[Expert@HostName]# clish -c "set inactivity-timeout 720" geef de nieuwe time-outclish op (in minuten),
[Expert@Hostnaam]# echo $TMOUT kijk naar de huidige time-out-expertmodus,
[Expert@Hostnaam]# export TMOUT=3600 geef de nieuwe time-outexpertmodus op (in seconden). Als u de waarde instelt op 0, wordt de time-out uitgeschakeld.
- Om instellingen te importeren, voert u het migratie-importhulpprogramma uit. Ga hiervoor naar de map: cd $FWDIR/bin/upgrade_tools/en voer de import uit: ./migreren imp
ort -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
Laten we de komende uren van het leven genieten. ONTKOPPEL UW SSH-SESSIE NIET tijdens de procedure. Aan het einde zal het migratieproces een succesbericht of een fout weergeven.
Controlelijst na update
- Beschikbaarheid van hulpbronnen.
- SIC met GW.
- Licenties. Als licenties onjuist worden weergegeven of niet worden weergegeven op SMS, voert u de opdracht uit vsec_central_licence voor licentieverdeling.
- Het beleid instellen.
SmartEvent-database importeren
- Activeer de SmartEvent-blade.
- We maken via WinSCP verbinding met sms en dragen eerder gedownloade bestanden over in binaire modus <datum>-db-backup.backup и eventiaUpgrade.tar naar map /var/log/UpgradeR77.30_R80.20/
- We voeren het script uit met het commando: $RTDIR/bin/eventiaUpgrade.sh -upgrade /var/log/UpgradeR77.30_R80.20/eventiaUpgrade.tar
- De status controleren: bekijk -n 10 eventiaUpgrade.sh
- Het controleren van de logboeken in SmartEvent. DROOM!
Het Check Point GW-cluster bijwerken (actief/back-up)
Voordat u met het werk begint
- We slaan de GAIA-configuratie van elk clusterknooppunt op in een bestand. Gebruik hiervoor de opdracht: clish -c "toon configuratie" > ./<Bestandsnaam>.txt
- Bestanden uploaden met WinSCP.
- Maak verbinding met de WebUI van beide knooppunten en ga naar het tabblad CPUSE → Toon alle pakketten.
- Het updatepakket voor de versie zoeken R80.20 Nieuwe installatie, druk op Downloaden.
- We controleren of het CCP-protocol in de modus werkt UitzendingVoer hiervoor het commando in: cphaprob -a als
Als de modus is geselecteerd multicast, vervang het door het commando: cphaconf set_ccp uitzending (de opdracht wordt op elk knooppunt uitgevoerd). - Wij installeren Downtime voor de betrokken knooppunten in uw monitoringsysteem.
- We controleren of de parameters zijn ingeschakeld op virtualisatieniveau MAC-adres wijzigen и Gesmede transmissies voor een synchronisatienetwerk.
Bijwerken
- We maken via ssh verbinding met het actieve knooppunt en voeren de opdracht uit om de status van het cluster te controleren: bekijk -n 2 cphaprob stat
- Keer terug naar het tabblad WebUI Stanby-knooppunten CPUSE en voor het geselecteerde pakket R80.20 Nieuwe installatie launch Verificateur.
- Laten we het Verifier-rapport analyseren. Als installatie is toegestaan, ga dan verder.
- Selecteer een pakket R80.20 Nieuwe installatie en loop Upgrade. Tijdens het upgradeproces wordt het systeem opnieuw opgestart. GAIA-instellingen worden opgeslagen. Op het moment van opnieuw opstarten controleren we de status van het cluster. Na het laden moet de status van het bijgewerkte knooppunt veranderen in KLAAR. In een aantal gevallen kwamen we een moment tegen waarop een nog niet bijgewerkte node overschakelde naar de status Actieve Aandacht en niet langer de status van de bijgewerkte node weergaf. Wees niet ongerust: deze optie is ook acceptabel.
- Zodra de update is voltooid, opent u SmartDashboard.
- Open het clusterobject en wijzig de clusterversie van R77.30 in R80.20. Klik OK. Als er een foutmelding verschijnt bij het opslaan van wijzigingen:
Een interne fout is opgetreden. (Code: 0x8003001D, Kon geen toegang krijgen tot bestand voor schrijfbewerking),
volgen. Sla daarna de wijzigingen op en klik Beleid installeren. - Schakel in de instellingen de optie uit Als de installatie op een clusterlid mislukt, mag u bij gatewayclusters niet op dat cluster installeren.
- Wij hebben het beleid bepaald. Het systeem genereert een fout voor een actief knooppunt dat nog niet is bijgewerkt.
- We maken via ssh verbinding met het bijgewerkte knooppunt en voeren de opdracht uit om de status van het cluster te controleren: bekijk -n 2 cphaprob stat
- Maak verbinding met het WebUI Active-knooppunt en ga naar het tabblad CPUSE → Toon alle pakketten.Het updatepakket voor de versie zoeken R80.20 Nieuwe installatie, Klik Downloaden.
- Wij installeren Downtime voor de betrokken knooppunten in uw monitoringsysteem.
- Keer terug naar het tabblad Actieve knooppunten van WebUI CPUSE en voor het geselecteerde pakket R80.20 Nieuwe installatie launch Verificateur.
- Laten we het Verifier-rapport analyseren. Als installatie is toegestaan, ga dan verder.
- Selecteer een pakket R80.20 Nieuwe installatie en loop Upgrade. Tijdens het upgradeproces wordt het systeem opnieuw opgestart. GAIA-instellingen worden opgeslagen. Op het moment van opnieuw opstarten controleren we de status van het cluster op het reeds bijgewerkte knooppunt. Na het opnieuw opstarten verandert de clusterstatus op het bijgewerkte knooppunt van READY in ACTIVE.
- Wanneer het upgradeproces is voltooid, start u SmartDashboard en stelt u het beleid in.
Controlelijst na update
- Gebeurtenislogboeken in SmartLog, status van VPN-tunnels.
- GAIA-instellingen.
- Een cluster herstellen na een testfailover.
- Licenties en contracten. Als licenties onjuist worden weergegeven of niet worden weergegeven op SMS, voert u de opdracht uit. vsec_central_licence voor licentiedistributie.
- KernXL.
- SecureXL.
- Hotfix en CPinfo op twee knooppunten.
Conclusie
Over het algemeen is dat alles op dit punt: u bent op de hoogte gehouden.
Voor ons duurde het hele proces gemiddeld 6 tot 12 uur, afhankelijk van de grootte van de geëxporteerde databases. De werkzaamheden duurden twee nachten: één voor het updaten van SMS, de tweede voor het cluster.
Er was geen verkeersonderbreking, ondanks het feit dat we alle bovengenoemde fouten zelf hadden gecontroleerd.
Natuurlijk kunnen er soms compleet nieuwe problemen optreden tijdens het updateproces, maar dit is Check Point en zoals we allemaal weten is er altijd een hotfix!
Fijne zwarte en roze nachten en updates!
Bron: www.habr.com