מדוע VPN עם מנהרה מלאה מסתיר את ה-VLAN המקומיים הניתבים שלכם

המתג «allow local network» בלקוח VPN נשמע כאילו הוא מכסה הכול בבניין. בפועל הוא בדרך כלל מוסיף כמה חריגים של כתובות פרטיות למסלול ברירת המחדל של המנהרה ועוצר שם. ה-VLAN שלכם לאחסון נשאר נגיש רק אם מסלול לאותה קידומת מדויקת שורד את הגעת המנהרה, ובלקוחות רבים הוא לא שורד.

זו שאלה של ניתוב ולא הגדרה של VPN, וזה חדשות טובות: יש לה תשובה קונקרטית.

מה allow-local-network באמת מכסה

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

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

מסלולים מחוברים נעצרים בנתב הראשון

תחנת עבודה בכתובת 192.168.10.20/24 עם שער 192.168.10.1 מקבלת אוטומטית מסלול מחובר עבור 192.168.10.0/24. ה-VLAN לאחסון בכתובת 192.168.20.0/24 הוא קידומת אחרת, נגיש רק דרך אותו שער, ולתחנת העבודה אין מסלול עבורה מעבר למסלול ברירת המחדל. לפני שהמנהרה עולה, מסלול ברירת המחדל הרגיל שולח במקרה את תעבורת האחסון אל 192.168.10.1 והכול עובד.

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

הפיתוי הוא לשלוח יד לחריג רחב כמו זוג מסלולי /1 או מסלול ברירת מחדל שני. התנגדו לכך. ככל שהחריג צר יותר, כך קל יותר להסביר, לבקר ולהסיר אותו כשהרשת משתנה.

שימו את החריג בטבלה שמנצחת

בתוך טבלת ניתוב אחת, /24 מנצח /0 או /1 בזכות התאמת הקידומת הארוכה ביותר, ולכן מסלול ספציפי אל ה-VLAN לאחסון דרך השער המקומי מספיק, בתנאי שהטבלה נבדקת בכלל. בלינוקס הצורה הרגילה קצרה:

ip route add 192.168.20.0/24 via 192.168.10.1 dev eth0

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

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

שמות ומדיניות לא עוקבים אחרי מסלולים

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

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

חוזה שאפשר למסור

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

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

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