אפליקציית העבודה דורשת VPN? בדקו קודם את שלוש השכבות האלה

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

מה האפליקציה עצמה יכולה לבדוק

לפני שמניחים חוק פלטפורמה נסתר, זכרו כי אפליקציה רגילה יכולה לראות אם תעבורת VPN פעילה. ConnectivityManager מדווח על רשתות שנושאות TRANSPORT_VPN, והיעדר NET_CAPABILITY_NOT_VPN אומר לכל קורא שהמסלול הנוכחי עובר במנהרה. מפתח שרוצה לסרב לפעול מחוץ למנהרה יכול לעשות זאת עם ממשקי API ציבוריים ובלי שום כלי ארגוני.

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

מסלול השירות: שמות וכתובות פרטיים

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

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

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

שכבת מדיניות האפליקציה

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

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

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

שכבת הפלטפורמה: תמיד פעיל ונעילה

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

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

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

להבדיל בין השלושה

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

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

מה לכלול בבקשת התמיכה

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

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

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