מסלול ברירת המחדל הישן שלך שורד את OpenVPN בכוונה

אתם מתחברים למנהרה, מריצים ip route, ושער ברירת המחדל המקורי עדיין שם. המחשבה הבאה היא שהלקוח לא השתלט על המסלול, אז אתם מוחקים את ברירת המחדל ידנית ומאבדים את הקישוריות לגמרי. הרשומה הזו אמורה להישאר. עם redirect-gateway def1, OpenVPN מתקין שני מסלולים ספציפיים יותר שעוקפים את ברירת המחדל הרגילה במקום להחליף אותה. השער הישן נשאר ומפסיק לשאת את התעבורה שבדקתם.

מה def1 באמת עושה

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

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

למה /1 ולא /0

הניתוב בוחר את הקידומת המתאימה הארוכה ביותר, לא את המדד הנמוך ביותר, כך ש-/1 מנצח /0 לא משנה מה אומר המדד של ברירת המחדל. שני החצאים קיימים כי /1 אחד מכסה רק חצי מהמרחב; כשרק 0.0.0.0/1 קיים, כל מה מ-128.0.0.0 ומעלה עדיין הולך אחרי ברירת המחדל הישנה, מה שיוצר את התסמין המבלבל שבו חלק מהאתרים עובדים ואחרים לא.

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

קראו טבלת ניתוב אמיתית

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

default via 192.168.50.1 dev wlan0
0.0.0.0/1 via 10.8.0.1 dev tun0
128.0.0.0/1 via 10.8.0.1 dev tun0

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

בדקו איזה מסלול החבילה באמת לוקחת

מסלולים ספציפיים יותר עדיין יכולים לנצח: מסלול לטווח פרטי, תת-רשת מקומית או הכתובת של שרת ה-VPN עצמו ארוכה מ-/1. המנהרה זקוקה לנתיב חיצוני לשרת שלה, ושליחת החיבור הזה חזרה למנהרה תשבור אותו מיד. ב-Linux שאלו את הליבה במקום לקרוא את הטבלה בעין: ip route get עם היעד שמעניין אתכם מדפיס את המסלול שנבחר, הממשק והמקור. אם מוגדר ניתוב לפי מדיניות, בדקו גם את הכללים, כי כלל יכול לבחור טבלה אחרת לפני שהטבלה הראשית נבדקת.

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

מה def1 לא מכסה

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

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