تحديث نقطة التحقق من R77.30 إلى 80.20

في خريف عام 2019 ، توقفت Check Point عن دعم إصدارات R77.XX ، وتحتاج إلى تحديث. لقد قيل الكثير بالفعل عن الفرق بين الإصدارات ، إيجابيات وسلبيات الانتقال إلى R80. دعنا نتحدث عن كيفية ترقية نقطة التحقق من الأجهزة الافتراضية (CloudGuard لـ VMware ESXi و Hyper-V و KVM Gateway NGTP) وما الذي يمكن أن يحدث.

لذلك ، كان لدينا مهندسان من CCSE ، وأكثر من اثنتي عشرة مجموعة افتراضية ، نقطة تفتيش R77.30 ، وعدة غيوم ، إصلاحات طفيفة وبحر كامل من مختلف الخلل ومواطن الخلل وكل ذلك ، وجميع الألوان والأحجام ، وكذلك المواعيد النهائية الضيقة للغاية. دعنا نذهب!

المحتويات:

تدريب
تحديث خادم الإدارة
تحديث الكتلة

هذا هو ما تبدو عليه البنية التحتية السحابية للعميل النموذجي مع Check Point الافتراضية

تدريب

بادئ ذي بدء ، تحتاج إلى التحقق من كفاية الموارد للتحديث. الحد الأدنى الموصى به لمتطلبات R80.20 الآن يبدو كما يلي:


يتم وصف التوصيات في CP_R80.20_GA_Release_Notes .

لكننا سنكون واقعيين. إذا كان هذا كافيًا في الحد الأدنى من التهيئة ، فعندئذٍ ، كما توضح الممارسة ، عادةً ما يكون فحص https قيد التشغيل ، يعمل SmartEvent للرسائل القصيرة ، وما إلى ذلك ، الأمر الذي يتطلب بالطبع قدرات مختلفة تمامًا. لكن بشكل عام ليس أكبر من R77.30.

ولكن هناك فروق دقيقة. وهي تتعلق أولاً بأحجام الذاكرة الفعلية. تتطلب العديد من العمليات مباشرة أثناء عملية الترقية مساحة على القرص الثابت.

بالنسبة لخادم الإدارة ، سيعتمد مقدار مساحة القرص الحرة إلى حد كبير على حجم السجلات الحالية (إذا أردنا حفظها) وعلى عدد مراجعات قاعدة البيانات المحفوظة ، على الرغم من أننا لن نحتاج إليها بكمية كبيرة. بالطبع ، بالنسبة لعقد نظام المجموعة (إلا إذا قمت بتخزين السجلات محليًا أيضًا) فإن هذا كله لا يهم. إليك كيفية التحقق مما إذا كانت لديك المساحة المناسبة:

1. نقوم بالاتصال بخادم الإدارة الذكية عبر ssh ، وانتقل إلى وضع الخبير وأدخل الأمر:
   
   [Expert @ cp-sms: 0] # df -h
2. في الإخراج ، سنرى شيئًا مثل هذا التكوين:
   
   حجم نظام الملفات المستخدمة ، استخدم٪ 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. نحن مهتمون حاليًا بقسم / var / log

ضع في اعتبارك أنه وفقًا لسياسة تخزين وحذف ملفات السجل القديمة ، وكذلك حجم قاعدة البيانات المصدرة ، قد تكون هناك حاجة إلى مساحة أكبر. إذا أصبح إنشاء مساحة خالية أقل من المشار إليها في السياسة عند إنشاء الأرشيف لتخزين ملفات السجل ، سيبدأ النظام في محو السجلات القديمة ولن يدرجها في الأرشيف.

أيضًا ، بالنسبة لعملية التحديث نفسها ، سيحتاج النظام إلى 13 غيغابايت على الأقل من المساحة غير المخصصة على القرص الصلب. يمكنك التحقق من وجودها بواسطة الأمر:

[Expert @ cp-sms: 0] # pvs

سنرى الاستنتاج التالي تقريبًا:

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

في هذه الحالة ، لدينا 43 جيجابايت. هناك ما يكفي من الموارد. يمكنك البدء في التحديث.

تحديث نقطة التحقق خادم إدارة SMS

