Tutorial
גיבוי WAN כפול ב-MikroTik לספקיות
כיצד לבנות גיבוי WAN כפול אמין ב-MikroTik לצי ספקיות: ניתוב רקורסיבי, Netwatch, NAT לכל WAN, זמן מעבר ואימות מרחוק.
תקציר גיבוי WAN כפול ב-MikroTik שומר על אתר מחובר לרשת על ידי העברת התעבורה באופן אוטומטי לקו גיבוי כאשר הקו הראשי נכשל. RouterOS מספק שלושה אבני בניין — ניתוב רקורסיבי עם check-gateway, Netwatch ו-NAT לכל WAN — והשילוב הנכון תלוי בכמה מהיר וכמה חכם הזיהוי שלכם צריך להיות. עבור ציי ספקיות הבעיה הקשה יותר אינה קטע ההגדרה אלא אישור, על פני מאות אתרים מרוחקים מאחורי CGNAT, שהגיבוי אכן עבד. מדריך זה מכסה את שני ההיבטים.
מהו גיבוי WAN כפול ב-MikroTik?
גיבוי WAN כפול ב-MikroTik הוא הגדרת RouterOS שמעניקה לנתב שני קווי אינטרנט — ראשי וגיבוי — ומעבירה אוטומטית את התעבורה לגיבוי כאשר הראשי מפסיק להעביר מנות, ומחזירה אותה כשהוא מתאושש. זה אינו זהה לאיזון עומסים: גיבוי משאיר קו אחד מושבת כפוליסת ביטוח, בעוד שאיזון עומסים מפזר את התעבורה בין השניים. המטרה היא רציפות, לא רוחב פס נוסף, ולכן זוהי תבנית היתירות המוגדרת כברירת מחדל עבור אתרים שפשוט אינם יכולים לחשוך.
המנגנון נשען על בחירת הנתיב. RouterOS בוחר את נתיב ברירת המחדל הפעיל לפי המרחק המנהלי הנמוך ביותר, כך שאתם נותנים לראשי מרחק קטן יותר ולגיבוי מרחק גדול יותר. כל התכנון מצטמצם אז לשאלה אחת: כיצד הנתב מחליט שהראשי “למטה” ומוריד את הנתיב שלו? קבלו את ההחלטה הזו נכון — מהר מספיק אך לא עצבני — והגיבוי יהיה אמין. עשו זאת שגוי, ואתם או עוברים לאט מדי או מרצדים בין הקווים בכל מנה אבודה.
שלב 1 — מפו את שני קווי ה-WAN לפני שתיגעו בנתיב
התחילו ברישום מה כל קו באמת הוא. קו ראשי קבוע מסוג סיב או PPPoE עם שער סטטי או שמוקצה על ידי PPP מתנהג אחרת מגיבוי Starlink או LTE שיושב מאחורי Carrier-Grade NAT ומספק לכם כתובת דינמית. זה חשוב כי ניתוב רקורסיבי עובד רק עם שערי IP יציבים, לא עם סוגי ממשק דינמיים כמו PPPoE או DHCP שבהם הכתובת יכולה להשתנות (תיעוד MikroTik — Failover (WAN Backup)). החליטו איזה קו ראשי, איזה גיבוי, והאם אחד מהם מחליף את ה-IP שלו בהתחברות מחדש — עובדה אחת זו מכתיבה באיזו שיטת זיהוי תוכלו להשתמש.
שלב 2 — הוסיפו נתיבי ברירת מחדל רקורסיביים עם check-gateway
הגישה הקלאסית משתמשת בניתוב רקורסיבי: במקום לכוון את נתיב ברירת המחדל ישירות לקפיצה הבאה, אתם מכוונים אותו ליעד בדיקה (למשל פותר ציבורי ידוע) ומוסיפים נתיב סטטי שמורה ל-RouterOS להגיע ליעד זה רק דרך שער WAN מסוים. לאחר מכן אתם יוצרים שני נתיבי ברירת מחדל הנפתרים רקורסיבית מעל יעדים אלה — הראשי עם מרחק קטן יותר ו-check-gateway=ping מופעל, הגיבוי עם מרחק גדול יותר (Scoop — Basic ISP Failover with MikroTik).
ההתנהגות שיש לתכנן סביבה היא העיתוי. Check-gateway משבית נתיב לאחר שתי בדיקות כושלות רצופות, והבדיקות רצות בערך כל 10 שניות, כך שהמעבר בפועל נוחת סביב 20 עד 30 שניות — והוא אינו מגיב לאובדן מנות לסירוגין, רק לשער מת לחלוטין (תיעוד MikroTik — Failover (WAN Backup)). עבור אתרי לקוחות ספקיות רבים זה מקובל. עבור מסופי קול או תשלום לעיתים קרובות לא, וכאן נכנס שלב 4.
שלב 3 — הגדירו NAT עבור שני הקווים
נתב WAN כפול זקוק לכלל masquerade (או src-nat) נפרד לכל ממשק WAN כך שהקו הפעיל בכל רגע מתרגם את התעבורה היוצאת נכון; כלל יחיד הקשור לממשק אחד ישבור את הקישוריות בשקט ברגע שהגיבוי מעביר את התעבורה לקו האחר. הוסיפו כלל masquerade אחד בשרשרת srcnat עבור ה-out-interface הראשי וכלל שני עבור הגיבוי. אם אתם מפרסמים שירותים נכנסים, זכרו שכללי dst-nat הקשורים לכתובת הראשי מפסיקים לעבוד כאשר אותו קו — וה-IP הציבורי שלו — נעלם. שבריריות נכנסת זו היא אותה מלכודת אדריכלית שכוסתה במקרה שינויי ה-IP של Starlink, וזו הסיבה שגישה מעוגנת ביציאה מתרחבת טוב יותר מהפניית פורטים. ליסודות ה-NAT, ראו את המדריך שלנו להגדרת NAT ב-MikroTik.
שלב 4 — השתמשו ב-Netwatch כשאתם צריכים זיהוי מהיר או חכם יותר
כאשר 20–30 שניות איטיות מדי או שאתם צריכים לפעול על קווים מושפלים-אך-חיים, Netwatch הוא הכלי הגמיש יותר. ב-RouterOS v7, Netwatch קיבל פרמטר type שיכול לבדוק עם icmp, tcp-conn, http-get, https-get או simple, ואתם יכולים לקבוע מרווח בדיקה משלכם במקום לחיות עם הקצב הקבוע של check-gateway (תיעוד MikroTik — Failover (WAN Backup)). לכל מארח יש סקריפט up וסקריפט down, כך שאתם יכולים להשבית את נתיב ברירת המחדל הראשי, להפעיל התראה או לרשום את האירוע במעבר.
מפעילים רבים משלבים את השניים: ניתוב רקורסיבי מטפל במוות קו נקי, בעוד ש-Netwatch מכסה את המקרים המסובכים יותר ושולח התראות. שרשור קהילה ארוך-טווח דן בדיוק בפשרה זו וכדאי לקרוא אותו לפני שתתקננו שיטה אחת על פני צי שלם (פורום MikroTik — netwatch instead of recursive routing). מה שלא תבחרו, שמרו על ההגדרה זהה בכל אתר — צי של סקריפטי גיבוי בהתאמה אישית הוא בעצמו תקלה שמחכה לקרות.
שלב 5 — אמתו את הגיבוי בכל אתר מרוחק
הנה החלק שמדריכי ההגדרה מדלגים עליו. הוספת הנתיבים בנתב מעבדה אחד היא קלה; להוכיח שהגיבוי עובד על מאות התקני CPE פרוסים היא בעיית הספקיות האמיתית — והיא נעשית קשה יותר כאשר קו הגיבוי הוא Starlink או LTE מאחורי CGNAT, מכיוון שלהתקן לעיתים קרובות אין IP ציבורי נגיש לניהול לאחר המעבר. אם אתם יכולים לאשר את הגיבוי רק על ידי המתנה לשיחת לקוח, אין לכם באמת גיבוי; יש לכם סקריפט שאתם מקווים שירוץ.
כאן ניהול מרכזי משנה את הכלכלה. MKController שומר על כל נתב נגיש דרך מנהרת יוצאת מאומתת, כך שתוכלו לאשר שנתיב הגיבוי נושא תעבורה, לצפות במעבר הגיבוי בניטור ולדחוף הגדרה מתוקנת — מבלי להיות תלויים ב-IP ציבורי שאולי אינו קיים על קו הגיבוי. שלבו זאת עם טלמטריה: המדריכים שלנו על ניטור MikroTik מרחוק עם Zabbix ועל ניטור SNMP עבור MikroTik מראים כיצד להתריע על אירוע הגיבוי עצמו, כך שמעבר שקט לקו הגיבוי היקר לעולם אינו נשאר ללא תשומת לב.
טיפים
- שמרו על בדיקת ה-
check-gatewayשל קו הגיבוי מכוונת ליעד שאתם מגיעים אליו דרך אותו קו, לא דרך הראשי, אחרת הבדיקה שלכם חסרת משמעות. - תייגו מעברי גיבוי בניטור שלכם כך שאתר הפועל ימים על קו הגיבוי שלו יפתח כרטיס — גיבוי שאיש אינו מבחין בו הוא עלות חוזרת, לא הצלה.
- בדקו את הכבל האמיתי, לא רק את הנתיב: משכו את המחבר של הראשי ומדדו את זמן המעבר האמיתי.
הביאו את הגיבוי תחת מישור בקרה אחד
גיבוי WAN כפול על MikroTik יחיד הוא בעיה פתורה. לעשות זאת באופן אמין על פני צי שלם — עם הגדרה עקבית והיכולת להוכיח שהגיבוי עובד על נתב שאינכם יכולים להגיע אליו דרך IP ציבורי — הוא המקום שבו רוב המפעילים מפסידים כסף. ניהול מרכזי, מעוגן ביציאה, סוגר את הפער הזה.