ניתוב רקורסיבי: כשהמנהרה לוכדת את החבילות של עצמה

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

בדקו קודם את הנתיב החיצוני

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

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

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

למה החיבור שורד לרגע

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

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

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

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

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

בדקו שוב אחרי שינוי רשת

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

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

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