قبل البدء في العمل ، قم بما يلي:

1. قم بتثبيت حزمة أدوات الترحيل على خادم الإدارة. للقيام بذلك ، يجب عليك تحميل الصورة من بوابة Check Point .
2. قم بتنزيل الأرشيف إلى خادم الإدارة عبر WinSCP في المجلد /var/log/UpgradeR77.30_R80.20 (إذا لزم الأمر ، قم بإنشاء مجلد أولاً).
3. نتصل بخادم الإدارة عبر SSH ونذهب إلى مجلد الأرشيف: cd /var/log/UpgradeR77.30_R80.20/
4. قم بفك ضغط الملف: tar -zxvf ./ <اسم الملف> .tgz
5. نطلق الأداة المساعدة pre_upgrade_verifier باستخدام الأمر: ./pre_upgrade_verifier -p $ FWDIR -c R77 -t R80.20
6. عند الانتهاء من الأمر ، سيتم إنشاء تقرير عن الإعدادات غير المتوافقة. وهي متاحة في /opt/CPsuite-R77/fw1/log/pre_upgrade_verification_report.(xls و html و txt). إنه أكثر ملاءمة لتفريغه من خلال SCP ومشاهدته عبر المتصفح.
   للتخلص من جميع الإعدادات غير المتوافقة ، استخدم SK117237 .
7. ثم أعد تشغيل الأداة المساعدة pre_upgrade_verifier للتحقق من حل جميع أسباب عدم التوافق.
8. بعد ذلك ، نقوم بجمع معلومات حول واجهات الشبكة وجدول التوجيه وتحميل تكوين 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 "إظهار التكوين"> /var/log/UpgradeR77.30_R80.20/cp-sms-config.txt
9. قم بتحميل الملف المستلم عبر SCP.
10. نحن نفعل لقطة على مستوى الافتراضية.
11. نزيد مهلة جلسة SSH إلى 8 ساعات. إليك ما يحالفك الحظ: حسب حجم القاعدة المصدرة ، يمكن أن تستمر من عدة دقائق إلى عدة ساعات. للقيام بذلك:
    [Expert @ HostName] # clish -c "show anctivity-timeout" شاهد clish timeout الحالي ،
    
    [Expert @ HostName] # clish -c "تعيين عدم النشاط - مهلة 720" ، حدد clish timeout (بالدقائق) ،
    
    [Expert @ HostName] # echo $ TMOUT ننظر إلى وضع خبير المهلة الحالي ،
    
    [Expert @ HostName] # export TMOUT = 3600 حدد وضع خبير مهلة جديد (بالثواني) ، إذا قمت بتعيين القيمة على 0 ، فسيتم إيقاف المهلة.
12. نقوم بتحميل صورة التثبيت SMS.iso وتثبيتها على الجهاز الظاهري.
    
    قبل الخطوة التالية ، تأكد من التحقق مرة أخرى من أن لديك مساحة كافية غير مخصصة على محرك الأقراص الثابتة (أذكرك بأنك تحتاج إلى 13 جيجابايت).
    
13. قبل البدء في تصدير التكوين ، نقوم بتغيير ملف السجل باستخدام الأمر: fw logswitch

تكوين التصدير والسجلات

1. قم بتشغيل الأداة المساعدة migrate_export لإلغاء تحميل التكوين. للقيام بذلك ، انتقل إلى المجلد الذي تم إنشاؤه مسبقًا: cd /var/log/UpgradeR77.30_R80.20/ واستخدم الأمر: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
   
   أو
   
   انتقل إلى المجلد: cd $ FWDIR / bin / upgrade_tools / and
   قم بتشغيل الأمر من هناك: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
   
   إذا كانت القاعدة التي تم تصديرها كبيرة ، فقد يستغرق الإجراء عدة ساعات.
   لا تفصل جلسة SSH أثناء الإجراء.
   
   في هذه العملية ، ستعرض GAIA هذه الرسالة:
   
   يمكنك الذهاب بأمان لتناول القهوة والغداء.
   
   بعد أن نرى إما رسالة خطأ مثل هذا:
   
   
   
   أو رسالة حول الإكمال الناجح للعملية:
   
   
   
   إذا كانت العملية مستمرة لبضع ساعات ، فيمكنك التحقق منها. بدون فصل الجلسة الحالية ، قم بإعداد جلسة متوازية عبر ssh وأدخل الأمر العلوي. من بين العمليات ، يجب عرض عملية الترحيل.
   
   إذا بدون فصل جلسة SSH بأي طريقة ، فاستخدم: yes | nohup ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
   
   في هذه الحالة ، يمكنك فصل الجلسة ، ولكن سيكون من غير المناسب مراقبة التقدم: سيتعين عليك التحقق من إكمال العملية باستخدام الأمر العلوي ، وفي حالة وجود مشكلة ، لن تكون هناك رسالة خطأ. لذلك ، نوصي بشدة بهذا الخيار.
