איזה כלי macOS יכול לכפות על אפליקציה אחת לעבור רק דרך ה-VPN?
גבול של VPN בלבד זקוק גם לנתיב וגם לסירוב. השוו פרופילים לפי אפליקציה, פרוקסים, מסננים ו-PF, ואז בדקו את האפליקציה היחידה שחשובה לכם.
שורה אחת במסמך דרישות — „האפליקציה הזו רשאית להשתמש ב-VPN, ושום דבר אחר“ — מבקשת בשקט שני מנגנונים שאף מתג יחיד אינו מספק. לתעבורה דרוש נתיב דרך המנהרה המיועדת, ותעבורה שיוצאת ישירות חייבת להידחות. כלים שעושים אחד מהם היטב ואת השני בכלל לא נפוצים, ולכן השוואה ששואלת רק אם משהו יכול לחסום עונה בביטחון על חצי מהשאלה. כתבו קודם את הגבול, ואז בחרו את הרכיבים שמכסים את שני החצאים שלו.
שתי דרישות שמסתתרות במשפט אחד
הכוונה היא החלק שמכניס חיבור למנהרה או לפרוקסי. הסירוב הוא החלק שמונע מאותו חיבור לצאת בכל נתיב אחר. רכיבים שונים מיישמים אותם, הם נכשלים בדרכים שונות, ומוצר יכול להיות מצוין באחד ולא לומר דבר על השני:
| Approach | Steers traffic | Refuses direct egress | Knows the app identity |
|---|---|---|---|
| Per-app VPN profile | Yes, for the apps it names | Only if a filter or firewall also blocks | Yes, within its own rules |
| Application proxy setting | Partly, for requests that honour it | No | No |
| Content filter | No | Yes | Yes, if the filter is written that way |
| Local PF ruleset | No | Yes, by address and port | Not reliably |
קראו את הטבלה כרשימת בדיקה ולא כדירוג. אף שורה אינה ממלאת את שתי העמודות האמצעיות, והשורות שמכסות אותן הן שני רכיבים שמשתפים פעולה: האחד מחזיק בנתיב והשני בסירוב. עמודת הזהות חשובה מסיבה אחרת, כי כלל שאינו יכול לנקוב בשם האפליקציה אינו יכול לאכוף כלל לגביה. כל מה שתפרסו חייב לענות על שלושתם, אחרת הגבול במסמך הדרישות אינו הגבול במכונה.
הכוונה לבדה משאירה מוצא
הגדרת פרוקסי של אפליקציה היא הדוגמה הברורה ביותר להכוונה בלי סירוב. היא יכולה להכוין בקשות של אפליקציה שמכבדת את פרוקסי המערכת, והיא אינה מכסה דבר אחר: תהליך עזר, מעדכן, שירות רקע או פרוטוקול אחר יכולים לנסוע בנתיב שלהם בלי לקרוא אי פעם את ההעדפה הזו. לכן בחירת נקודת קצה SOCKS בחלון אחד אינה יוצרת מדיניות של היעדר יציאה ישירה עבור היישום. אם הדרישה עוסקת באפליקציה כשלם, שאלו אילו רכיבים הכלל מזהה באמת.
פרופיל VPN לפי אפליקציה מכוון טוב יותר מפרוקסי, מפני שהפלטפורמה מחליטה אילו אפליקציות נכנסות למנהרה במקום שכל אפליקציה תחליט בעצמה. אף על פי כן הוא אינו מסרב לשום דבר: הפרופיל מספק נתיב, ותעבורה שאינה מתאימה לו נוקטת בנתיב הרגיל. בדיוק הפער הזה הוא המקום שבו רכיב שני זוכה במקומו, ולכן מוצרים שנראים כמו מתג אחד הם בדרך כלל שניים.
סירוב לבדו שובר את האפליקציה
התיעוד של Apple על מסנני תוכן מתאר פסק דין של היתר-או-חסימה על תעבורה בעודה עוברת במחסנית הרשת. פסק דין זה אינו מנהרה ואינו חיבור פרוקסי, מפני שהוא מחליט אם משהו רשאי להמשיך ולא לאן הוא הולך. מסנן לבדו אוכף את הסירוב בצורה מושלמת ומשאיר את היישום לא שמיש, עם יומנים נקיים ובלי הסבר. פסק דין של מסנן יכול לעצור חיבור אך אינו מספק לעולם את המנהרה, ולכן שילובו עם הכוונה הוא החלטת התכנון ולא תוספת רשות.
מערך כללי PF המנוהל מקומית נמצא בקצה השני של הספקטרום הזה. זו החלטת תמיכה לגיטימית במכונה שבבעלות מנהל, והיא אינה אוטומטית היסוד של מוצר שניתן להפיץ, מפני מי שמחזיק במערך הכללים מחזיק גם באינטראקציות שלו עם משתמשי חומת אש אחרים, בנתיב השדרוג שלו ובשחזור שלו כשכלל שגוי. הוספת PF למוצר אינה מסירה את שאלת הבעלות הזו; היא מגדירה אותה.
הפריסה מחליטה אם הכלל עוד קיים מחר
האופן שבו Network Extension נפרס בפלטפורמות של Apple תלוי בסוג הספק, באריזה ובגרסת מערכת ההפעלה שלפניכם. הרחבת אפליקציה ב-macOS פועלת בהקשר משתמש ומסתיימת כשמשתמש זה מתנתק, ואילו להרחבת מערכת יש הקשר גלובלי שאינו תלוי בהפעלה. אם ההגנה צריכה לשרוד התנתקות, ההבדל הזה הוא כל התכנון ולא הערת שוליים. אשרו את נתיב הפריסה לפני שאתם מבטיחים את ההתנהגות, מפני שאותו קוד נוחת אחרת בהתאם לסוג ההרחבה שנשלח.
זמינות קוד המקור היא עניין נפרד מאכיפה. קריאת מאגר אומרת לכם איך משהו מיושם, לא מה הקובץ הבינארי המותקן רשאי לעשות במכונה הזו. חתימה, התקנה והרשאה עדיין חלות, והוראות שנבנו סביב הרחבת ליבה מיושנת או תחבולת הזרקת ספרייה מתארות פלטפורמה אחרת ועמדת סיכון אחרת, ככל שפעלו פעם בטוב.
מקרה קבלה שמנקב בשם האפליקציה
בחרו פעולה אחת שהאפליקציה מבצעת מעצמה, רשמו את הכתובת שהיא אמורה להגיע אליה ואם הכתובת היא IPv4 או IPv6, ואז חזרו על אותה פעולה במצב המאושר בלי מנהרה. הריצה השנייה חייבת להפיק את הסירוב המוצהר ולא ניסיון חוזר ישיר ושקט. זה החצי שאנשים משאירים לא מוגדר, והחצי היחיד שמוכיח שהסירוב קיים בכלל. הריצו אותו תחילה כשהמנהרה זמינה, כדי שההבדל בין שתי התוצאות יוכל לבוא רק מהמנהרה החסרה.
לאחר מכן עברו על המעברים שהדרישה מזכירה: הפעלה מחדש של האפליקציה, תהליך עזר שמתעורר, התחברות מחדש של המנהרה, החלפת רשתות במכונה, והתנתקות או אתחול היכן שרלוונטי. דף IP ציבורי בדפדפן אינו בדיקה של השקעים של אפליקציה אחרת, ולכן אינו יכול להחליף את זו. במקום שבו שום פריסה נתמכת אינה מכסה את ההתנהגות האמיתית של האפליקציה, סביבה מבודדת מורשית עם שער מפורש ובלי יציאה חלופית היא החלטת בלימה עם עלות ניהול משלה, לא תחליף לתיבת סימון.
סיימו בכתיבת ארבעה סעיפים: מאילו רכיבים מורכבת האפליקציה, מי מחזיק בהכוונה, מי מחזיק בסירוב, והמצבים שבהם הכלל חייב עדיין לחול. מאגר ציבורי יכול להיות קריטריון בחירה אחד, אבל הוא אינו אחד מהארבעה, והסעיפים האלה הם שקובעים אם כלי נתון עומד בדרישת הרשת.