كونكت للتقنية Connect4Techsكونكت للتقنية Connect4Techs
أدوات مجانية: حاسبة Subnet · امتحانات تجريبية · قاموس المصطلحات ←
الرئيسية » أمن المعلومات » فايروول » فورتي جيت » شرح High Availability (HA) Active-Passive في الفورتي جيت “دروس شرح فورتي جيت 18”

شرح High Availability (HA) Active-Passive في الفورتي جيت “دروس شرح فورتي جيت 18”

بناء Cluster من جهازي فورتي جيت بنظام FGCP Active-Passive مع Heartbeat و Session Pickup واختبار الـ Failover.

بقلمAhmad Hussain تاريخ النشر15 أكتوبر 2026 وقت القراءة7 دقائق
شرح High Availability (HA) Active-Passive في الفورتي جيت “دروس شرح فورتي جيت 18”
محتويات المقال 14
  1. ما هو FGCP؟
  2. متطلبات بناء الـ Cluster
  3. السيناريو المستخدم
  4. المفاهيم المهمة قبل الإعداد
  5. Heartbeat Interfaces
  6. Priority و Override
  7. Monitored Interfaces
  8. Session Pickup
  9. الإعداد من الـ GUI
  10. الإعداد عبر CLI
  11. التحقق من حالة الـ Cluster
  12. اختبار الـ Failover
  13. أخطاء شائعة
  14. الخلاصة

نكمل سلسلة شرح كورس فورتي جيت فايروول بالعربي، شرح عملي خطوة بخطوة على FortiOS 7.4 و 7.6.

فيما سبق تم شرح

  1. مقدمة عن فورتي جيت FortiGate
  2. طريقة تنزيل وضبط اعدادات ال VM FortiGate
  3. ضبط اعدادات كرت الشبكة على جهاز الكلاينت (Client)
  4. طريقة عمل reset لعدد الأيام (14) للـ VM FortiGate
  5. مشكلة انتهاء الـ License للفورتي جيت
  6. باك اب لإعدادات الـ FortiGate واستعادتها
  7. شرح مكونات وواجهات الفورتي جيت
  8. طريقة تغيير باسورد الأدمن في FortiGate
  9. طريقة توصيل الانترنت لجهاز الفورتي جيت
  10. ترقية الـ Firmware لجهاز الفورتي جيت
  11. إنشاء يوزر جديد و Administration profiles
  12. ما هو الفورتي جارد FortiGuard
  13. شرح SD-WAN في الفورتي جيت لخطّي إنترنت مع Performance SLA “
  14. شرح Firewall Policies في الفورتي جيت خطوة بخطوة “
  15. شرح NAT في الفورتي جيت: Source NAT و IP Pools و Virtual IPs “
  16. شرح Site-to-Site IPsec VPN بين جهازي فورتي جيت “
  17. شرح Remote Access VPN باستخدام FortiClient و IPsec IKEv2 في الفورتي جيت “

الفورتي جيت هو بوابة الشركة للإنترنت ولكل الفروع، وإذا توقف جهاز واحد يتوقف العمل بالكامل. لذلك تستخدم أغلب الشركات جهازين في وضع High Availability، بحيث يعمل أحدهما ويكون الآخر جاهزاً لاستلام العمل فوراً عند حدوث عطل. في هذا الدرس نشرح بروتوكول FGCP في وضع Active-Passive، وهو الوضع الأكثر استخداماً.

ما هو FGCP؟

FGCP أو FortiGate Clustering Protocol هو بروتوكول Fortinet لبناء Cluster من جهازين أو أكثر. الأجهزة تتبادل رسائل Heartbeat عبر منافذ مخصصة، ويتم اختيار جهاز Primary يمرر الترافيك، بينما يبقى الـ Secondary في وضع الاستعداد ويستقبل نسخة متزامنة من الإعدادات، ومن جدول الجلسات إذا فعّلت Session Pickup. الإعدادات تتم على الـ Primary فقط وتنتقل تلقائياً إلى الـ Secondary.

في وضع Active-Passive يستخدم الـ Cluster عناوين MAC افتراضية (Virtual MAC) على المنافذ، فعند حدوث Failover ينتقل نفس الـ IP ونفس الـ MAC إلى الجهاز الآخر، ويرسل الجهاز الجديد Gratuitous ARP لتحديث جداول السويتشات.

متطلبات بناء الـ Cluster

  • نفس الموديل ونفس الـ Hardware Revision.
  • نفس إصدار FortiOS على الجهازين (يفضل نفس الـ Build تماماً).
  • نفس الـ Licenses، فاشتراكات FortiGuard تُشترى لكل جهاز على حدة ولا تنتقل بين أعضاء الـ Cluster.
  • نفس إعدادات HA: Mode و Group Name و Group ID و Password ومنافذ Heartbeat.
  • نفس وضع العمل (NAT أو Transparent) ونفس إعداد VDOMs.
  • منفذ واحد على الأقل للـ Heartbeat، ويُفضل منفذان للاحتياط.

السيناريو المستخدم