2. إزالة المجموع الاختباري من الأرشيف: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
3. نحن نحفظ القيمة المستلمة في جهاز كمبيوتر محمول.
4. نحن نتصل بالرسائل النصية القصيرة عبر SCP وتحميل الأرشيف مع التكوين إلى محطة العمل. تأكد من استخدام نقل الملفات في تنسيق ثنائي.

تصدير قاعدة بيانات SmartEvent

نحن هنا بحاجة إلى إصدار SMS مثبت مسبقاً R80. أي اختبار سوف تفعل.

1. من SMS ، نحتاج إلى برنامج نصي موجود هنا: $ RTDIR / bin / eva_db_backup.csh
2. من خلال SCP ، قم بتحميل البرنامج النصي eva_db_backup.csh في المجلد: /var/log/UpgradeR77.30_R80.20/
3. نتواصل عبر SSH إلى الرسائل القصيرة. انسخ الملف إلى المجلد: cp /var/log/UpgradeR77.30_R80.20/eva_db_backup.csh
   $ RTDIR / bin / eva_db_backup.csh
   
4. تغيير الترميز: dos2unix $ RTDIR / bin / eva_db_backup.csh
5. إضافة مالك: chown -v admin: root $ RTDIR / bin / eva_db_backup.csh
6. إضافة أذونات: chmod -v 0755 $ RTDIR / bin / eva_db_backup.csh
7. نبدأ في تصدير قاعدة SmartEvent: $ RTDIR / bin / eva_db_backup.csh
8. نقوم بتحميل الملفات المستلمة عبر SCP: $ RTDIR / bin / <date> -db-backup.backup و $ RTDIR / bin / eventiaUpgrade.tar إلى محطة العمل.

تحديث

1. انتقل إلى WebUI GAIA SMS → CPUSE → عرض جميع الحزم.
2. في حالة قيام CPUSE بإنشاء خطأ في اتصال السحاب من Connect Point ، فإننا نتحقق من إعدادات DGW و DNS و Proxy.
3. إذا كان كل شيء صحيحًا ، ولكن الخطأ لا يزال قائماً ، فأنت بحاجة إلى تحديث CPUSE يدويًا ، بإرشاد sk92449 .
4. قم بتنزيل الصورة وانتقل إلى Verifier. إذا لزم الأمر ، والقضاء على التناقضات.
   
   نتيجة لذلك ، سترى هذه الرسالة:
   
   
5. اختر R80.20 تثبيت جديد وترقية لإدارة الأمن.
6. عند تثبيت التحديث ، حدد Clean Install. بعد التثبيت ، سيتم إعادة تشغيل النظام.
7. نمر معالج المرة الأولى .
8. بعد الوصول ، نتحقق من الحسابات.
9. نحن نتواصل مع الرسائل القصيرة عبر SSH ونغير قذيفة مستخدمنا إلى / bin / bash /:
   
   تعيين المستخدم <username> shell / bin / bash /
   
   حفظ التكوين (في حال أردنا ترك bin / bash / كصدفة افتراضية وبعد إعادة التشغيل).
10. بعد ذلك ، نتواصل مع SMS عبر SCP وفي الوضع الثنائي ننقل الأرشيف بتكوين SMS_w_logs_export_r77_r80.tgz إلى المجلد /var/log/UpgradeR77.30_R80.20/
    
