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

אתם מעבירים את ה-VPN למנהרה מלאה, רוב התעבורה מצייתת, ואז כתובת אחת עונה ישירות — מדפסת, NAS, מארח קפיצה ב-10.x. הקריאה המובנת מאליה היא שהמנהרה דולפת, אז אתם מורידים את המדד של נתיב ברירת המחדל ושום דבר לא משתנה. הניסיון הכושל הזה הוא הרמז: נתיב ברירת מחדל הוא גיבוי, לא פסק דין. חיפוש הנתיב לוקח את התחילית התואמת הארוכה ביותר לפני שהוא בכלל משווה מדדים, כך ש-/24 ממשיך לנצח את /0 לא משנה איזה מספר תצמידו לאחד מהם. ברגע שהסדר הזה ברור, הדליפה היא בדרך כלל נתיב שמישהו התקין בכוונה, או תחילית שהלקוח מעולם לא התכוון לכסות.

מה נתיב ברירת מחדל באמת מבטיח

0.0.0.0/0 מתאים לכל יעד IPv4 עם אפס ביטים של ספציפיות. הוא קיים כדי שמארח יוכל להגיע לכל דבר שהטבלה שלו לא מתארת טוב יותר. נתיב אל 192.168.1.0/24 נושא 24 ביטים תואמים, כך שעבור 192.168.1.40 הוא מנצח לפני שמישהו משווה מדדים, מרחק ניהולי או איך שהלקוח יקרא לשדה העדיפות שלו. אותו כלל תקף ב-FIB של לינוקס, בטבלת הניתוב של Windows ובמחסנית ה-BSD שמאחורי macOS.

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

חצאי נתיבי ברירת מחדל, או למה הרשומה הראשית יכולה להיראות ללא שינוי

הדוגמה הנקייה ביותר היא redirect-gateway def1 ב-OpenVPN. במקום למחוק את נתיב ברירת המחדל שלכם ולהחליף אותו, הוא מוסיף 0.0.0.0/1 ו-128.0.0.0/1. יחד הזוג מכסה את כל IPv4, כל תחילית ארוכה מ-/0, ושניהם מנצחים את ברירת המחדל של הנתב תוך השארתה במקומה. הריצו רשימת נתיבים אחר כך וברירת המחדל המקורית עדיין שם, עדיין מצביעה לשער שלכם; היא פשוט אף פעם לא נבחרת ליעדי אינטרנט.

wg-quick של WireGuard מגיע לאותה תוצאה דרך ניתוב מבוסס מדיניות. כש-AllowedIPs מכסה 0.0.0.0/0 הוא יוצר טבלה משלו, שולח לשם מנות מסומנות ומוסיף כלל שמתעלם מהתחילית באורך אפס של הטבלה הראשית. הטבלה הראשית שומרת על רשומת ברירת המחדל שלה, והכללים קובעים שטבלת המנהרה נשאלת ראשונה עבור התעבורה שהממשק מחזיק בה.

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

מדדים מכריעים תיקו, תחיליות מכריעות מנצחים

מדדים מושווים רק בין מועמדים שמתאימים ליעד באותה מידה. בלינוקס, ip route get 10.20.5.9 מדפיס את המנצח יחד עם הטבלה שלו, ו ip route show table all מפרט את המועמדים, כולל כל חצאי נתיבי ברירת מחדל וכל טבלה שכלל מצביע עליה. ב-Windows, Find-NetRoute -RemoteIPAddress 10.20.5.9 מחזיר את הנתיב הנבחר ואת כתובת המקור, בעוד Get-NetRoute מציג את הטבלה הגולמית — אבל העלות האפקטיבית היא מדד הנתיב ועוד מדד הממשק, כך שמתאם איטי יכול להפסיד תיקו שהוא נראה כזוכה בו.

שלושה מקרים מכסים את רוב מה שתראו:

• אותו יעד, /24 מול /0: ה-/24 מנצח באורך התחילית, יאמרו המדדים מה שיאמרו.
• אותו יעד, שני /24 עם מדדים שונים: המדד האפקטיבי הנמוך יותר מנצח.
• אותו יעד, שתי טבלאות, אחת נבחרת על ידי כלל מדיניות: הכלל בוחר קודם את הטבלה, והשוואת התחיליות מתרחשת בתוכה.

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

למי בדרך כלל שייכת העקיפה

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

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

ואז בדקו את IPv6 בנפרד. ip -6 route ו Get-NetRoute -AddressFamily IPv6 מחזיקים מצב נפרד, ברירות מחדל נפרדות והתנהגות לקוח נפרדת. ביקורת של IPv4 בלבד לא אומרת דבר על מארח עם מחסנית כפולה שמעדיף בשקט נתיב IPv6 מקורי, ורק זה יכול לגרום ללקוח להיראות כמו split-tunnel.

אשרו בעזרת הזרימה של האפליקציה עצמה

רשמו את היעד שהאפליקציה באמת משתמשת בו, ואז שאלו את המערכת על הנתיב שהיא הייתה נוקטת מכתובת המקור שאליה האפליקציה ההיא נקשרת. ip route get 10.20.5.9 from 192.168.1.40 עונה על כך בלינוקס; Find-NetRoute -RemoteIPAddress 10.20.5.9 ועוד הכתובת המקומית עושה זאת ב-Windows. השוו את התוצאה למה שהפרופיל טוען. עמוד ה-IP הציבורי של דפדפן בודק יעד אחד בפרוטוקול אחד ולא אומר דבר על הכתובת הפרטית שהתחילה את התלונה.

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

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

• ציינו את היעד ואת כתובת המקור שהאפליקציה באמת משתמשת בהם.
• הדפיסו את הנתיב המנצח עם ip route get או Find-NetRoute.
• בדקו אם זוג /1 או טבלת מדיניות מחזיק בנתיב האינטרנט.
• פרטו כל תחילית ארוכה מ-/0 שמתאימה ליעד.
• חזרו על בדיקת IPv6 בנפרד.
• עקבו אחרי הנתיב ששרד בחזרה לקובץ, לפרופיל או למסנן שמתקין אותו.
• התחברו מחדש והריצו שוב את השאילתה לפני שתכריזו שזה תוקן.

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