المنفذالوظيفة
port1WAN، متصل بسويتش أمام الراوتر
port2LAN بشبكة 192.168.10.0/24 وعنوان البوابة 192.168.10.1
port3 و port4Heartbeat، كابلات مباشرة بين الجهازين

FGT-A سيكون الـ Primary بـ Priority 200، و FGT-B هو الـ Secondary بـ Priority 100. كل منفذ WAN و LAN في الجهازين يجب أن يكون متصلاً بنفس الـ VLAN/السويتش، لأن الجهاز الذي يستلم العمل يحتاج نفس الاتصال تماماً.

المفاهيم المهمة قبل الإعداد

Heartbeat Interfaces

عبر هذه المنافذ تتم مراقبة الجهاز الآخر ومزامنة الإعدادات والجلسات. يجب أن تكون منافذ مخصصة لا تحمل ترافيك المستخدمين، وأن تكون موصولة مباشرة أو عبر VLAN معزولة. لكل منفذ Heartbeat قيمة Priority، والمنفذ صاحب الأولوية الأعلى هو الذي يُستخدم أولاً.

Priority و Override

اختيار الـ Primary لا يعتمد على الـ Priority وحدها. عندما يكون Override معطلاً (الوضع الافتراضي) يكون الترتيب: عدد الـ Monitored Interfaces السليمة، ثم الـ HA Uptime (العمر داخل الـ Cluster)، ثم الـ Priority، ثم الـ Serial Number. أي أن الجهاز الذي استلم العمل بعد عطل يبقى Primary حتى لو عاد الجهاز الأصلي، وهذا يمنع حدوث Failover ثانٍ غير ضروري. أما عند تفعيل Override فتتقدم الـ Priority على الـ Uptime، فيستعيد الجهاز صاحب الأولوية الأعلى دوره دائماً بمجرد عودته. فرق الـ Uptime لا يُحتسب إلا إذا زاد عن 5 دقائق افتراضياً.

Monitored Interfaces

هي المنافذ التي إذا سقطت على الـ Primary يتم نقل العمل للجهاز الآخر، مثل port1 و port2. بدون مراقبتها، فإن انقطاع كابل LAN على الـ Primary لن يسبب Failover لأن الجهاز نفسه ما زال يعمل. لا تضع منافذ الـ Heartbeat ضمن الـ Monitored Interfaces.

Session Pickup

افتراضياً تتم مزامنة الإعدادات فقط، وعند الـ Failover تنقطع الجلسات المفتوحة ويعيد المستخدمون الاتصال. تفعيل Session Pickup يجعل جلسات TCP تُنسخ إلى الـ Secondary فتستمر بعد الـ Failover. لنسخ جلسات UDP و ICMP أيضاً يجب تفعيل session-pickup-connectionless، مع الانتباه إلى أن ذلك يزيد الحمل على منافذ الـ Heartbeat.

الإعداد من الـ GUI

ابدأ بالجهاز الذي سيكون Primary وعليه الإعدادات الكاملة، ثم الجهاز الثاني ويُفضل أن يكون بإعدادات المصنع.

  1. تأكد أن الجهازين على نفس إصدار FortiOS من Dashboard > Status، وغيّر الـ Hostname لكل جهاز ليسهل التمييز بينهما.
  2. تأكد أن منافذ port3 و port4 غير مستخدمة في أي Policy أو Zone أو DHCP Server.
  3. على FGT-A اذهب إلى System > HA.
  4. Mode: اختر Active-Passive.
  5. Device priority: اكتب 200.
  6. Group name: اكتب اسماً مثل TS-CLUSTER، و Password: كلمة مرور قوية.
  7. فعّل Session pickup.
  8. Monitor interfaces: أضف port1 و port2.
  9. Heartbeat interfaces: أضف port3 و port4 مع Priority بقيمة 50 لكل منهما.
  10. اضغط OK. ستفقد الاتصال بالجهاز لثوانٍ لأن المنافذ تتحول إلى Virtual MAC.
  11. على FGT-B كرر نفس الخطوات بنفس الإعدادات تماماً لكن بـ Device priority قيمتها 100، ثم صِل كابلات الـ Heartbeat وبعدها كابلات WAN و LAN.
  12. سينضم FGT-B إلى الـ Cluster ويستقبل الإعدادات من FGT-A. بعد اكتمال المزامنة يظهر الجهازان في صفحة System > HA مع حالة Synchronized.

الإعداد عبر CLI

على FGT-A:

config system global
    set hostname "FGT-A"
end
config system ha
    set group-name "TS-CLUSTER"
    set mode a-p
    set password "StrongHAPassword"
    set hbdev "port3" 50 "port4" 50
    set session-pickup enable
    set override disable
    set priority 200
    set monitor "port1" "port2"
end

على FGT-B نفس الأوامر مع تغيير الـ Hostname والـ Priority:

config system global
    set hostname "FGT-B"
end
config system ha
    set group-name "TS-CLUSTER"
    set mode a-p
    set password "StrongHAPassword"
    set hbdev "port3" 50 "port4" 50
    set session-pickup enable
    set override disable
    set priority 100
    set monitor "port1" "port2"
