איך להבחין בין לולאת ניתוב לבין נתיב שמפרפר באתרי VPN
לולאת ניתוב ונתיב לא יציב גורמים לאותה אבידה לסירוגין. שלוש בדיקות בשערים מבדילות ביניהם לפני שתשנו משהו.
שני אתרים, מנהרה אחת וקידומת מרוחקת שעונה לזמן מה ואז משתתקת. הרפלקס הוא לקרוא לזה לולאת ניתוב, ולפעמים זה בדיוק מה שזה. אבל לולאה ונתיב שמפרפר יוצרים את אותה תלונה, והם זקוקים לתיקונים הפוכים: האחד הוא החלטת העברה שלעולם אינה מסתיימת, והשני הוא קידומת שכל הזמן עוזבת את הטבלה. שלוש תצפיות מפרידות ביניהם, ואפשר לאסוף את שלושתן משורת הפקודה של השער לפני שנוגעים במסנן או מפעילים מחדש מנהרה.
לולאה נקבעת קפיצה אחר קפיצה. אתר A בוחר ב-B כקפיצה הבאה ליעד, B בוחר ב-A לאותו יעד, והמנות קופסת על TTL אחרי שני סיבובים. פרפור נקבע לעומת זאת על ידי פרוטוקול הניתוב: הקידומת נסוגה, מותקנת מחדש או מוחלפת בקפיצה הבאה חלופית, כך שלחלק מהמנות אין נתיב בכלל בעוד אחרות הולכות בנתיב טוב לחלוטין.
שלוש הבדיקות שמכריעות את השאלה
אין צורך בלכידת מנות כדי לקבל את ההחלטה הראשונה. צריך את מצב הקידומת בשני הקצוות, את הקפיצה הבאה שכל צד בוחר, ומספר קפיצות שחוזר על עצמו או לא. אם הקידומת נשארת מותקנת עם אותה קפיצה הבאה בזמן שהתעבורה נכשלת, הלולאה חיה בנתיב ההעברה. אם הקידומת נעלמת וחוזרת, התקלה נמצאת מעל ההעברה והתיקון שייך לפרוטוקול הניתוב, לא לנתיב סטטי.
| Observation | Routing loop | Route flapping |
|---|---|---|
| Prefix in the table | Installed, same next hop throughout | Withdrawn and reinstalled, or next hop alternates |
| Hop count | Reaches zero at the same two gateways | Expires only while the prefix is missing |
| Failure shape | Consistent loss for that prefix from every source | Bursts, often after a link or peer event |
| Where the fix belongs | The site that owns the prefix, plus filters on the transit path | Advertisement, hold timers, or the flapping link |
אזהרה אחת לפני שמתחילים. אם אתם קוראים את זה דרך המנהרה שעושה לולאה, הסשן שלכם מת ברגע שתשנו את הנתיב. פתחו קונסולה או נתיב ניהול שאינו תלוי בקידומת שאתם עומדים לתקן.
בדיקה ראשונה: האם הקידומת יציבה או רוחשת
שאלו את הליבה מה היא התקינה, לא מה מבטיח קובץ התצורה. בשער לינוקס, ip route get 10.20.30.40 מריץ את אותה חיפוש שהנתיב להעברה מריץ, כולל טבלאות מדיניות, בעוד ip route show 10.20.30.0/24 מציג את הרשומה עצמה. ip monitor route משדר כל שינוי ברגע שהוא קורה, וזו הדרך המהירה ביותר לראות קידומת מגיעה ועוזבת.
בנתב שמריץ FRR או BIRD, טבלת ההעברה אינה המעניינת. show ip bgp 10.20.30.0/24 מחזיר את הנתיב הנבחר ואת זמן הפעולה שלו; זמן פעולה שמתאפס כל כמה דקות הוא פרפור שאפשר לתת לו שם, לא לולאה. show ip bgp summary מציג את מצב השכנים ואת ספירת הקידומות, כך שעמית שנופל כל הזמן מסיר את האשמה מנתיב ההעברה.
רשמו את התשובה לפני שתשנו משהו. יציבות עשר דקות בזמן שפינגים נכשלו, והיעלמות ארבע פעמים בעשר דקות, מובילות לצעדים הבאים שונים. השנייה הופכת כל תיאוריית נתיב סטטי לבלתי רלוונטית.
בדיקה שנייה: האם הקפיצה הבאה מצביעה בחזרה למנהרת ההגעה
לולאה דורשת שני שערים שמסכימים. באתר שקולט את המנות, הביטו בנתיב שהמנות תשתמש בו כדי לצאת: ip route get 10.20.30.40 from 10.10.5.20 עם כתובת המקור האמיתית, כי כלל מדיניות עשוי להשיב אחרת מהטבלה הראשית. אחר כך חזרו על החיפוש באתר ששלח אותה. אם כל צד בוחר בצד השני כקפיצה הבאה לאותה קידומת, הלולאה הוכחה ואף לכידה לא תוסיף דבר.
הסיבה היא כמעט תמיד הודעה שלא הייתה אמורה לחצות את המנהרה. נתיב ברירת מחדל שמופץ מחדש לתוך המנהרה, צביר שמכסה את תת-הרשת של האתר המרוחק עצמו, או נתיב סטטי שמצביע לעמית ליתר ביטחון — כולם יוצרים את אותה קפיצה הבאה הדדית. המנהרה יכולה להיות מותקנת במלואה ועדיין לשאת תעבורה במעגל; הערות ההעברה של strongSwan מתארות את צד הניתוב של הדרישה הזו.
WireGuard ראוי להערה משלו, כי אין הודעה להאשים. wg show מפרט את ה-AllowedIPs של כל עמית, והליבה מקבלת יעד עבור עמית רק אם הוא נופל בתוך הטווח הזה. לולאה שם היא טווח AllowedIPs חופף או נתיב סטטי שמצביע בחזרה דרך הממשק, ולכן התיקון חי בשני המקומות האלה ולא בשום מקום אחר.
בדיקה שלישית: קראו את מספר הקפיצות, לא את הכוכביות
traceroute -n -I 10.20.30.40 וגם mtr -n -r -c 20 10.20.30.40 מציגים את הנתיב, ומצב ICMP שורד לעיתים קרובות סינון שאוכל בדיקות UDP. לולאה נראית כמו רצף קצר וחוזר של אותן שתי כתובות שער עם TTL שעולה בכל פעם. נפילה נראית כמו כוכביות אחרי השער האחרון שהשיב, וקפיצה שקטה אחת אינה הוכחה לשום דבר.
כשהנתיב עמום, קראו את ה-TTL על החוט. tcpdump -ni any -vv icmp בשני השערים מציג את ה-TTL של כל מנה ואת כתובת המקור של כל תשובת זמן-שהופר. אם מנה מגיעה לאתר המרוחק עם TTL נמוך ממספר הקפיצות שהנתיב יכול להכיל, משהו מוסיף קפיצות ש-traceroute לא מראה לכם, וזה קורה כשחומת האש של אתר אחד עונה לבדיקות בשם אתר אחר.
תקנו את הבעלים של הקידומת, ואז אמתו את שני הכיוונים
החליטו איזה אתר יוצר את היעד ואילו נתיבי מעבר מותרים, ואז שנו את ההודעה או את הנתיב הסטטי אצל אותו בעלים. תיקון האתר הקולט מפתה ובדרך כלל שגוי: הוא מסתיר את הלולאה לקידומת אחת ומשאיר את ההודעה הרעה במקומה לבאה. תגי נתיב, רשימות הפצה וכללי split-horizon קיימים כדי לעצור את זה במקור, והם זולים יותר ממסנן שמתאים לקידומת אחת.
אחרי השינוי, אמתו בנפרד את הכיוון ההלוך ואת החזור, כי לולאה יכולה להיות מוחלפת בחור שחור בלי שיפור נראה בתסמין. הריצו ip route get משני הקצוות, שלחו תעבורה ממארח שאינו השער, והשאירו את ip monitor route פועל לפחות טיימר החזקה אחד כדי שפרפור לא ייחשב לתיקון.
לפני שתשנו משהו, אשרו את חמש הנקודות האלה: הקידומת יציבה או רוחשת, הקפיצה הבאה בשני הקצוות מצביעה למנהרה, מספר הקפיצות חוזר על עצמו או לא, אתר אחד מחזיק בקידומת, ויש לכם נתיב ניהול ששורד את השינוי. אם אחת מהחמש אינה ידועה, ארבע האחרות הן השערות.