HA ב-FortiGate: המדריך המלא בעברית להקמת אשכול Active-Passive — מהיסודות ועד Failover אמיתי

בואו נתחיל מסיפור שכל מי שעבד בשטח מכיר. יום חמישי, ארבע אחר הצהריים. הפיירוול היחיד בארגון מחליט שמספיק לו — ספק כוח, באג בגרסה, או פשוט כבל שמישהו הוציא בטעות בארון התקשורת. תוך שנייה אין אינטרנט, אין VPN לעובדים מהבית, אין גישה למערכות בענן, ואתם על הטלפון עם מנהל התפעול מנסים להסביר למה כל החברה עומדת. הבעיה כאן היא לא התקלה. תקלות קורות. הבעיה היא שהיה רכיב אחד שכל הארגון תלוי בו — Single Point of Failure.

בדיוק בשביל זה קיים HA. במאמר הזה ניקח את הנושא מההתחלה: מה זה High Availability, איך FortiGate מממש אותו בפועל, ואיך מקימים אשכול Active-Passive עובד — כולל כל ההגדרות שקל לפספס, בדיקות Failover אמיתיות, ופקודות אבחון שיצילו אתכם בשטח. זה בדיוק אותו תרגיל שהתלמידים שלנו מבצעים במעבדה בקורס Firewall FortiGate של מכללת נטמי, רק בגרסת מאמר.

אז מה זה בכלל HA?

High Availability, או בעברית זמינות גבוהה, זו גישה תכנונית פשוטה: אף רכיב בודד לא יפיל את השירות. במקום פיירוול אחד, שמים שניים (או יותר) שמכירים אחד את השני, מסנכרנים ביניהם את כל הקונפיגורציה ואת טבלת הסשנים, ומסכימים מראש מי מוביל. אם המוביל נופל — השני תופס פיקוד. למשתמש הקצה, במקרה הטוב, זה נראה כמו הבהוב קצר בשיחת הזום.

אצל Fortinet הפרוטוקול שעושה את הקסם נקרא FGCP — FortiGate Clustering Protocol. שני המכשירים מדברים ביניהם על גבי ממשקי Heartbeat ייעודיים, בוחרים Primary (בעבר קראו לזה Master), מסנכרנים קונפיגורציה אוטומטית, ומנטרים כל הזמן אחד את השני. חשוב להבין: אשכול FGCP מנוהל כישות אחת. אתם מתחברים ל-Primary, מגדירים שם מדיניות — והיא מופיעה בשנייה בשני המכשירים.

Active-Passive מול Active-Active — מה באמת מתאים לכם

• ▸Active-Passive (A-P) — מכשיר אחד מעביר את כל התעבורה, השני יושב מוכן ומסונכרן. פשוט, צפוי, קל לאבחון. זו ברירת המחדל בכ-90% מהפריסות בשטח, וזה מה שנבנה כאן.
• ▸Active-Active (A-A) — שני המכשירים מעבדים תעבורה, כאשר ה-Primary מפזר בעיקר סשנים של בדיקות UTM אל ה-Secondary. נשמע מפתה, אבל מוסיף מורכבות באבחון ולא תמיד נותן את הקפיצה בביצועים שציפיתם לה.
• ▸כלל אצבע מהשטח: אם אתם לא יכולים להסביר בדיוק למה אתם צריכים A-A — אתם צריכים A-P.

לפני שנוגעים בקונפיגורציה — רשימת הדרישות

רוב תקלות ה-HA שראיתי בחיים נולדו עוד לפני ההגדרה הראשונה, כי משהו בדרישות הבסיס לא התקיים. FGCP די נוקשה בעניין, וטוב שכך:

• ▸אותו דגם בדיוק בשני המכשירים (FortiGate 100F עם 100F, לא 100F עם 80F).
• ▸אותה גרסת FortiOS — עד רמת ה-Build. פער גרסאות הוא הסיבה מספר אחת לאשכול שלא מתאחד.
• ▸אותה רמת רישוי ורישום ב-FortiGuard, אחרת ה-Secondary לא יוכל לספק את אותן הגנות אחרי Failover.
• ▸לפחות ממשק אחד פנוי ל-Heartbeat, ורצוי שניים לצורך יתירות. ממשק Heartbeat לא נושא תעבורת משתמשים.
• ▸אין DHCP ואין PPPoE על ממשקים שמשתתפים באשכול, ואין ממשקים במצב Sniffer.
• ▸שני המכשירים מחוברים לאותם ה-VLANים ולאותם מתגים — פיזית ולוגית סימטריים.

