Geekly articles weekly

Aktualisieren Sie Check Point von R77.30 auf 80.20



Im Herbst 2019 unterstützte Check Point die R77.XX-Versionen nicht mehr und musste aktualisiert werden. Über den Unterschied zwischen den Versionen, die Vor- und Nachteile des Übergangs zum R80 wurde bereits viel gesprochen. Lassen Sie uns darüber sprechen, wie der Check Point der virtuellen Appliance (CloudGuard für VMware ESXi, Hyper-V, KVM-Gateway-NGTP) tatsächlich aktualisiert wird und was schief gehen könnte.

Wir hatten also 2 CCSE-Ingenieure, mehr als ein Dutzend virtueller Cluster, Check Point R77.30, mehrere Wolken, ein paar Hotfixes und eine Menge verschiedener Bugs, Pannen und so weiter, alle Farben und Größen und auch sehr enge Fristen. Lass uns gehen!
Inhalt:

Vorbereitung
Aktualisieren des Verwaltungsservers
Aktualisieren des Clusters



So sieht eine typische Client-Cloud-Infrastruktur mit virtuellem Check Point aus

Vorbereitung


Zunächst müssen Sie prüfen, ob die Ressourcen für das Update ausreichen. Die empfohlenen Mindestanforderungen für R80.20 sehen jetzt so aus:

Gerät
CPU
RAM
HDD
Sicherheitsgateway
2 Kern
4 gb
Ab 15 GB
SMS
2 Kern
6 gb
-

Empfehlungen sind in CP_R80.20_GA_Release_Notes beschrieben .

Aber wir werden realistisch sein. Wenn dies in der minimalsten Konfiguration ausreicht, haben wir, wie die Praxis zeigt, normalerweise die https-Prüfung aktiviert, SmartEvent funktioniert für SMS usw., was natürlich völlig andere Kapazitäten erfordert. Insgesamt aber nicht größer als beim R77.30.

Aber es gibt Nuancen. Dabei geht es vor allem um die Größe des physischen Gedächtnisses. Viele Vorgänge direkt während des Aktualisierungsvorgangs erfordern Festplattenspeicher.

Bei einem Verwaltungsserver hängt die Menge des freien Speicherplatzes sehr stark von der Menge der aktuellen Protokolle (wenn diese gespeichert werden sollen) und von der Anzahl der gespeicherten Datenbankrevisionen ab, obwohl sie nicht in großem Umfang benötigt werden. Für Cluster-Knoten ist dies natürlich egal (es sei denn, Sie speichern Protokolle auch lokal). So überprüfen Sie, ob Sie über den richtigen Speicherplatz verfügen:

  1. Wir stellen über ssh eine Verbindung zum Smart Management Server her, wechseln in den Expertenmodus und geben den folgenden Befehl ein:

    [Experte @ cp-sms: 0] # df -h
  2. Am Ausgang sehen wir so etwas wie diese Konfiguration:

    Verwendete Dateisystemgröße Verfügbarkeit Verwendung% Aktiviert am
    / dev / mapper / vg_splat-lv_current 30G 7.4G 21G 27% /
    / dev / sda1 289 M 24 M 251 M 9% / boot
    tmpfs 2,0G 0 2,0G 0% / dev / shm
    / dev / mapper / vg_splat-lv_log 243G 177G 53G 78% / var / log
  3. Derzeit interessieren wir uns für den Abschnitt / var / log

Beachten Sie, dass abhängig von der Richtlinie zum Speichern und Löschen alter Protokolldateien sowie der Größe der exportierten Datenbank möglicherweise mehr Speicherplatz erforderlich ist. Wenn beim Erstellen des Archivs der freie Speicherplatz geringer wird als in der Richtlinie zum Speichern von Protokolldateien angegeben, löscht das System die alten Protokolle und nimmt sie NICHT in das Archiv auf.

Für den eigentlichen Aktualisierungsvorgang benötigt das System mindestens 13 GB nicht zugewiesenen Speicherplatz auf der Festplatte. Sie können das Vorhandensein mit dem folgenden Befehl überprüfen:

[Expert @ cp-sms: 0] # pvs

Wir werden ungefähr die folgende Schlussfolgerung sehen:

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

In diesem Fall haben wir 43 GB. Es gibt genug Ressourcen. Sie können mit der Aktualisierung beginnen.