end

إذا كان في نفس الشبكة أكثر من Cluster فغيّر group-id لكل Cluster، لأن الـ Virtual MAC يُشتق منه، وتكرار نفس الـ Group ID على نفس الشبكة يسبب تعارضاً في عناوين MAC.

التحقق من حالة الـ Cluster

get system ha status
diagnose sys ha checksum cluster
execute ha manage ?
  • get system ha status يعرض الـ Mode، والجهاز الـ Primary، وسبب اختياره، وحالة المزامنة لكل عضو.
  • diagnose sys ha checksum cluster يعرض الـ Checksum للإعدادات على كل جهاز. إذا كانت القيم متطابقة فالإعدادات متزامنة، وإذا اختلفت فهناك مشكلة مزامنة يجب البحث عن سببها.
  • execute ha manage يسمح بالدخول من الـ Primary إلى CLI الجهاز الـ Secondary، ويعرض ? أرقام الأعضاء المتاحة.

اختبار الـ Failover

نفّذ الاختبار في نافذة صيانة. ابدأ Ping مستمراً من جهاز في LAN إلى الإنترنت، ثم جرّب أحد الطرق التالية:

  1. افصل كابل port2 من الـ Primary. بما أن port2 ضمن الـ Monitored Interfaces سينتقل العمل إلى FGT-B خلال ثوانٍ مع فقدان عدد قليل من الـ Ping.
  2. أو استخدم الـ Failover Flag من CLI الـ Primary، وهو مخصص للاختبار والصيانة فقط:
execute ha failover set 1
execute ha failover status
get system ha status
execute ha failover unset 1

الرقم 1 هو رقم الـ Cluster في الوضع العادي بدون Virtual Clustering. الجهاز الذي عليه الـ Flag يبقى Secondary مهما حدث حتى تزيله، لذلك لا تنسَ تنفيذ unset بعد الاختبار وتأكد بـ execute ha failover status.

بعد الاختبار ومع Override معطل سيبقى FGT-B هو الـ Primary. لإعادة الدور إلى FGT-A في وقت مناسب يمكن تصفير الـ HA Uptime على الجهاز الحالي باستخدام diagnose sys ha reset-uptime فيصبح FGT-A صاحب الـ Uptime الأعلى (أو يتقارب الجهازان ضمن هامش الـ 5 دقائق فيُحسم الاختيار بالـ Priority) ويعود Primary.

أخطاء شائعة

  • اختلاف إصدار FortiOS أو الموديل، فلا يتكون الـ Cluster أصلاً.
  • اختلاف Group Name أو Password أو Group ID بين الجهازين.
  • استخدام منفذ Heartbeat واحد فقط، فإذا انقطع يظن كل جهاز أنه وحيد ويصبح الاثنان Primary (Split Brain) ويحدث تعارض في الـ IP و MAC.
  • تمرير الـ Heartbeat عبر سويتش يضيف تأخيراً أو يحجب الـ Ethertypes الخاصة بـ FGCP، والأفضل كابل مباشر أو VLAN معزولة.
  • عدم إضافة منافذ WAN و LAN إلى الـ Monitored Interfaces، فلا يحدث Failover عند انقطاع كابل.
  • تفعيل Override دون فهم تأثيره، فيحدث Failover إضافي كلما عاد الجهاز الأصلي.
  • شراء Licenses لجهاز واحد فقط، فتتوقف خدمات FortiGuard عند انتقال العمل للجهاز الآخر.
  • نسيان أن الإدارة تتم على الـ Primary فقط، أو الحاجة لإدارة كل جهاز بعنوان مستقل دون إعداد Management Interface مخصص لـ HA.

الخلاصة

بناء Cluster بنظام FGCP Active-Passive يحتاج جهازين متطابقين في الموديل والإصدار والـ Licenses، ومنفذين للـ Heartbeat، ونفس Group Name و Password، مع تحديد الـ Priority ومراقبة منافذ WAN و LAN وتفعيل Session Pickup لاستمرار الجلسات. بعد الإعداد تحقق دائماً بـ get system ha status و diagnose sys ha checksum cluster، واختبر الـ Failover فعلياً في نافذة صيانة قبل الاعتماد على الـ Cluster في الإنتاج.

استفدت من المقال؟شاركه مع زمايلك، يمكن يفيدهم كمان.
كتب بواسطةAhmad Hussain

مهندس شبكات بخبرة أكثر من 10 سنوات في تصميم شبكات الشركات وتشغيلها وتأمينها. حاصل على شهادات سيسكو CCNA و CCNP و CCIE، وشهادتي Fortinet NSE 4 و NSE 7، ودرس كورسات Microsoft MCSA و VMware و Palo Alto (PCNSA / PCNSE) و MikroTik (MTCNA / MTCRE) و Aruba و Ubiquiti، إلى جانب أنظمة الاتصالات VoIP (Asterisk و Elastix و 3CX). يكتب في كونكت للتقنية شروحات عملية في الشبكات وأمن المعلومات.

إعلان
إعلان
0% اتقرا