למה מסלול מארח /32 משאיר את נקודת הקצה של VPN נגישה

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

כתובת אחת, רשומה אחת בטבלה

מסלול מארח IPv4 נושא קידומת /32 ומסלול מארח IPv6 נושא /128, כלומר הרשומה יכולה להתאים בדיוק לכתובת יעד אחת. שום דבר אחר בטבלה לא זז: תת־הרשת שמכסה אותה ומסלול ברירת המחדל נשארים במקומם. הרשומה הצרה מנצחת עבור אותה כתובת מפני שהקידומת שלה ארוכה יותר, לא מפני שהיא נוספה מאוחר יותר.

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

קראו את הרשומה מהלקוח החוצה

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

ip route get 203.0.113.25
ip -6 route get 2001:db8:4::25
ip route show | grep -F 203.0.113.25
Find-NetRoute -RemoteIPAddress 203.0.113.25

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

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

חריג נקודת הקצה ומלכודת הרקורסיה

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

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

אמתו את הנתיב שהאפליקציה באמת משתמשת בו

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

ip route get 203.0.113.25
sudo nft list ruleset | grep -A 4 'chain output'
curl -sS --max-time 8 -o /dev/null -w '%{remote_ip}
' https://app.example.net

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

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