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

שתי תת-מערכות אחראיות לשתי השאלות

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

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

מה באמת משנה החרגה לפי אפליקציה

בונה של VpnService יכול לתת שמות לחבילות שנשארות מחוץ למנהור באמצעות addDisallowedApplication, או לתת שמות לחבילות היחידות המותרות בפנים באמצעות addAllowedApplication. האפליקציות האלה פותחות אז שקעים ברשת שמתחת, בעוד ה-VPN ממשיך להחזיק בנתיב ברירת המחדל לכל השאר.

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

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

איך נראית מנה משותפת מבחינת הטלפון

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

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

איזו מדיניות באמת דרושה להחרגת הוט ספוט

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

SourceDestinationIntended path
One authorized hotspot clientOne approved public service addressOrdinary cellular uplink
The same clientAll other covered destinationsShared VPN
The phone's own appsTheir existing destinationsUnchanged phone policy

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

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

כתובת אחת שנלכדה אינה יעד

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

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

אמתו מהצד המורד

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

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

מאמרים קשורים