אפליקציה שנקשרת לכתובת ה-VPN עדיין משתמשת במסלול הלא נכון

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

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

מה קישור באמת מחליט

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

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

מדריך הסוקטים של IP ב-Linux מתעד את סמנטיקת הקישור. חצי הניתוב חי ב-ip-rule וב-ip-route, ואלה דפי מדריך נפרדים מסיבה.

ודאו שהכתובת שייכת למרחב השמות הזה

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

ip -br addr show
ip netns identify <pid>
ss -tanp | grep <port>

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

קראו את החיפוש עבור המקור והיעד האלה

פקודה אחת עונה על השאלה שהקישור לא ענה עליה:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

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

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

התקינו כלל מדיניות רק אם זה התכנון

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

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

ip route add default dev tun0 table 100
ip rule add from 10.8.0.2 table 100 priority 100
ip route get 203.0.113.10 from 10.8.0.2

בטלו עם ip rule del ו-ip route flush table 100. כל מה שנוסף כך נעלם באתחול מחדש אלא אם מנהל כותב אותו, וזה גם תכונת בטיחות וגם סיבה לא להחזיק את העותק היחיד בהיסטוריית ה-shell שלכם.

אמתו בשלוש תצפיות

רשמו את המקור שהאפליקציה ביקשה, את המסלול שהחיפוש בחר, ואת המקור שהשרת באמת ראה.

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

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