Mettre à jour Check Point de R77.30 à 80.20

À l'automne 2019, Check Point a cessé de prendre en charge les versions R77.XX et devait être mis à jour. On a déjà beaucoup parlé de la différence entre les versions, les avantages et les inconvénients du passage au R80. Voyons comment mettre à niveau le point de contrôle de l'appliance virtuelle (CloudGuard pour VMware ESXi, Hyper-V, KVM Gateway NGTP) et ce qui pourrait mal se passer.

Nous avons donc eu 2 ingénieurs CCSE, plus d'une douzaine de clusters virtuels Check Point R77.30, plusieurs nuages, quelques petits correctifs et toute une série de bugs, de bugs et tout ça, toutes les couleurs et tailles, et aussi des délais très serrés. C'est parti!

Contenu:

La préparation
Mise à jour du serveur de gestion
Mise à jour du cluster

Voici à quoi ressemble une infrastructure cloud client typique avec Check Point virtuel

La préparation

Tout d'abord, vous devez vérifier la suffisance des ressources pour la mise à jour. Les exigences minimales recommandées pour R80.20 ressemblent maintenant à ceci:


Les recommandations sont décrites dans CP_R80.20_GA_Release_Notes .

Mais nous serons réalistes. Si cela suffit dans la configuration la plus minimale, alors, comme le montre la pratique, nous avons généralement l'inspection https activée, SmartEvent fonctionne pour SMS, etc., ce qui, bien sûr, nécessite des capacités complètement différentes. Mais globalement pas plus grand que pour le R77.30.

Mais il y a des nuances. Et elles concernent tout d'abord les tailles de mémoire physique. De nombreuses opérations directement pendant le processus de mise à niveau nécessiteront de l'espace sur le disque dur.

Pour un serveur de gestion, la quantité d'espace disque disponible dépendra beaucoup du volume des journaux actuels (si nous voulons les enregistrer) et du nombre de révisions de base de données enregistrées, bien que nous n'en ayons pas besoin en grande quantité. Bien sûr, pour les nœuds de cluster (sauf si vous stockez également les journaux localement), tout cela n'a pas d'importance. Voici comment vérifier si vous avez le bon espace:

1. Nous nous connectons au Smart Management Server via ssh, passons en mode expert et entrons la commande:
   
   [Expert @ cp-sms: 0] # df -h
2. À la sortie, nous verrons quelque chose comme cette configuration:
   
   Taille du système de fichiers utilisée Utilisation disponible% monté
   / 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. Nous sommes actuellement intéressés par la section / var / log

Veuillez noter qu'en fonction de la politique de stockage et de suppression des anciens fichiers journaux, ainsi que de la taille de la base de données exportée, davantage d'espace peut être requis. Si lors de la création de l'archive, l'espace libre devient inférieur à celui indiqué dans la politique de stockage des fichiers journaux, le système commencera à effacer les anciens journaux et ne les inclura PAS dans l'archive.

De plus, pour le processus de mise à jour lui-même, le système aura besoin d'au moins 13 Go d'espace non alloué sur le disque dur. Vous pouvez vérifier sa présence avec la commande:

[Expert @ cp-sms: 0] # pvs

Nous verrons approximativement la conclusion suivante:

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

Dans ce cas, nous avons 43 Go. Il y a suffisamment de ressources. Vous pouvez commencer la mise à jour.

Mise à jour de Check Point SMS Management Server

Avant de commencer le travail, procédez comme suit:

1. Installez le package des outils de migration sur le serveur de gestion. Pour ce faire, vous devez télécharger l'image à partir du portail Check Point .
2. Téléchargez l'archive sur le serveur de gestion via WinSCP dans le dossier /var/log/UpgradeR77.30_R80.20 (si nécessaire, créez d'abord un dossier).
3. Nous nous connectons au serveur de gestion via SSH et allons dans le dossier d'archives: cd /var/log/UpgradeR77.30_R80.20/
4. Décompressez le fichier: tar -zxvf ./ <nom de fichier> .tgz
5. Nous démarrons l'utilitaire pre_upgrade_verifier avec la commande: ./pre_upgrade_verifier -p $ FWDIR -c R77 -t R80.20
6. Une fois la commande terminée, un rapport sur les paramètres incompatibles sera généré. Il est disponible sur /opt/CPsuite-R77/fw1/log/pre_upgrade_verification_report.(xls, html, txt). Il est plus pratique de le décharger via SCP et de le regarder via le navigateur.
   Pour éliminer tous les paramètres incompatibles, utilisez SK117237 .