HA לא סולח על אלתורים. שני מכשירים זהים, שתי גרסאות זהות, שני חיבורי Heartbeat — או שתבלו את הערב מול הודעת out-of-sync.

שלב 1 — הכנה: שם מארח וסדר בקונפיגורציה

עוד לפני שמדליקים HA, תנו לכל מכשיר Hostname שונה ומזהה: FGT-A ו-FGT-B. זה נשמע טריוויאלי, אבל כשתפתחו בעוד חצי שנה חלון SSH באמצע אירוע, השם הזה הוא ההבדל בין לדעת איפה אתם לבין לנחש. ודאו גם שעל ה-Secondary אין קונפיגורציה שאתם רוצים לשמור — ברגע ההצטרפות לאשכול הוא ידרוס את עצמו עם הקונפיגורציה של ה-Primary.

config system global
    set hostname "FGT-A"
end

שלב 2 — הגדרת HA ב-GUI

נכנסים אל System > HA. זה המסך שבו הכל קורה, ולמרות שהוא נראה קצר — כמעט לכל שדה בו יש משמעות מבצעית.

• ▸Mode — נבחר Active-Passive.
• ▸Device priority — מי מוביל. ערך גבוה יותר מנצח. תנו ל-FGT-A ערך 200 ול-FGT-B את ברירת המחדל 128 (או 100). זה השדה שקובע מי ה-Primary כשהכל תקין.
• ▸Group name ו-Group ID — מזהי האשכול. חייבים להיות זהים בשני המכשירים. אם יש לכם כמה אשכולות באותה רשת שכבה 2, תנו Group ID שונה לכל אחד — אחרת תיצרו התנגשות MAC וירטואלי.
• ▸Password — סוד משותף לאימות ההודעות בין החברים. חייב להיות זהה, ולא, זה לא המקום לשים 123456.
• ▸Session pickup — סנכרון טבלת הסשנים. בלי זה, אחרי Failover כל חיבור פעיל נקטע וצריך להיפתח מחדש. עם זה, הורדות ושיחות שורדות את המעבר.
• ▸Heartbeat interfaces — הממשקים שדרכם החברים מדברים. בחרו שניים לצורך יתירות; אם ה-Heartbeat נופל לגמרי, שני המכשירים חושבים שהם Primary וזה מצב Split-Brain שאף אחד לא רוצה לפגוש.
• ▸Monitor interfaces — ממשקים שכשל בהם מפעיל Failover. סמנו את ה-WAN ואת ה-LAN. אל תסמנו ממשקי Heartbeat.

config system ha
    set group-name "NETME-HA"
    set group-id 10
    set mode a-p
    set password ********
    set hbdev "port3" 50 "port4" 50
    set session-pickup enable
    set override disable
    set priority 200
    set monitor "port1" "port2"
end

שימו לב ל-override. כשהוא disable (וזו ברירת המחדל המומלצת), מכשיר שחזר לחיים לא ידחוף את עצמו חזרה לתפקיד Primary — האשכול נשאר יציב והתעבורה לא נקטעת פעם שנייה סתם. הפעילו override רק אם באמת חשוב לכם שמכשיר ספציפי תמיד יוביל, ותהיו מודעים לכך שאתם קונים בכך עוד אירוע Failover בכל התאוששות.

שלב 3 — חיבור פיזי והצטרפות לאשכול

מחברים את ממשקי ה-Heartbeat בין שני המכשירים — כבל ישיר בין port3 ל-port3 ובין port4 ל-port4 זו האפשרות הנקייה ביותר באתר יחיד. אם האשכול מפוצל בין שני ארונות או שני אתרים, ה-Heartbeat יעבור דרך מתגים, ואז חובה VLAN ייעודי ומבודד לחלוטין. אחרי החיבור, שני המכשירים מריצים תהליך בחירה, ותוך שניות ה-Secondary מוריד לעצמו את כל הקונפיגורציה מה-Primary ומאתחל את עצמו.