11. نقوم بإزالة المجموع الاختباري من الأرشيف: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz ومقارنته بالقيمة السابقة. يجب أن تطابق المجموع الاختباري.
12. نزيد مهلة جلسة SSH إلى 8 ساعات. للقيام بذلك:
    
    [Expert @ HostName] # clish -c "show anctivity-timeout" شاهد clish timeout الحالي ،
    
    [Expert @ HostName] # clish -c "تعيين عدم النشاط - مهلة 720" ، حدد clish timeout (بالدقائق) ،
    
    [Expert @ HostName] # echo $ TMOUT ننظر إلى وضع خبير المهلة الحالي ،
    
    [Expert @ HostName] # export TMOUT = 3600 حدد وضع خبير المهلة الجديد (بالثواني). إذا قمت بتعيين القيمة على 0 ، فسيتم إيقاف المهلة.
13. لاستيراد الإعدادات ، قم بتشغيل أداة ترحيل الاستيراد المساعدة. للقيام بذلك ، انتقل إلى المجلد: cd $ FWDIR / bin / upgrade_tools / وقم بتشغيل الاستيراد: ./migrate imp
    ort -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz

استمتع بالحياة خلال الساعات القليلة القادمة. لا تفصل جلسة SSH أثناء الإجراء. في النهاية ، ستقوم عملية الترحيل بإرجاع رسالة نجاح أو خطأ.

المرجعية بعد التحديثات

1. توافر الموارد.
2. SIC مع غيغاواط.
3. الترخيص. إذا تم عرض التراخيص بشكل غير صحيح أو لم يتم عرضها على SMS ، فقم بتشغيل الأمر vsec_central_licence لتوزيع التراخيص.
4. وضع السياسة.

استيراد قاعدة بيانات SmartEvent

1. تمكين SmartEvent Blade.
2. نتصل عبر WinSCP بالرسائل النصية القصيرة وفي الوضع الثنائي نقل ملفات <date> -db-backup.backup و eventiaUpgrade.tar التي تم تنزيلها مسبقًا إلى المجلد /var/log/UpgradeR77.30_R80.20/
3. نبدأ البرنامج النصي باستخدام الأمر: $ RTDIR / bin / eventiaUpgrade.sh -upgrade /var/log/UpgradeR77.30_R80.20/eventiaUpgrade.tar
4. التحقق من الحالة: مشاهدة -n 10 eventiaUpgrade.sh
5. تحقق من السجلات في SmartEvent. DREAM!

تحديث الكتلة Check Point GW (نشط / النسخ الاحتياطي)

قبل البدء في العمل

1. نحفظ تكوين GAIA من كل عقدة من الكتلة إلى ملف. للقيام بذلك ، استخدم الأمر: clish -c "show التكوين"> ./ <اسم الملف> .txt
2. نحن تحميل الملفات باستخدام WinSCP.
3. نحن نتصل بـ WebUI لكلتا العقدتين وننتقل إلى علامة التبويب CPUSE → إظهار جميع الحزم.
4. نجد حزمة الخدمة للإصدار R80.20 Fresh Install ، انقر فوق Download.
5. نتحقق من أن بروتوكول CCP يعمل في وضع البث ، ولهذا ندخل الأمر: cphaprob -a if
   إذا تم تحديد وضع البث المتعدد ، قم بتغييره باستخدام الأمر: cphaconf set_ccp broadcast (يتم تنفيذ الأمر على كل عقدة).
6. اضبط وقت التوقف للعقد المشاركة في نظام المراقبة الخاص بك.
7. نتحقق من أنه على مستوى المحاكاة الافتراضية ، يتم تمكين معلمات تغيير عنوان MAC وعمليات النقل المزورة لشبكة المزامنة.

تحديث