7. Réexécutez ensuite l'utilitaire pre_upgrade_verifier pour vérifier que toutes les causes d'incompatibilité ont été résolues.
8. Ensuite, nous collectons des informations sur les interfaces réseau, la table de routage et téléchargeons la configuration 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 "afficher la configuration"> /var/log/UpgradeR77.30_R80.20/cp-sms-config.txt
9. Téléchargez le fichier reçu via SCP.
10. Nous faisons des instantanés au niveau de la virtualisation.
11. Nous augmentons le délai d'expiration de la session SSH à 8 heures. Voici la chance: selon la taille de la base exportée, elle peut durer de quelques minutes à plusieurs heures. Pour ce faire:
    [Expert @ HostName] # clish -c "afficher l'inactivité-timeout" regardez le time-out actuel clish,
    
    [Expert @ HostName] # clish -c "set inactivity-timeout 720" spécifiez un nouveau timeout clish (en minutes),
    
    [Expert @ HostName] # echo $ TMOUT regardez le mode expert de timeout actuel,
    
    [Expert @ HostName] # export TMOUT = 3600 spécifiez un nouveau mode expert de délai d'attente (en secondes), si vous définissez la valeur sur 0, le délai d'attente sera désactivé.
12. Nous chargeons et montons l'image d'installation SMS.iso sur la machine virtuelle.
    
    Avant l'étape suivante, assurez-vous de vérifier à nouveau que vous disposez de suffisamment d'espace non alloué sur votre disque dur (je vous rappelle que vous avez besoin de 13 Go).
    
13. Avant de commencer l'exportation de la configuration, nous modifions le fichier journal avec la commande: fw logswitch

Exporter la configuration et les journaux

1. Exécutez l'utilitaire migrate_export pour décharger la configuration. Pour ce faire, accédez au dossier créé précédemment: cd /var/log/UpgradeR77.30_R80.20/ et utilisez la commande: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
   
   soit
   
   allez dans le dossier: cd $ FWDIR / bin / upgrade_tools / et
   exécutez la commande à partir de là: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
   
   Si la base exportée est grande, la procédure peut prendre plusieurs heures.
   NE DÉBRANCHEZ PAS la SESSION SSH pendant la procédure.
   
   Dans le processus, GAIA affichera ce message:
   
   Vous pouvez aller en toute sécurité pour le café et le déjeuner.
   
   Après avoir vu un message d'erreur comme celui-ci:
   
   
   
   Ou un message sur la réussite de l'opération:
   
   
   
   Si le processus dure depuis quelques heures, vous pouvez le vérifier. Sans déconnecter la session en cours, configurez une session parallèle via ssh et entrez la commande supérieure. Parmi les processus, le processus de migration doit être affiché .
   
   Si sans déconnecter la session SSH de quelque façon que ce soit, utilisez: yes | nohup ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
   
   Dans ce cas, vous pouvez déconnecter la session, mais il sera gênant de surveiller la progression: vous devrez vérifier la fin du processus avec la commande top, et en cas de problème il n'y aura pas de message d'erreur. Par conséquent, nous recommandons fortement cette option.
2. Supprimer la somme de contrôle de l'archive: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
3. Nous enregistrons la valeur reçue dans un cahier.
4. Nous nous connectons à SMS via SCP et téléchargeons l'archive avec la configuration sur le poste de travail. Assurez-vous d'utiliser le transfert de fichiers au format binaire.

Exporter la base de données SmartEvent

Ici, nous avons besoin d'une version SMS pré-installée R80. N'importe quel test fera l'affaire.

1. Depuis SMS, nous avons besoin d'un script situé ici: $ RTDIR / bin / eva_db_backup.csh
2. Via SCP, chargez le script eva_db_backup.csh dans le dossier: /var/log/UpgradeR77.30_R80.20/
3. Nous nous connectons via SSH à SMS. Copiez le fichier dans le dossier: cp /var/log/UpgradeR77.30_R80.20/eva_db_backup.csh
   $ RTDIR / bin / eva_db_backup.csh
   
4. Changez l' encodage: dos2unix $ RTDIR / bin / eva_db_backup.csh
5. Ajouter le propriétaire: chown -v admin: root $ RTDIR / bin / eva_db_backup.csh
6. Ajouter des autorisations: chmod -v 0755 $ RTDIR / bin / eva_db_backup.csh
7. Nous commençons l'exportation de la base SmartEvent: $ RTDIR / bin / eva_db_backup.csh
8. Nous téléchargeons les fichiers reçus via SCP: $ RTDIR / bin / <date> -db-backup.backup et $ RTDIR / bin / eventiaUpgrade.tar sur le poste de travail.

