שאלת ראיון FortiGate: למה Zoom ו־Office 365 מתנתקים לרגע ב־SD-WAN, כשהקו לא נפל וה־SLA תקין?

זו שאלה שמראיינים בחברות אינטגרציה ובצוותי NOC אוהבים במיוחד, כי היא לקוחה ישר מהשטח. אין בה הגדרה לשנן. יש בה לקוח שמתלונן, גרף SLA ירוק, וקו שלא נפל. המראיין רוצה לראות אם אתם מבינים מה קורה ל־Session שכבר קיים, ולא רק איך FortiGate בוחר נתיב ל־Session חדש.

קודם כל, לקרוא נכון את הנתונים שבשאלה

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

• ▸״החוק תופס והתעבורה יוצאת בקו א׳״: הבעיה לא ב־Match של החוק. ה־Source, ה־Destination וה־Internet Service מוגדרים נכון.
• ▸״הקו לא נפל פיזית״: אין כאן Link Down קלאסי. ממשק שנופל יפיל Sessions בכל מקרה, וזו שאלה אחרת.
• ▸״ה־SLA לא חרג מהסף״: לפי הגרפים לא היה Failover אמיתי. אבל גרף ממוצע לא מספר הכול, ונחזור לזה.
• ▸״פעם ביום־יומיים, בעומס קל, לרגע״: זה לא עומס, זה אירוע. משהו קצר ונקודתי מזיז Sessions קיימים ממקומם.
• ▸״חלק מהמשתמשים״: רק מי שהיה באמצע שיחה או חיבור פעיל ברגע האירוע. מי שפתח Session אחרי זה בכלל לא הרגיש.

מה קורה ל־Session כשהניתוב משתנה ב־FortiOS

כדי לענות טוב צריך להבין דבר אחד על FortiGate: ה־Session Table שומר לכל Session גם את ממשק היציאה ואת ה־Gateway. כל עוד שום דבר לא זז, החבילות עוברות מהר לפי מה שכבר רשום. אבל ברגע שיש שינוי בניתוב, למשל Route שנוסף או הוסר, או שינוי בסדר החברים ב־SD-WAN Rule, ה־FortiGate מסמן את ה־Sessions הרלוונטיים כ־Dirty.

Session שמסומן Dirty עובר בדיקה מחדש בחבילה הבאה שלו: Route Lookup, התאמת Policy, ובחירת חבר SD-WAN. אם התשובה החדשה היא קו ב׳, ה־Session ממשיך משם. על הנייר זה נשמע הגיוני. בפועל, אם ה־Session יוצא עכשיו עם כתובת IP ציבורית אחרת, הצד השני רואה חבילות מכתובת שהוא לא מכיר. שיחת Zoom נתקעת ומתחברת מחדש, ו־Outlook או Teams מציגים ״מנסה להתחבר״ לכמה שניות.

• ▸Sessions עם SNAT על ה־FortiGate: כברירת מחדל הם נשארים על הממשק המקורי גם אחרי שינוי ניתוב, כל עוד ה־Route שלהם עדיין קיים ב־FIB. זה בדיוק מה ש־snat-route-change במצב disable עושה, וזו ברירת המחדל.
• ▸snat-route-change enable: ה־FortiGate יעביר גם Sessions עם SNAT לנתיב החדש. כתובת המקור משתנה וה־Session נשבר. מי שהדליק את זה ״כדי שה־Failover יהיה מהיר יותר״ קיבל בדיוק את התלונה שבשאלה.
• ▸Sessions בלי SNAT על ה־FortiGate: למשל כשה־NAT נעשה בראוטר של ספק האינטרנט, במכשיר נוסף אחרי ה־FortiGate, או ב־SASE מעבר למנהרת IPsec. כאן אין שום דבר שמונע מה־Session לעבור, וזה תרחיש מאוד נפוץ.
• ▸Route שנמחק לגמרי מה־FIB: במקרה כזה ה־FortiGate חייב לבדוק את ה־Session מחדש, ושום הגדרה לא תחזיק אותו על הנתיב הישן.

אז מה מזיז Sessions אם ה־SLA בכלל לא נשבר?

זה החלק שמפריד בין מי שקרא מדריך לבין מי שעבד עם SD-WAN בייצור. ה־SLA ״לא חרג״ לפי הגרף, אבל יש כמה סיבות שבגללן סדר החברים בחוק יכול להשתנות בלי ש־SLA נשבר באופן שרואים בעין.

