מה bypass-dhcp באמת מוסיף לתוכנית מסלולים של OpenVPN

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

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

שני דגלים, שתי משימות לא קשורות

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

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

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

למה החריג באמת מוגבל

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

0.0.0.0/1        via 10.8.0.1      dev tun0
128.0.0.0/1      via 10.8.0.1      dev tun0
192.168.1.1/32   via 192.168.1.254 dev wlan0

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

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

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

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

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

שאר המסלול אינו בדגל הזה

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

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

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