Aktualisieren von Check Point SMS Management Server


Bevor Sie mit der Arbeit beginnen, gehen Sie wie folgt vor:

  1. Installieren Sie das Migrationstools-Paket auf dem Verwaltungsserver. Dazu müssen Sie das Bild vom Check Point- Portal hochladen.
  2. Laden Sie das Archiv über WinSCP im Ordner /var/log/UpgradeR77.30_R80.20 auf den Verwaltungsserver herunter (erstellen Sie ggf. zuerst einen Ordner).
  3. Wir stellen über SSH eine Verbindung zum Verwaltungsserver her und wechseln in den Archivordner : cd /var/log/UpgradeR77.30_R80.20/
  4. Entpacken Sie die Datei: tar -zxvf ./ <Dateiname> .tgz
  5. Wir starten das Dienstprogramm pre_upgrade_verifier mit dem folgenden Befehl: ./pre_upgrade_verifier -p $ FWDIR -c R77 -t R80.20
  6. Nach Abschluss des Befehls wird ein Bericht über inkompatible Einstellungen erstellt. Es ist verfügbar unter /opt/CPsuite-R77/fw1/log/pre_upgrade_verification_report.(xls, html, txt). Es ist bequemer, es über SCP zu entladen und über den Browser zu schauen.
    Verwenden Sie SK117237, um alle nicht kompatiblen Einstellungen zu entfernen .
  7. Führen Sie dann das Dienstprogramm pre_upgrade_verifier erneut aus, um sicherzustellen, dass alle Ursachen für die Inkompatibilität behoben wurden.
  8. Als Nächstes sammeln wir Informationen über Netzwerkschnittstellen, die Routing-Tabelle und laden die GAIA-Konfiguration hoch:
    ip a> /var/log/UpgradeR77.30_R80.20/cp-sms-config.txt
    ip r> /var/log/UpgradeR77.30_R80.20/cp-sms-config.txt
    Klicken Sie auf -c "Konfiguration anzeigen"> /var/log/UpgradeR77.30_R80.20/cp-sms-config.txt
  9. Laden Sie die empfangene Datei über SCP hoch.
  10. Wir machen Snapshots auf der Ebene der Virtualisierung.
  11. Wir erhöhen das Timeout der SSH-Sitzung auf 8 Stunden. So viel Glück: Abhängig von der Größe der exportierten Basis kann dies einige Minuten bis einige Stunden dauern. Dafür:
    [Expert @ HostName] # clish -c "Inaktivitäts- Timeout anzeigen " Den aktuellen Timeout-Clish anzeigen.

    [Expert @ HostName] # clish -c "set inactivity-timeout 720" legt eine neue Zeitüberschreitung fest (in Minuten),

    [Expert @ HostName] # echo $ TMOUT den aktuellen Timeout-Expertenmodus anzeigen,

    [Expert @ HostName] # export TMOUT = 3600 Geben Sie einen neuen Timeout-Expertenmodus an (in Sekunden). Wenn Sie den Wert auf 0 setzen, wird das Timeout deaktiviert .
  12. Wir laden das SMS.iso-Installationsimage und hängen es an die virtuelle Maschine an.

    Vergewissern Sie sich vor dem nächsten Schritt erneut, dass auf Ihrer Festplatte genügend nicht zugewiesener Speicherplatz vorhanden ist (ich erinnere Sie daran, dass Sie 13 GB benötigen).
  13. Bevor Sie mit dem Export der Konfiguration beginnen, ändern Sie die Protokolldatei mit dem Befehl: fw logswitch