• ▸החוק מוגדר במצב Best Quality: במצב הזה ה־FortiGate לא שואל ״האם הקו עומד ב־SLA״, אלא ״איזה קו טוב יותר כרגע״ לפי Latency, Jitter או Packet Loss. אם לרגע קו ב׳ מראה Latency טוב יותר בפער גדול מ־link-cost-threshold, החוק מחליף סדר. אין חריגה מסף, כי בכלל אין סף. יש רק השוואה.
• ▸Health Check שמהבהב: אם כמה Probes רצופים נכשלים, לפי failtime, החבר מסומן dead לכמה שניות וחוזר לפי recoverytime. בגרף שמציג ממוצע של דקות לא רואים את זה, אבל ה־SD-WAN Rule כבר הספיק להחליף סדר ולחזור.
• ▸חזרה מהירה מדי לקו המועדף: גם כשקו א׳ באמת היה בעייתי לכמה שניות, בלי hold-down-time החוק מחזיר את התעבורה אליו ברגע שהוא חוזר לתקינות. כל מעבר כזה הוא עוד סבב של Dirty Sessions.
• ▸שינויים בטבלת הניתוב שלא קשורים לחוק: חידוש DHCP או חיבור PPPoE מחדש בקו ב׳, Route שנלמד מ־BGP, או שינוי Static Route. כל שינוי כזה יכול לסמן Sessions כ־Dirty ולשלוח אותם לבדיקה מחדש.
• ▸Load Balance בתוך החוק: אם החוק במצב Lowest Cost עם Load Balance, סדר החברים משתנה לעתים קרובות לפי האלגוריתם. בלי sla-stickiness זה מתכון ל־Sessions שקופצים.

הפיצ׳רים ב־FortiOS שאחראים לשמור את ה־Session במקום

המראיין שאל ״איזה Feature אחראי״. התשובה המדויקת היא שיש כמה, וכל אחד פותר שכבה אחרת של אותה בעיה. מי שיודע להסביר מתי משתמשים בכל אחד, נשמע כמו מישהו שכבר עבר את זה.

• ▸sla-stickiness, ברמת ה־SD-WAN Rule: כשהוא מופעל, Session שיושב על חבר שעדיין עומד ב־SLA נשאר עליו, גם אם חבר אחר נהיה מועדף יותר. Sessions חדשים ילכו לפי הסדר החדש. זה ה־Feature שהכי ישיר לשאלה.
• ▸hold-down-time, ברמת ה־SD-WAN Rule: כמה שניות לחכות לפני שחוזרים מקו הגיבוי לקו המועדף. מונע ״פינג־פונג״ בין קווים כשקו א׳ מתאושש לרגע ונופל שוב.
• ▸link-cost-threshold, במצב Best Quality: באיזה אחוז שיפור צריך לעבור כדי שהחוק יחליף סדר. ברירת המחדל היא 10 אחוז. ברשת עם הבדלים קטנים ב־Latency, הגדלה של הערך מורידה מעברים מיותרים.
• ▸snat-route-change, ברמת system global: קובע אם Sessions עם SNAT יעברו לנתיב חדש. ברירת המחדל disable שומרת אותם במקום. אם מישהו הפעיל אותו, זה חשוד מספר אחד.
• ▸preserve-session-route, ברמת הממשק: כשהוא מופעל, Sessions שיצאו מהממשק נשארים עליו גם אחרי שינוי ניתוב, כל עוד ה־Route שלהם קיים ב־FIB. עובד גם על Sessions בלי SNAT, ולכן מתאים כשה־NAT נעשה מחוץ ל־FortiGate.

config system sdwan
    config service
        edit 3
            set name "Zoom-O365-WAN1"
            set mode sla
            set internet-service enable
            set internet-service-name "Microsoft-Office365" "<Zoom ISDB object>"
            config sla
                edit "HC-SaaS"
                    set id 1
                next
            end
            set priority-members 1 2
            set sla-stickiness enable
            set hold-down-time 300
        next
    end
end

# ברירת מחדל, לוודא שלא שונתה
config system global
    set snat-route-change disable
end

# כשה-NAT לא נעשה על ה-FortiGate
config system interface
    edit "wan1"
        set preserve-session-route enable
    next
end

בדיקה ב־CLI: איזה מסלול באמת תפס את ה־Session

החלק השני של השאלה הוא המבחן האמיתי. מראיין רוצה לשמוע סדר עבודה, לא רשימת פקודות. אני מציע ארבעה שלבים, מהתמונה הכללית ועד החבילה הבודדת.