Mettre à jour

1. Accédez à WebUI GAIA SMS → CPUSE → Afficher tous les packages.
2. Dans le cas où CPUSE génère une erreur de connexion au cloud Connect Point, nous vérifions les paramètres DGW, DNS et proxy.
3. Si tout est correct, mais que l'erreur persiste, vous devez mettre à jour CPUSE manuellement, guidé par sk92449 .
4. Téléchargez l'image et passez par Verifier. Si nécessaire, éliminez les incohérences.
   
   Par conséquent, vous devriez voir ce message:
   
   
5. Choisissez R80.20 Nouvelle installation et mise à niveau pour la gestion de la sécurité.
6. Lors de l'installation de la mise à jour, sélectionnez Nettoyer l'installation. Après l'installation, le système redémarrera.
7. Nous passons le First Time Wizard.
8. Après avoir obtenu l'accès, nous vérifions les comptes.
9. Nous nous connectons à SMS via SSH et changeons notre shell utilisateur en / bin / bash /:
   
   définir l'utilisateur <username> shell / bin / bash /
   
   enregistrer la configuration (au cas où nous voudrions laisser bin / bash / comme shell par défaut et après le redémarrage).
10. Ensuite, nous nous connectons à SMS via SCP et en mode binaire, nous transférons l'archive avec la configuration SMS_w_logs_export_r77_r80.tgz dans le dossier /var/log/UpgradeR77.30_R80.20/
    
11. Nous supprimons la somme de contrôle de l'archive: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz et la comparons avec la valeur précédente. Le total de contrôle doit correspondre.
12. Nous augmentons le délai d'expiration de la session SSH à 8 heures. Pour ce faire:
    
    [Expert @ HostName] # clish -c "afficher l'inactivité-timeout" regardez le time-out actuel clish,
    
    [Expert @ HostName] # clish -c "set inactivity-timeout 720" spécifiez un nouveau timeout clish (en minutes),
    
    [Expert @ HostName] # echo $ TMOUT regardez le mode expert de timeout actuel,
    
    [Expert @ HostName] # export TMOUT = 3600 spécifiez le nouveau mode expert de délai d'attente (en secondes). Si vous définissez la valeur sur 0, la temporisation sera désactivée.
13. Pour importer les paramètres, exécutez l'utilitaire d'importation de migration. Pour ce faire, accédez au dossier: cd $ FWDIR / bin / upgrade_tools / et exécutez l'import: ./migrate imp
    ort -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz

Profitez de la vie pendant les deux prochaines heures. NE DÉBRANCHEZ PAS la SESSION SSH pendant la procédure. À la fin, le processus de migration renverra un message de réussite ou une erreur.

Liste de contrôle après les mises à jour

1. Disponibilité des ressources.
2. SIC avec GW.
3. Licences Si les licences ne s'affichent pas correctement ou ne s'affichent pas sur SMS, exécutez la commande vsec_central_licence pour distribuer les licences.
4. Paramètre de stratégie.

Importer une base de données SmartEvent

1. Activez la lame SmartEvent.
2. Nous nous connectons via WinSCP à SMS et en mode binaire, nous transférons les fichiers <date> -db-backup.backup et eventiaUpgrade.tar précédemment téléchargés dans le dossier /var/log/UpgradeR77.30_R80.20/
3. Nous commençons le script avec la commande: $ RTDIR / bin / eventiaUpgrade.sh -upgrade /var/log/UpgradeR77.30_R80.20/eventiaUpgrade.tar
4. Vérification de l'état: regardez -n 10 eventiaUpgrade.sh
5. Vérifiez les journaux dans SmartEvent. RÊVE!

Mettre à jour le cluster Check Point GW (actif / sauvegarde)

Avant de commencer le travail

1. Nous enregistrons la configuration GAIA de chaque nœud du cluster dans un fichier. Pour ce faire, utilisez la commande: clish -c "show configuration"> ./ <Nom de fichier> .txt
2. Nous téléchargeons des fichiers à l'aide de WinSCP.
3. Nous nous connectons à la WebUI des deux nœuds et allons dans l' onglet CPUSE → Afficher tous les packages.
4. Nous trouvons le Service Pack pour la version R80.20 Fresh Install , cliquez sur Télécharger.
5. On vérifie que le protocole CCP fonctionne en mode Broadcast , pour cela on entre la commande: cphaprob -a if
   Si le mode multidiffusion est sélectionné, modifiez-le avec la commande: cphaconf set_ccp broadcast (la commande est exécutée sur chaque nœud).