1. نتواصل عبر ssh بالعقدة النشطة ونقوم بتشغيل الأمر لمراقبة حالة الكتلة: watch -n 2 cphaprob stat
2. نعود إلى عقد WebUI Stanby في علامة التبويب CPUSE وقم بتشغيل Verifier لحزمة R80.20 Fresh Install المحددة .
3. نحن نحلل تقرير Verifier. إذا كان التثبيت مسموحًا ، فاستمر.
4. حدد الحزمة R80.20 Fresh Install وقم بتشغيل Upgrade . أثناء عملية الترقية ، سيتم إعادة تشغيل النظام. يتم حفظ إعدادات GAIA. في وقت إعادة التشغيل ، نراقب حالة الكتلة. بعد التحميل ، يجب تغيير حالة العقدة المحدثة إلى جاهزة. في بعض الحالات ، كانت لدينا لحظة عندما دخلت عقدة لم يتم تحديثها بعد في حالة الاهتمام النشط وتوقفت عن عرض حالة العقدة المحدثة. لا تشعر بالقلق - هذا الخيار صالح أيضًا.
5. عند الانتهاء من التحديث ، افتح SmartDashboard.
6. افتح كائن الكتلة وقم بتغيير إصدار الكتلة من R77.30 إلى R80.20. انقر فوق موافق. في حالة حدوث خطأ أثناء حفظ التغييرات:
   لقد حدث خطأ داخلي. (الرمز: 0x8003001D ، تعذر الوصول إلى ملف لعملية الكتابة) ،
   اتبع SK119973 . بعد ذلك ، احفظ التغييرات وانقر فوق " تثبيت السياسة".
7. في الإعدادات ، قم بإلغاء تحديد المعلمة For clusters clusters ، إذا فشل التثبيت على عضو كتلة ، لا تقم بتثبيت على تلك الكتلة.
8. نضع سياسة. سيقوم النظام بإعطاء خطأ للعقدة النشطة ، والتي لم يتم تحديثها بعد.
9. نقوم بالاتصال بالعقدة المحدثة عبر ssh وقم بتشغيل الأمر لمراقبة حالة الكتلة: watch -n 2 cphaprob stat
10. نتصل بعقد WebUI النشطة وننتقل إلى علامة التبويب CPUSE → إظهار كافة الحزم. نجد حزمة الخدمة للإصدار R80.20 Fresh Install ، انقر فوق Download.
11. اضبط وقت التوقف للعقد المشاركة في نظام المراقبة الخاص بك.
12. نعود إلى عقد WebUI النشطة في علامة التبويب CPUSE وقم بتشغيل Verifier لحزمة تثبيت R80.20 الطازجة المحددة .
13. نحن نحلل تقرير Verifier. إذا كان التثبيت مسموحًا ، فاستمر.
14. حدد الحزمة R80.20 Fresh Install وقم بتشغيل Upgrade. أثناء عملية الترقية ، سيتم إعادة تشغيل النظام. يتم حفظ إعدادات GAIA. في وقت إعادة التشغيل ، نراقب حالة الكتلة على عقدة تم تحديثها بالفعل. بعد إعادة التشغيل ، ستتغير حالة الكتلة على العقدة المحدّثة من جاهز إلى نشط.
15. عند اكتمال عملية الترقية ، قم بتشغيل SmartDashboard وتثبيت السياسة.

المرجعية بعد التحديثات

• سجلات الأحداث في SmartLog ، حالة أنفاق VPN.
• إعدادات GAIA.
• استرداد الكتلة بعد اختبار الفشل.
• التراخيص والعقود. إذا تم عرض التراخيص بشكل غير صحيح أو لم يتم عرضها على SMS ، فقم بتشغيل الأمر. vsec_central_licence لتوزيع الترخيص.
• CoreXL.
• SecureXL.
• الإصلاح العاجل و CPinfo على عقدتين.

استنتاج

بشكل عام ، في هذه المرحلة ، كل شيء - لقد قمت بتحديث.

استغرقت العملية برمتها في المتوسط ​​من 6 إلى 12 ساعة ، وهذا يتوقف على حجم قواعد البيانات المصدرة. تم تنفيذ العمل لمدة ليلتين: واحدة لتحديث الرسائل القصيرة ، والثانية للمجموعة.

لم يكن هناك توقف في حركة المرور ، على الرغم من أننا فحصنا جميع الأخطاء أعلاه على أنفسنا.

بالطبع ، قد تنشأ أحيانًا صعوبات جديدة تمامًا أثناء عملية التحديث ، ولكن هذه نقطة تفتيش ، وكما نعلم جميعًا ، هناك دائمًا إصلاح عاجل!

حظا سعيدا مع ليال الوردي والوردي والتحديثات!