איך מנהרה מפוצלת מחליטה איזה תעבורה משתמשת ב-VPN

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

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

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

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

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

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

כריכה לפי אפליקציה וקידומות יעד הן כלים שונים

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

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

DNS ומתג העצירה הולכים לפי הכללים שלהם

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

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

בדקו את ההפרדה משני הצדדים

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

ip route get 203.0.113.10
ip route get 198.51.100.25
resolvectl query intranet.example.com
curl -s --interface tun0 https://example.com -o /dev/null -w '%{http_code}\n'

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

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