המסלול נדחה בגלל ביטי מארח? מצאו את הקידומת שהתכוונתם אליה

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

על מה המנתח באמת מתלונן

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

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

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

קחו מנהרה שצריכה להגיע אל 172.20.130.0 עם מסכה /20. מסכה /20 שואלת ארבעה ביטים מהאוקטט השלישי, ולכן האוקטט הזה נספר רק בצעדים של 16: 0, 16, 32 והלאה עד 240. הערך 130 נופל בין 128 ל-143, כלומר הרשת המקיפה מתחילה ב-172.20.128.0, ולא ב-172.20.130.0 עם האוקטט האחרון מאופס.

בכתב, הבלוק נע בין 172.20.128.0 ל-172.20.143.255 ומחזיק 4,096 כתובות. הזנת אותם ערכים למנתח לא קפדני מציגה את ההחלפה שהוא היה עושה בשמכם:

$ python3 -c "import ipaddress; n=ipaddress.ip_network('172.20.130.0/20', strict=False); print(n, n.num_addresses)"
172.20.128.0/20 4096

החליטו איזה יעד באמת התכוונתם

השורה שנדחתה מסתירה בדרך כלל אחת משלוש כוונות, ורק אתם יכולים לבחור. אם המנהרה צריכה את כל הבלוק, כתבו 172.20.128.0/20, כתובת הרשת הקנונית. אם המנהרה צריכה רק את המקטע 130, המסכה הייתה שגויה ו-172.20.130.0/24 היא הצורה הכנה. אם היעד הוא מכונה אחת, מסלול מארח IPv4 הוא /32 ואין שום אריתמטיקת מסכות מעורבת.

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

למה ההעברה מעולם לא הייתה הפתרון

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

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

בדקו את המסלול המותקן ואת הנתיב שהוא זוכה בו

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

שאלו כתובת חבר וגם אחת מחוץ לבלוק, כדי שההשוואה תהיה משמעותית ולא שורה מרגיעה אחת:

ip -4 route show 172.20.128.0/20
ip -4 route get 172.20.140.10
ip -4 route get 172.20.200.10

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