VPN לכל אפליקציה או split tunnel? מה נתיב ב-Mac יכול להחליט

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

הבורר הוא יעד, ולעולם לא תהליך

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

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

מה split tunnel רגיל נותן בפועל

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

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

מה דורש VPN לכל אפליקציה ב-macOS

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

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

שלוש דרכים להפרדה לפי אפליקציה בלי MDM

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

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

נסחו את הבקשה כך שהתשובה תהיה חד-משמעית

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

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