תנו למארחי ה-LAN נתיב חזרה ל-VPN עם אפשרות 121 של DHCP

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

קודם כל תנו שמות לשלוש הכתובות

קחו LAN קונקרטי: 192.168.50.0/24 עם נתב ברירת המחדל הרגיל ב-192.168.50.1 ושער VPN נפרד ב-192.168.50.2. לקוחות מרוחקים מאומתים תופסים את 10.90.0.0/24.

הנתיב שכל מארח משתתף צריך הוא 10.90.0.0/24 via 192.168.50.2. היעד הוא מאגר הלקוחות, והצעד הבא הוא כתובת ה-LAN של השער ולא כתובת המנהרה שלו.

קודדו אותו כנתיב סטטי ללא מחלקות

אפשרות 121 נושאת זוגות של קידומת וצעד הבא, ו-RFC 3442 מגדיר גם את הקידוד וגם את התנהגות הלקוח שנובעת ממנו. עבור מופע dnsmasq קיים שמשרת רק את ה-LAN הממחיש הזה, צורת התצורה היא:

dhcp-option=121,10.90.0.0/24,192.168.50.2,0.0.0.0/0,192.168.50.1

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

אל תאבדו את נתיב ברירת המחדל

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

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

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

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

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

אמתו את החכירה, ואז את החיפוש

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

בלקוח Linux, קראו את הנתיבים בפועל ואמתו את שתי הרשומות:

ip -4 route
ip -4 route get 10.90.0.23

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

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

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

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