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

מה כל דגל עושה למסלול ברירת המחדל

ללא שום דגל, האפשרות מסירה את מסלול ברירת המחדל הרגיל ומעמידה את המנהרה במקומו, כך שהשער הישן נעלם מהטבלה כל עוד החיבור פעיל. הוסיפו def1 וברירת המחדל הזו נשארת ברשימה, ושני מסלולים צרים יותר עושים את העבודה. הוסיפו bypass-dhcp וגם מסלול ה-DHCP שורד, מה שחשוב ברשת שבה הלקוח עדיין צריך להגיע לשרת ה-DHCP המקומי. רשימת הדגלים ב עמוד המדריך של OpenVPN 2.6 קצרה מספיק לקריאה אחת, וכל ערך משנה אילו מסלולים יגיעו לטבלה.

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

def1 מנצח בזכות ספציפיות בלי לגעת בברירת המחדל שלכם

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

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

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

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

השאירו את קצה המנהרה נגיש

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

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

ip route get 198.51.100.20

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

תעבורת IPv6 ממשיכה להשתמש בטבלה של עצמה

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

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

ip -6 route show default
ip -6 route get 2001:db8::10

הוכיחו באיזה ממשק משתמשת אפליקציה

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

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

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

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

מאמרים קשורים