מדד המסלול של ה-VPN השתנה לאחר ההתחברות: מה זה אומר
מדד נמוך יותר רק מכריע בין מסלולים בעלי אותה מידת ספציפיות. קראו את כלל המדיניות, את הקידומת ואת מסלול המארח של נקודת הקצה לפני שתשנו מספר מסלול VPN כלשהו.
אתם מתחברים ל-VPN, מריצים route print, ומסלול ברירת המחדל נושא כעת מדד נמוך בהרבה מבעבר. המסקנה הטבעית היא שה-VPN תפס את מסלול ברירת המחדל מפני שהמספר שלו קטן יותר. לפעמים זה בדיוק מה שקרה. לעיתים קרובות המדד אינו הגורם המכריע כלל, ושינויו לא משנה דבר מפני שהבחירה נעשתה קודם לכן, לפי אורך הקידומת או לפי כלל מדיניות.
התסמין אמיתי: תעבורה שיצאה בעבר דרך מתאם ה-Wi-Fi יוצאת כעת דרך המנהרה, או להפך. המדד הוא קלט אחד בחיפוש שרץ בסדר קבוע, ואת הסדר הזה צריך לקרוא לפני שנוגעים במספר.
עם מה המספר באמת מתחרה
ההשוואה הראשונה היא ספציפיות, לא העדפה. מסלול ל-10.20.0.0/16 גובר על 10.0.0.0/8, ושניהם גוברים על 0.0.0.0/0, יאמרו המדדים שלהם מה שיאמרו. VPN שמתקין מסלול ברירת מחדל עם המדד הנמוך ביותר במחשב עדיין מפסיד לכל מסלול ספציפי יותר שמתאים ליעד, כולל מסלול המארח שהלקוח מתקין לשרת שלו עצמו.
לכן הורדת המדד במסלול ברירת מחדל אינה יכולה לכפות תת-רשת מחוברת ישירות לתוך המנהרה. אם אתם רוצים את תת-הרשת הזו בתוך ה-VPN, הוסיפו מסלול לקידומת או בחרו את טבלת המנהרה בכלל מדיניות. המדד הוא המנוף הלא נכון למשימה הזאת.
| Check in this order | Question | Where you read it |
|---|---|---|
| 1. Policy and table | Which routing table does this traffic use? | ip rule, client profile |
| 2. Prefix length | Which matching route is most specific? | route print, ip route |
| 3. Metric | Which of the equally specific routes is preferred? | route print, ip route |
| 4. Interface state | Is the chosen next hop reachable? | adapter status, link state |
לינוקס מכריע על הטבלה לפני המדד
בלינוקס הגרעין מתייעץ קודם עם בסיס הנתונים של המדיניות. ip rule מפרט את הכללים ואת הטבלאות שהם בוחרים, ו-ip route get 203.0.113.10 מדווח את הטבלה, המסלול וכתובת המקור שהגרעין היה משתמש בהם בפועל ליעד הזה. מדד בתוך טבלה 100 אינו מתחרה לעולם במסלול בטבלה הראשית, מפני שהכלל בחר את הטבלה לפני שהושווה מדד כלשהו.
לכן מסלול יכול להיראות נכון ב-ip route show table all ובכל זאת לא לשאת תעבורה. קראו את הכלל שהתאים, אחר כך את הטבלה שהוא בחר, ואחר כך השוו את המסלולים שבתוכה. אם נבחרה הטבלה הלא נכונה, שום עריכת מדד בטבלה האחרת לא תעזור.
ווינדוס משלב שני מדדים
לווינדוס אין בסיס נתונים של מדיניות כברירת מחדל, אבל הוא משלב מדד מסלול עם מדד ממשק, ומדד הממשק האוטומטי יכול להשתנות עם מהירות הקישור ומצב המתאם. לכן אותו מסלול יכול להתנהג אחרת לאחר שמופיע תחנת עגינה או מתאם וירטואלי. Find-NetRoute -RemoteIPAddress 203.0.113.10 מדווח את כתובת המקור, הקפיצה הבאה והממשק שנבחרו, וזה קרוב יותר להחלטה האמיתית מאשר הטבלה הגולמית.
קראו את ערכי המסלול והממשק יחד. העלאת מדד ממשק יכולה להזיז תעבורה בלי שאף רשומת מסלול תשתנה, ו-לקוח VPN שמחזיק במסלולים שלו יתקין אותם מחדש בהתחברות חוזרת ויזרוק את העריכה שלכם.
החזיקו את נקודת הקצה של המנהרה מחוץ למנהרה
כל מנהרה זקוקה לנתיב לשרת שלה עצמה שאינו עובר דרך המנהרה. לקוחות מתקינים מסלול מארח לנקודת הקצה דרך שער פיזי, והמסלול הזה חייב להישאר ספציפי יותר ממסלול ברירת המחדל שהלקוח מוסיף. מחקו אותו, או תנו למנהרה לנצח בחיפוש אחר הכתובת הזו, והחבילות העטופות ינסו להיכנס למנהרה שאמורות לבנות. החיבור נכשל או נכנס ללולאה.
בדקו את מסלול המארח הזה לפני ואחרי כל שינוי מדד: הוא צריך להצביע על הקפיצה הפיזית הבאה ולשרוד התחברות חוזרת. אם הלקוח מחזיק בו, שנו את הפרופיל או את התצורה המנוהלת במקום ערך זמן ריצה שיידרס.
בדקו את שתי משפחות הכתובות ואת ההקשר של היישום
IPv4 ו-IPv6 הם החלטות נפרדות עם טבלאות נפרדות. VPN יכול לשאת IPv4 בזמן ש-IPv6 ממשיך להשתמש בנתב המקומי, ושינוי מדד במשפחה אחת אינו אומר דבר על האחרת. בדקו את שתיהן, ואז בדקו את הקשר היישום. תהליך שקשור לממשק, מרחב שמות של מכולה או VPN לכל יישום עשוי לראות טבלה אחרת מהמעטפת שלכם.
אמתו בכלי שמדווח את ההחלטה ליעד האמיתי, ולא לפי רשימת הטבלה המלאה. אם המסלול שנבחר הוא זה שהתכנון מתכוון אליו, עצרו. מדד שאינו המספר הקטן ביותר על המסך אינו תקלה, וכפייתו להיות הקטן ביותר עלולה לשבור את נתיב נקודת הקצה שהמנהרה תלויה בו.