המנהרה עדיין למעלה, המסלול נעלם: להפריד בין שני כשלי VPN

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

שלושה שלבים שנראים כמו אירוע אחד

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

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

קראו קודם את המסלול המותקן

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

ip route get 10.20.5.10
ip route show 10.20.0.0/16

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

ואז הביטו בתצוגה של הפרוטוקול עצמו

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

vtysh -c "show bgp summary"
vtysh -c "show bgp ipv4 unicast 10.20.0.0/16"

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

כשהשעונים לא מסכימים

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

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

התאוששות בלי לולאה

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

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