Konfiguration und Protokolle exportieren

  1. Führen Sie das Dienstprogramm migrate_export aus, um die Konfiguration zu entladen. Wechseln Sie dazu in den zuvor erstellten Ordner: cd /var/log/UpgradeR77.30_R80.20/ und verwenden Sie den Befehl: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz

    entweder

    Wechseln Sie in den Ordner: cd $ FWDIR / bin / upgrade_tools / und
    Führen Sie den folgenden Befehl aus: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz

    Wenn die exportierte Basis groß ist, kann der Vorgang mehrere Stunden dauern.
    Trennen Sie die SSH-Sitzung während des Vorgangs nicht.

    Dabei zeigt GAIA folgende Meldung an:

    Sie können sicher für Kaffee und Mittagessen gehen.

    Nachdem wir entweder eine Fehlermeldung wie diese sehen:



    Oder eine Nachricht über den erfolgreichen Abschluss des Vorgangs:



    Wenn der Vorgang bereits einige Stunden dauert, können Sie ihn überprüfen. Richten Sie eine parallele Sitzung über ssh ein, ohne die aktuelle Sitzung zu trennen, und geben Sie den Befehl top ein. Unter den Prozessen sollte der Migrationsprozess angezeigt werden .

    Wenn Sie die SSH-Sitzung in keiner Weise trennen möchten, verwenden Sie: yes | nohup ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz

    In diesem Fall können Sie die Sitzung trennen, es ist jedoch unpraktisch, den Fortschritt zu überwachen: Sie müssen den Abschluss des Vorgangs mit dem Befehl top überprüfen, und im Falle eines Problems wird keine Fehlermeldung angezeigt. Daher empfehlen wir diese Option.
  2. Entfernen Sie die Prüfsumme aus dem Archiv: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
  3. Wir speichern den empfangenen Wert in einem Notizbuch.
  4. Wir verbinden uns per SCP mit SMS und laden das Archiv mit der Konfiguration auf die Workstation hoch. Stellen Sie sicher, dass Sie die Dateiübertragung im Binärformat verwenden.

Exportieren Sie die SmartEvent-Datenbank

Hier benötigen wir eine vorinstallierte SMS-Version R80. Jeder Test wird ausreichen.

  1. Für SMS benötigen wir ein Skript, das sich hier befindet: $ RTDIR / bin / eva_db_backup.csh
  2. Laden Sie über SCP das Skript eva_db_backup.csh in den Ordner: /var/log/UpgradeR77.30_R80.20/
  3. Wir verbinden uns via SSH mit SMS. Kopieren Sie die Datei in den Ordner: cp /var/log/UpgradeR77.30_R80.20/eva_db_backup.csh
    $ RTDIR / bin / eva_db_backup.csh
  4. Ändern Sie die Codierung: dos2unix $ RTDIR / bin / eva_db_backup.csh
  5. Besitzer hinzufügen : chown -v admin: root $ RTDIR / bin / eva_db_backup.csh
  6. Berechtigungen hinzufügen : chmod -v 0755 $ RTDIR / bin / eva_db_backup.csh
  7. Wir starten den Export der SmartEvent-Basis: $ RTDIR / bin / eva_db_backup.csh
  8. Wir laden die empfangenen Dateien über SCP: $ RTDIR / bin / <Datum> -db-backup.backup und $ RTDIR / bin / eventiaUpgrade.tar auf die Workstation hoch .

Update

  1. Gehen Sie zu WebUI GAIA SMS → CPUSE → Alle Pakete anzeigen.
  2. In dem Fall, dass CPUSE einen Connect Point-Cloud-Verbindungsfehler generiert, überprüfen wir die DGW-, DNS- und Proxy-Einstellungen.
  3. Wenn alles in Ordnung ist, der Fehler jedoch weiterhin auftritt, müssen Sie CPUSE manuell aktualisieren, indem Sie sich an sk92449 orientieren .
  4. Laden Sie das Bild herunter und gehen Sie durch Verifier. Beseitigen Sie gegebenenfalls Inkonsistenzen.

    Infolgedessen sollte diese Meldung angezeigt werden:

  5. Wählen Sie R80.20 Fresh Install and Upgrade für Security Management.
  6. Wählen Sie bei der Installation des Updates die Option "Neuinstallation". Nach der Installation wird das System neu gestartet.
  7. Wir bestehen den First Time Wizard.
  8. Nachdem wir Zugriff erhalten haben, überprüfen wir die Konten.
  9. Wir stellen über SSH eine Verbindung zu SMS her und ändern unsere Benutzer-Shell in / bin / bash /:

    setze Benutzer <Benutzername> shell / bin / bash /

    Speichere die Konfiguration (falls wir bin / bash / als Standard-Shell lassen wollen und nach dem Neustart).
  10. Als nächstes verbinden wir uns über SCP mit SMS und übertragen im Binärmodus das Archiv mit der Konfiguration SMS_w_logs_export_r77_r80.tgz in den Ordner /var/log/UpgradeR77.30_R80.20/
  11. Wir entfernen die Prüfsumme aus dem Archiv: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz und vergleichen sie mit dem vorherigen Wert. Die Prüfsumme muss übereinstimmen.
  12. Wir erhöhen das Timeout der SSH-Sitzung auf 8 Stunden. Dafür:

    [Expert @ HostName] # clish -c "Inaktivitäts- Timeout anzeigen " Den aktuellen Timeout-Clish anzeigen.

    [Expert @ HostName] # clish -c "set inactivity-timeout 720" legt eine neue Zeitüberschreitung fest (in Minuten),

    [Expert @ HostName] # echo $ TMOUT den aktuellen Timeout-Expertenmodus anzeigen,

    [Expert @ HostName] # export TMOUT = 3600 gibt den neuen Timeout-Expertenmodus an (in Sekunden). Wenn Sie den Wert auf 0 setzen, wird das Timeout deaktiviert.
  13. Führen Sie zum Importieren der Einstellungen das Dienstprogramm zum Migrieren des Imports aus. Wechseln Sie dazu in den Ordner: cd $ FWDIR / bin / upgrade_tools / und führen Sie den Import aus: ./migrate imp
    ort -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz

Genieße das Leben für die nächsten paar Stunden. Trennen Sie die SSH-Sitzung während des Vorgangs nicht. Am Ende gibt der Migrationsprozess entweder eine Erfolgsmeldung oder einen Fehler zurück.

Checkliste nach Updates

  1. Verfügbarkeit von Ressourcen.
  2. SIC mit GW.
  3. Lizenzen Wenn die Lizenzen falsch oder nicht in SMS angezeigt werden, führen Sie den Befehl vsec_central_licence aus , um die Lizenzen zu verteilen.
  4. Richtlinieneinstellung.

SmartEvent-Datenbank importieren

  1. Aktivieren Sie das SmartEvent-Blade.
  2. Wir verbinden uns per WinSCP mit SMS und übertragen im Binärmodus die zuvor heruntergeladenen Dateien <date> -db-backup.backup und eventiaUpgrade.tar in den Ordner /var/log/UpgradeR77.30_R80.20/
  3. Wir starten das Skript mit dem Befehl: $ RTDIR / bin / eventiaUpgrade.sh -upgrade /var/log/UpgradeR77.30_R80.20/eventiaUpgrade.tar
  4. Überprüfen des Status: watch -n 10 eventiaUpgrade.sh
  5. Überprüfen Sie die Protokolle in SmartEvent. TRAUM!

Cluster Check Point GW aktualisieren (Aktiv / Backup)


Vor Arbeitsbeginn

  1. Wir speichern die GAIA-Konfiguration von jedem Knoten des Clusters in eine Datei. Verwenden Sie dazu den Befehl: clish -c "show configuration"> ./ <Dateiname> .txt
  2. Wir laden Dateien mit WinSCP hoch.
  3. Wir verbinden uns mit der WebUI beider Knoten und gehen zur Registerkarte CPUSE → Show all packages.
  4. Wir finden das Service Pack für Version R80.20 Fresh Install , klicken Sie auf Download.
  5. Wir prüfen, ob das CCP-Protokoll im Broadcast- Modus funktioniert, geben dazu den Befehl ein: cphaprob -a if
    Wenn der Multicast- Modus ausgewählt ist, ändern Sie ihn mit dem Befehl: cphaconf set_ccp broadcast (der Befehl wird auf jedem Knoten ausgeführt).
  6. Stellen Sie die Ausfallzeit für die beteiligten Knoten in Ihrem Überwachungssystem ein.
  7. Wir stellen sicher, dass auf der Virtualisierungsebene die Parameter MAC Address Change und Forged Transmits für das Synchronisierungsnetzwerk aktiviert sind.

