אפליקציה כבולה לממשק? נתיב ה-VPN שלה אינו ברירת המחדל

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

שלוש כריכות שונות, שלוש השפעות שונות

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

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

קבעו מה האפליקציה באמת מגדירה

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

ב-Linux לאפשרויות socket כמו SO_BINDTODEVICE יש היקף ודרישות הרשאה מתועדים, ותהליך ללא הרשאות עשוי שלא بتوان להגדיר אותן כלל. המגבלה הזו היא רמז שימושי: אם אי אפשר להחיל את האפשרות, סביר שהאפליקציה אינה מקור ההבדל.

ניתוב מדיניות קורא את המקור

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

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

מנהרה מפוצלת ותהליכי עזר

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

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

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

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

מדריך ה-socket של Linux מתעד את SO_BINDTODEVICE ואת דרישותיו. קראו קודם את התצורה של האפליקציה עצמה, שחזרו את החיפוש באותו הקשר ורק אז החליטו אם הנתיב או הכריכה צריכים להשתנות.