# סדר החברים בכל SD-WAN Rule והאם הם עומדים ב-SLA
diagnose sys sdwan service4
# בגרסאות ישנות יותר: diagnose sys sdwan service
# ב-FortiOS 6.2 ומטה: diagnose sys virtual-wan-link service

# מצב ה-Health Check: Latency, Jitter, Packet Loss ו-alive/dead
diagnose sys sdwan health-check

# החוקים כפי שהם נכנסים בפועל ל-Policy Route, כולל סדר ה-oif
diagnose firewall proute list

diagnose sys session filter clear
diagnose sys session filter src 10.10.20.55
diagnose sys session filter dport 443
diagnose sys session list

# ממה כדאי להסתכל בפלט (דוגמה מקוצרת):
# state=log may_dirty ...
# orgin->sink: org pre->post, reply pre->post dev=7->5/5->7 gwy=203.0.113.1/10.10.20.55
# hook=post dir=org act=snat 10.10.20.55:52311->52.x.x.x:443(198.51.100.10:62311)
# sdwan_mbr_seq=1 sdwan_service_id=3

# התאמה בין מספר הממשק (dev=) לשם שלו
diagnose netlink interface list | grep index

diagnose debug reset
diagnose debug flow filter clear
diagnose debug flow filter addr 10.10.20.55
diagnose debug flow show function-name enable
diagnose debug flow trace start 50
diagnose debug enable

# מחפשים בפלט:
# Match policy routing id=...: to 52.x.x.x via ifindex-7
# שינוי ב-ifindex באמצע Session = ה-Session עבר קו

# לסיום, תמיד:
diagnose debug disable
diagnose debug reset

# היסטוריית SLA של חבר מסוים ב-Health Check
diagnose sys sdwan sla-log HC-SaaS 1
diagnose sys sdwan intf-sla-log wan1

# לוגי SD-WAN מסוג Event, כולל שינויי מצב של חברים
execute log filter category 1
execute log filter field subtype sdwan
execute log display

# טבלת הניתוב: האם משהו נוסף, הוסר או השתנה
get router info routing-table all

טעויות שכדאי לא לעשות בתשובה

• ▸״הקו לא יציב, צריך להחליף ספק״: השאלה אמרה במפורש שהקו לא נפל. מי שמתעלם מזה מאבד נקודות מהר.
• ▸להתבלבל עם Spillover: Spillover הוא מצב Load Balancing שמעביר תעבורה לקו נוסף כשעוברים סף רוחב פס. הוא לא המנגנון ששומר או מנתק Session קיים, ובתרחיש של עומס קל הוא כנראה בכלל לא רלוונטי.
• ▸להתבלבל עם ה־Implicit Rule: זה החוק שתופס תעבורה שלא התאימה לאף SD-WAN Rule. כאן החוק כן תופס, אז ה־Implicit Rule לא קשור.
• ▸לקפוץ ישר לפתרון: להגיד ״מדליקים sla-stickiness וזהו״ בלי להסביר איך מוכיחים שזו הבעיה. המראיין שאל גם איך בודקים.
• ▸להפעיל Debug Flow בלי Filter על FortiGate בייצור: זה פרט קטן, אבל מראיין עם ניסיון ישים לב.

שאלות המשך שכדאי להיות מוכנים אליהן

• ▸מה ההבדל בין מצב SLA, שנקרא Lowest Cost, לבין Best Quality? ב־SLA בוחרים את החבר הראשון לפי הסדר שעומד בסף. ב־Best Quality בוחרים את החבר עם המדד הכי טוב כרגע, ולכן הסדר משתנה יותר.
• ▸מה זה Session Dirty? Session שסומן לבדיקה מחדש בעקבות שינוי בניתוב או במדיניות. בחבילה הבאה ה־FortiGate מחליט מחדש לאן הוא יוצא.
• ▸למה UDP של Zoom רגיש במיוחד? כי אין בו Handshake שמתקן מצב. ברגע שכתובת המקור משתנה, השרת לא משייך את החבילות לשיחה, והלקוח צריך להתחבר מחדש.
• ▸מה ההבדל בין failtime ל־recoverytime ב־Health Check? failtime הוא כמה Probes רצופים צריכים להיכשל כדי לסמן את החבר dead. recoverytime הוא כמה Probes רצופים צריכים להצליח כדי להחזיר אותו.
• ▸מה עושה update-static-route ב־Health Check? מסיר מטבלת הניתוב את ה־Static Routes של חבר שסומן dead. זה עוד מקור לשינוי ניתוב שמסמן Sessions כ־Dirty.