Update

  1. Wir verbinden uns über ssh mit dem aktiven Knoten und führen den Befehl aus, um den Clusterstatus zu überwachen: watch -n 2 cphaprob stat
  2. Wir kehren zu den WebUI-Stanby-Knoten auf der Registerkarte CPUSE zurück und führen Verifier für das ausgewählte R80.20-Frischinstallationspaket aus .
  3. Wir analysieren den Verifier-Bericht. Wenn die Installation zulässig ist, fahren Sie fort.
  4. Wählen Sie das Paket R80.20 Fresh Install und führen Sie Upgrade aus . Während des Aktualisierungsprozesses wird das System neu gestartet. GAIA-Einstellungen werden gespeichert. Zum Zeitpunkt des Neustarts überwachen wir den Status des Clusters. Nach dem Laden sollte sich der Status des aktualisierten Knotens auf BEREIT ändern. In einigen Fällen hatten wir einen Moment, in dem ein noch nicht aktualisierter Knoten in den Status "Aktive Aufmerksamkeit" überging und den Status des aktualisierten Knotens nicht mehr anzeigte. Seien Sie nicht beunruhigt - diese Option ist auch gültig.
  5. Öffnen Sie nach Abschluss des Updates SmartDashboard.
  6. Öffnen Sie das Cluster-Objekt und ändern Sie die Cluster-Version von R77.30 auf R80.20. Klicken Sie auf OK. Wenn beim Speichern der Änderungen ein Fehler auftritt:
    Ein interner Fehler ist aufgetreten. (Code: 0x8003001D, Zugriff auf Datei für Schreibvorgang nicht möglich),
    Folgen Sie der SK119973 . Speichern Sie anschließend die Änderungen und klicken Sie auf Richtlinie installieren.
  7. Deaktivieren Sie in den Einstellungen den Parameter Für Gateway-Cluster. Wenn die Installation auf einem Cluster-Mitglied fehlschlägt, installieren Sie nicht auf diesem Cluster.
  8. Wir legen eine Politik fest. Das System gibt einen Fehler für den aktiven Knoten aus, der noch nicht aktualisiert wurde.
  9. Wir stellen über ssh eine Verbindung zum aktualisierten Knoten her und führen den Befehl aus, um den Clusterstatus zu überwachen: watch -n 2 cphaprob stat
  10. Wir stellen eine Verbindung zu den aktiven WebUI-Knoten her und wechseln zur Registerkarte CPUSE → Alle Pakete anzeigen. Wir finden das Service Pack für Version R80.20 Fresh Install , klicken Sie auf Download.
  11. Stellen Sie die Ausfallzeit für die beteiligten Knoten in Ihrem Überwachungssystem ein.
  12. Wir kehren zu den aktiven WebUI-Knoten auf der Registerkarte CPUSE zurück und führen Verifier für das ausgewählte R80.20-Frischinstallationspaket aus .
  13. Wir analysieren den Verifier-Bericht. Wenn die Installation zulässig ist, fahren Sie fort.
  14. Wählen Sie das Paket R80.20 Fresh Install und führen Sie Upgrade aus. Während des Aktualisierungsprozesses wird das System neu gestartet. GAIA-Einstellungen werden gespeichert. Zum Zeitpunkt des Neustarts überwachen wir den Status des Clusters auf einem bereits aktualisierten Knoten. Nach dem Neustart ändert sich der Clusterstatus auf dem aktualisierten Knoten von BEREIT in AKTIV.
  15. Starten Sie nach Abschluss des Aktualisierungsvorgangs SmartDashboard und installieren Sie die Richtlinie.

Checkliste nach Updates

  • Ereignisprotokolle in SmartLog, Status von VPN-Tunneln.
  • GAIA-Einstellungen.
  • Clusterwiederherstellung nach Testfailover.
  • Lizenzen und Verträge. Wenn die Lizenzen falsch angezeigt werden oder nicht in SMS angezeigt werden, führen Sie den Befehl aus. vsec_central_licence für die Lizenzverteilung.
  • CoreXL.
  • SecureXL.
  • Hotfix und CPinfo auf zwei Knoten.

Fazit

Im Allgemeinen ist zu diesem Zeitpunkt alles - Sie haben aktualisiert.

Unser gesamter Prozess dauerte im Durchschnitt 6 bis 12 Stunden, abhängig von der Größe der exportierten Datenbanken. Die Arbeit wurde für zwei Nächte durchgeführt: eine zum Aktualisieren von SMS, die zweite für den Cluster.

Es gab keine Verkehrsausfälle, obwohl wir alle oben genannten Fehler selbst überprüft haben.

Natürlich können während des Aktualisierungsvorgangs manchmal völlig neue Schwierigkeiten auftreten, aber dies ist Check Point, und wie wir alle wissen, gibt es immer einen Hotfix!

Viel Glück mit deinen rosa und rosa Nächten und Updates!

Source: https://habr.com/ru/post/de484170/

More articles:


All Articles