שמרו על המסלולים הפרטיים והסירו את ההפניה: מנהרת OpenVPN מפוצלת
מנהרה פרטית בלבד זקוקה לשני כללים: קידומות פרטיות עוברות דרכה, וגלישה רגילה שומרת על הנתיב המקומי שלה. מחיקת נתיב ברירת מחדל אינה מדיניות.
המנהרה עולה, היישום נטען, ואז כל השאר במחשב הנייד מתחיל להתנהג מוזר. זו הצורה הרגילה של מדיניות פרטית בלבד שמומשה על ידי מחיקת שורה אחת. הסרת נתיב ברירת מחדל שנדחף אכן משנה לאן הולך התעבורה, אבל היא לא אומרת לאן התעבורה אמורה ללכת במקום, והיא כלל לא נוגעת בפתרון שמות. מדיניות זקוקה לשני חצאים חיוביים לפני שאפשר לבדוק אותה.
מחיקת ההפניה היא רק חצי מהשינוי
הפניה של מנהרה מלאה ומדיניות פרטית בלבד נבדלות במה שהן טוענות על העולם. ההפניה תובעת כל יעד, ואילו המדיניות הפרטית תובעת רשימה ומשאירה את השאר בשקט. מחיקת התביעה בלי לכתוב את הרשימה מייצרת לקוח שלא מגיע לשום מקום מחוץ לרשת המקומית, וזה נראה כמו כשל ניתוב ולא כמו פער במדיניות. כתבו את הרשימה לפני שאתם מסירים את התביעה, ואז סדר שני השלבים האלה מפסיק להיות חשוב.
שני החצאים הם דרישות ולא ברירות מחדל. קידומות פרטיות חייבות להיכנס למנהרה, ויעדים רגילים חייבים לשמור על הנתיב שהיה להם לפני החיבור.
אם ארגון מחייב מנהרה מלאה, שום דבר מזה לא חל. העיצוב הפרטי בלבד שייך לפריסות שבהן ניתוב מפוצל מאושר.
pull-filter הוא התאמה, לא מתג
ההוראה pull-filter מסירה אפשרויות שנדחפו ושמותיהן תואמים קידומת, וזה כל מה שהיא עושה. התעלמות מההפניה משאירה כל אפשרות נדחפת אחרת במקומה, וזה בדרך כלל מה שרוצים: מסלולים, הגדרות DNS וערך שער הניתוב עדיין מגיעים. היא גם לא יכולה להסיר הוראה הכתובה בפרופיל המקומי, מפני שהסינון חל על מה שהשרת דוחף.
התנגדו לפיתוי להתעלם מכל אפשרות שמתחילה ב-route. התבנית הזו גם משליכה את המסלולים הפרטיים שהחיבור זקוק להם, והיא עלולה לאבד מידע על השער שהמנהרה תלויה בו.
route-nopull הוא החלטה רחבה יותר משהוא נראה. הוא מונע מהלקוח לקבל מסלולים שנדחפו ואפשרויות בסגנון DHCP כקבוצה, וזו מדיניות שונה מסינון אפשרות אחת.
כתבו את רשימת המסלולים מהיישום החוצה
התחילו ממה שהמשתמש באמת פותח, ואז הוסיפו את החלקים התומכים. יישום בכתובת 10.60.20.15 מרמז על תת-הרשת שלו 10.60.0.0/16, ושם פרטי מרמז על הפותר שעונה לו. לכן משתמש שביקש יישום אחד זקוק לשני יעדים ולהחלטת DNS אחת. כל מה שמעבר לרשימה הזו מחוץ לתחום מכוח הבנייה, וזה מה ששומר על המדיניות ניתנת לבדיקה.
בשרת שמשתף פעולה אלה הופכים לשני מסלולים שנדחפו, ואף אחד מהם אינו הפניה. שמרו על טופולוגיית המנהרה ועל ערכי שער הניתוב שהשירות הקיים מספק.
כשרק חלק מהמשתמשים זקוקים למדיניות הזו, הפעילו אותה לכל לקוח או לכל קבוצה. שינוי הניתוב של כולם כדי לתקן דרישה של צוות אחד הוא הדרך שבה מנהרה מפוצלת הופכת להפסקת שירות.
| Destination | Intended path |
|---|---|
10.60.0.0/16 | Tunnel, for the approved application services |
10.61.0.53/32 | Tunnel, to reach the internal resolver |
corp.example queries | Internal resolver, selected per namespace |
| Everything else | Local path and local resolver |
תנו ל-DNS ללכת באותו נתיב
נתיב אל הפותר אינו מדיניות פותר. בלקוח systemd-resolved התוצאה הסמנטית היא דומיין ניתוב עבור מרחב השמות הפרטי שמצביע על הפותר הפנימי, וזה מה שגורם לרק השמות האלה להשתמש בו. לקוח Windows זקוק במקום זאת למנגנון מדיניות מרחב שמות משלו. שורת שרת DNS בפרופיל אינה מתקינה אף אחד מאלה מעצמה.
בדקו מה מערכת ההפעלה בחרה ולא מה הפרופיל ביקש. בלינוקס resolvectl status מציג את הדומיין ואת השרת לכל קישור; ב-Windows טבלת מדיניות מרחב השמות היא הראיה המקבילה.
השאירו את הפותר נגיש דרך המנהרה, אחרת המדיניות מצביעה על כתובת שאי אפשר לשאול אותה. כתובת פותר שהמנהרה לא מגיעה אליה הופכת מדיניות עובדת לפסק זמן.
אמתו את שני החצאים בחיבור מחדש
חברו את הלקוח מחדש אחרי השינוי ובחנו את הנתיב האפקטיבי לכתובת פרטית ולכתובת ציבורית. אחר כך פתרו שם פרטי ושם ציבורי וודאו שכל אחד השתמש בפותר המיועד. טעינה של אתר ציבורי מוכיחה רק את החצי השני, וזה החצי שבדרך כלל עובד במקרה.
רשמו את המדיניות המוגמרת במשפט אחד: הקידומות והשמות האלה משתמשים בחיבור הזה, כל השאר הולך בנתיב המקומי. אחר כך שמרו אותה בפרופיל במקום לתקן הגדרות מתאם אחרי כל התחברות.