רגע לפני שממשיכים — הערה על MAC. באשכול FGCP, הממשקים מקבלים כתובת MAC וירטואלית משותפת שנגזרת מה-Group ID. זו הסיבה שאחרי Failover הרשת לא מתבלבלת: המכשיר החדש ממשיך להשתמש באותה MAC, ובנוסף שולח Gratuitous ARP כדי לרענן את טבלאות המתגים. זה גם בדיוק הסבר לשאלה הנפוצה למה שני אשכולות עם אותו Group ID באותה רשת גורמים לכאוס.

שלב 4 — בדיקת Failover אמיתית

אשכול שלא נבדק הוא הנחה, לא הגנה. תמיד, אבל תמיד, בדקו את ה-Failover בחלון תחזוקה מסודר לפני העלייה לאוויר. הבדיקה שאני אוהב היא פשוטה: פותחים ping רציף מתחנה בלאן לכתובת באינטרנט, ובמקביל מריצים הורדה גדולה או שיחת וידאו כדי לראות אם הסשנים באמת שורדים.

• ▸מנתקים את כבל ה-WAN מה-Primary — ה-Monitor Interface אמור לזהות ולהעביר תפקיד.
• ▸מכבים את ה-Primary לגמרי — הדמיה של כשל חומרה מלא.
• ▸מבצעים Failover יזום מה-CLI, בלי לגעת בכבלים בכלל.
• ▸סופרים כמה חבילות ping אבדו. בפריסה תקינה מדובר בבודדות, לרוב פחות משנייה של הפרעה.

# מעבר תפקידים יזום מהמכשיר הפעיל
execute ha failover set 1
execute ha failover unset 1

# מי אני ומי החברים שלי
get system ha status
diagnose sys ha status

# מעבר לניהול המכשיר השני דרך ה-CLI של האשכול
execute ha manage 1 admin

# בדיקת סנכרון קונפיגורציה בין החברים
diagnose sys ha checksum cluster

טעויות נפוצות שראינו במעבדה ובשטח

• ▸פערי גרסת FortiOS בין המכשירים — האשכול פשוט לא מתאחד, וההודעה בלוג לא תמיד ברורה.
• ▸Heartbeat יחיד. כבל אחד שנופל, ופתאום יש לכם שני Primary ברשת אחת — Split-Brain קלאסי.
• ▸סימון ממשק Heartbeat כ-Monitor Interface, מה שיוצר לולאת Failover אינסופית.
• ▸שכחה של Session pickup, ואז כל Failover מנתק שיחות, הורדות ו-VPN — טכנית זה עבד, מעשית המשתמשים צועקים.
• ▸Group ID זהה לשני אשכולות שונים באותה רשת שכבה 2 — התנגשות MAC וירטואלי ותקלות שנראות כמו קסם שחור.
• ▸אין תיעוד של Priority ושל override, ואז אף אחד לא זוכר מי אמור להיות Primary.
• ▸לא בודקים Failover אחרי כל שדרוג. אשכול שעבד בגרסה הקודמת הוא לא הבטחה לגרסה הנוכחית.

טיפ אחרון: שדרוג גרסה באשכול

אחד היתרונות היפים של HA הוא שדרוג כמעט ללא השבתה. FortiGate מבצע את זה לבד: מעלים את הקושחה מה-Primary, המערכת משדרגת קודם את ה-Secondary, מעבירה אליו תפקיד, ואז משדרגת את המכשיר השני. תנאי אחד — אל תיגעו בכלום באמצע, ותוודאו שיש לכם גיבוי קונפיגורציה ומסוף Console זמין. שדרוג בלי Console זה ספורט אתגרי, לא עבודת תשתיות.

מה עושים מכאן

HA הוא אחד הדברים שנראים פשוטים במאמר ומרגישים אחרת לגמרי כשעומדים מול שני מכשירים אמיתיים, כבל Heartbeat ביד ולקוח שמחכה. בקורס Firewall FortiGate של מכללת נטמי אתם בונים את האשכול בעצמכם על מעבדה חיה, מפילים אותו בכוונה, מתקנים, ולומדים לאבחן עם diagnose ו-sniffer — יחד עם Policies ו-NAT, פרופילי UTM (IPS, AntiVirus, Web Filter, Application Control), SSL Inspection, IPsec ו-SSL VPN ו-VDOM. בדיוק החומר שנשאלים עליו בראיונות ובדיוק מה שעושים ביום הראשון בעבודה.