6. Définissez le temps d'arrêt pour les nœuds impliqués dans votre système de surveillance.
7. Nous vérifions qu'au niveau de la virtualisation, les paramètres de changement d'adresse MAC et de transmissions forgées pour le réseau de synchronisation sont activés.

Mettre à jour

1. Nous nous connectons via ssh au nœud actif et exécutons la commande pour surveiller l'état du cluster: watch -n 2 cphaprob stat
2. Nous revenons aux nœuds WebUI Stanby sous l'onglet CPUSE et exécutons Verifier pour le package d'installation fraîche R80.20 sélectionné .
3. Nous analysons le rapport Verifier. Si l'installation est autorisée, continuez.
4. Sélectionnez le package R80.20 Fresh Install et exécutez Upgrade . Pendant le processus de mise à niveau, le système redémarrera. Les paramètres GAIA sont enregistrés. Au moment du redémarrage, nous surveillons l'état du cluster. Après le chargement, l'état du nœud mis à jour doit passer à PRET. Dans certains cas, nous avons eu un moment où un nœud non encore mis à jour est passé à l'état Active Attention et a cessé d'afficher l'état du nœud mis à jour. Ne vous inquiétez pas - cette option est également valable.
5. Une fois la mise à jour terminée, ouvrez SmartDashboard.
6. Ouvrez l'objet cluster et modifiez la version du cluster de R77.30 à R80.20. Cliquez OK. Si une erreur se produit lors de l'enregistrement des modifications:
   Une erreur interne s'est produite. (Code: 0x8003001D, impossible d'accéder au fichier pour l'opération d'écriture),
   suivez le SK119973 . Après cela, enregistrez les modifications et cliquez sur Installer la stratégie.
7. Dans les paramètres, décochez le paramètre For gateway clusters, si l'installation sur un membre du cluster échoue, ne l'installez pas sur ce cluster.
8. Nous établissons une politique. Le système donnera une erreur pour le nœud actif, qui n'a pas encore été mis à jour.
9. Nous nous connectons au nœud mis à jour via ssh et exécutons la commande pour surveiller l'état du cluster: watch -n 2 cphaprob stat
10. Nous nous connectons aux nœuds WebUI Active et accédons à l' onglet CPUSE → Afficher tous les packages. Nous trouvons le Service Pack pour la version R80.20 Fresh Install , cliquez sur Télécharger.
11. Définissez le temps d'arrêt pour les nœuds impliqués dans votre système de surveillance.
12. Nous revenons aux nœuds WebUI Active sous l'onglet CPUSE et exécutons Verifier pour le package d'installation fraîche R80.20 sélectionné .
13. Nous analysons le rapport Verifier. Si l'installation est autorisée, continuez.
14. Sélectionnez le package R80.20 Fresh Install et exécutez Upgrade. Pendant le processus de mise à niveau, le système redémarrera. Les paramètres GAIA sont enregistrés. Au moment du redémarrage, nous surveillons l'état du cluster sur un nœud déjà mis à jour. Après le redémarrage, l'état du cluster sur le nœud mis à jour passera de PRET à ACTIF.
15. Une fois le processus de mise à niveau terminé, lancez SmartDashboard et installez la stratégie.

Liste de contrôle après les mises à jour

• Journaux des événements dans SmartLog, état des tunnels VPN.
• Paramètres GAIA.
• Récupération de cluster après le basculement du test.
• Licences et contrats. Si les licences ne s'affichent pas correctement ou ne s'affichent pas sur SMS, exécutez la commande. vsec_central_licence pour la distribution des licences.
• CoreXL.
• SecureXL.
• Hotfix et CPinfo sur deux nœuds.

Conclusion

En général, à ce stade, tout - vous avez mis à jour.

L'ensemble de notre processus a duré en moyenne de 6 à 12 heures, selon la taille des bases de données exportées. Le travail s'est déroulé sur deux nuits: une pour la mise à jour SMS, la seconde pour le cluster.

Il n'y a eu aucun temps d'arrêt du trafic, malgré le fait que nous ayons vérifié toutes les erreurs ci-dessus.

Bien sûr, des difficultés complètement nouvelles peuvent parfois survenir pendant le processus de mise à jour, mais il s'agit de Check Point et, comme nous le savons tous, il y a toujours un correctif!

Bonne chance avec vos nuits roses et roses et mises à jour!