מדד מסלול של OpenVPN: למה המסלול הנבחר עדיין מפסיד

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

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

קראו את שורת המסלול לפי סדר השדות

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

עבור יעד פרטי השורה יכולה להיראות כך:

route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30

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

route-metric הוא ברירת מחדל, לא דירוג

route-metric קובע את ערך הגיבוי למסלולים שאינם נושאים מספר משלהם. הוא לא מעלה מסלול מעל משהו אחר, והוא לא מסדר מחדש מסלולים שהותקנו עם מדדים מפורשים.

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

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

בדקו מה הלקוח התקין

לאחר שההתחברות מחדש מסתיימת, שאלו את הגרעין ולא את הפרופיל.

ip route show מפרט את המסלולים שהלקוח הוסיף, ו-ip route get 172.20.5.10 עונה על השאלה השימושית יותר: איזה מסלול היעד הזה באמת ישתמש בו, ועם איזו כתובת מקור. אם היעד חסר בטבלה, הלקוח לא התקין אותו.

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

למה מדד קטן יותר עדיין מפסיד

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

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

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

כללי מדיניות רצים לפני הטבלה

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

השתמשו ב-ip rule show ואז שאלו את הטבלה הספציפית, למשל ip route show table 100, כדי לראות מה הכלל הזה יחזיר. אם לקוח VPN או סביבת הרצה של מכולות הוסיפו כלל, התשובה עשויה להיות שם ולא בטבלה שקראתם. גם כתובת המקור חשובה, כי כלל יכול להתאים למקור ולפתור את אותו יעד אחרת עבור תעבורת מנהרה ותעבורת LAN.

אמתו את היעד, לא את הדירוג

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

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