היכן חייבת לחיות כלל חומת אש של אנדרואיד כשמופעל VPN

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

מתחילים מהמשפט, לא מהמוצר

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

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

שלב 1: מה הטלפון עצמו יכול לאכוף

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

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

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

שלב 2: מה השער יכול לאכוף

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

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

שלב 3: פרטו את מה שלעולם לא מגיע

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

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

שלב 4: שייכו כל כלל לנתיב

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

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

שלב 5: שמרו על התעבורה חיה, ואז אמתו

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

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

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