מינהור מפוצל לפי אפליקציה מול לפי יעד: מה לבחור

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

שני הכללים פועלים בשכבות שונות

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

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

כללי אפליקציה מתאימים ללקוחות ניידים ולסוכנים מנוהלים

Android חושף את הבחירה ישירות: VpnService.Builder.addAllowedApplication() ו-addDisallowedApplication() מקבלים שמות חבילה ואוכפים את ההחלטה לכל UID, כמתואר במדריך המפתחים של VPN ב-Android. ב-iOS יש מקבילה באמצעות כללי VPN לכל אפליקציה המבוססים על מזהי צרור, שלרוב מסופקים בפרופיל MDM ולא מוקלדים ביד.

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

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

כללי יעד מתאימים לרשימות תת-רשתות ולנגישות אתרים

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

OpenVPN מגיע לאותו מקום דרך טבלת הניתוב הנדחפת. route-nopull מונע מהשרת להכתיב נתיבים, ואחר כך route 10.20.0.0 255.255.0.0 vpn_gateway בצד הלקוח מכסה בדיוק את קידומת המשרד. IPv6 הוא הצהרה נפרדת בכל אחד מהלקוחות האלה, ושכחה שלו היא הדרך הנפוצה ביותר לדלוף סביב פיצול IPv4 שנראה תקין.

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

היכן שני המודלים נשברים: תהליכי עזר, שירותים משותפים, פותרים

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

כללי יעד נשברים בשירותים משותפים ובשמות. שיתופי קבצים, מדפסות, DNS פנימי ושרת הרישוי חיים בכתובות, ולכן מנהור של אפליקציה אחת נותן לדפדפן גישה בעוד הכונן הממופה נשאר מת. הבדל הכיסוי הזה אינו באג באף אחד מהמודלים, אבל הוא הסיבה לכך שמנהור של אפליקציה אחת כל כך часто מייצר מצב שה-VPN פועל והשיתוף נעלם.

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

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

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

יישמו את הצורה הצרה ביותר שאתם יכולים לבטא, ואז אמתו בשאילת טבלת הניתוב ולא בסמל המצב של הלקוח:

ip route get 10.20.30.40
ip -6 route get 2001:db8:10::40
wg show wg0 allowed-ips
Get-NetRoute -DestinationPrefix 10.20.0.0/16
Find-NetRoute -RemoteIPAddress 10.20.30.40

שתי השורות הראשונות מזהות את הממשק שיעד אמיתי היה משתמש בו; wg show מדפיס את רשימת הקידומות המוגדרת; ב-Windows, Find-NetRoute עונה על אותה שאלה שהמחסנית תענה כשתישלח החבילה. אם הממשק הוא המנהור, הכלל התאים.

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