נתיב הגיבוי הצף של VPN לא משתלט: רשימת בדיקה למעבר

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

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

תנו שם לכשל שהגיבוי צריך לכסות

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

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

הפסיקו לבקש מהמרחק לזהות משהו

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

עבור נתיבים סטטיים זה דורש עוקב מפורש:

/ip route
add dst-address=10.20.0.0/24 gateway=192.0.2.1 distance=1 check-gateway=ping
add dst-address=10.20.0.0/24 gateway=wg-backup distance=10

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

עקבו לאן הולכות המנות של הבדיקה עצמה

גם לבדיקת תקינות יש נתיב. ברגע שתעבורת הנתונים עוברת ל-VPN, בדיקה לא מוגבלת לאותה כתובת מרוחקת יכולה ללכת אחריה, להצליח ולהיקרא כהוכחה שהראשי התאושש. התעבורה חוזרת לנתיב שבור והמחזור חוזר על עצמו.

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

/ip route print detail where dst-address=203.0.113.10
# gateway should still be the primary next hop

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

יעד אחד שדוחה ICMP או נכנס לתחזוקה נראה בדיוק כמו כשל נתיב, ושלושה יעדים בלי כלל נותנים לכם רק שלוש דעות. החליטו על הכלל קודם ואז יישמו אותו: למשל, הראשי נחשב למטה כששניים משלושה יעדים נכשלים בשני מרווחים רצופים, כתוב במדריך התפעול שבו האדם הבא ימצא אותו.

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

בדקו את נתיב החזרה ואת סיפור הסשנים

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

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

הריצו את רצף הקבלה

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

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