VPN לפי אפליקציה באפליקציות iPhone מנוהלות: מה מנותב ומה לא
מנהרה לפי אפליקציה עוקבת אחרי האפליקציה המנוהלת, לא אחרי הטלפון. בדקו את שיוך הפרופיל, את העותק המנוהל, את כללי ההפעלה לפי דרישה ואת הזרימות שיוצאות מהאפליקציה.
VPN לפי אפליקציה ב-iPhone אינו מתג לכל הטלפון. זהו שיוך בין אפליקציה מנוהלת אחת לפרופיל VPN אחד, שנוצר בעת פריסת האפליקציה, והתעבורה של כל השאר שומרת על המסלול שהיה לה קודם. לכן אותו טלפון מתנהג באופן לא עקבי: אפליקציית העבודה פותחת עמוד פרטי בעוד Safari אינו מגיע לאותו מארח, או שהמנהרה לא עולה כלל והאפליקציה מדווחת על פסק זמן שנראה כמו פרטי התחברות שגויים. הבדיקות רצות מהגורם הרחב ביותר ומטה, אז עצרו בראשונה שנכשלת.
בדקו תחילה את הפרופיל ואת רשומת האפליקציה
השיוך חי בשני אובייקטים, לא באחד. פרופיל ה-VPN מגדיר את המנהרה: סוג, שרת, אימות, DNS ומזהה החבילה של הספק כאשר משתמשים בלקוח מותאם. רשומת האפליקציה מצביעה על אותו פרופיל, ורוב קונסולות הניהול מציגות זאת כאפשרות לפי אפליקציה בתצורת האפליקציה, בשם קרוב ל-Per-App VPN. פרופיל שאין אפליקציה שמצביעה עליו אינו מנתב דבר לפי אפליקציה; הוא מתנהג כמנהרה רגילה שמישהו צריך להפעיל ידנית.
קראו את שני האובייקטים לפני שנוגעים בטלפון. ודאו שתצורת האפליקציה מפנה לפרופיל שאתם בודקים ולא לעותק ישן שלו, כי פרופילים כפולים בשמות כמעט זהים נפוצים לאחר העברה והאפליקציה תפנה בשמחה לזה שהוצא משימוש. אחר כך ודאו שהתצורה הגיעה למכשיר: הגדרות, כללי, VPN וניהול מכשיר חייבים להציג אותה כפרופיל מותקן. רשימת ה-VPN שם אינה המבחן. לשירות לפי אפליקציה בדרך כלל אין מתג ידני, לכן תצורה שנפרסה כראוי עשויה ללא להופיע עולם בין ה-VPN שניתן להפעיל. ההיעדר נראה ברשומת האפליקציה ובשאלה אם המנהרה עולה בבקשה הראשונה של האפליקציה.
תנאי אחד מסביר כרטיסים רבים: המודל הזה דורש שהאפליקציה תגיע דרך ניהול. עותק שהותקן מהצד או נרכש באופן אישי אינו מקבל את השיוך, גם כשמזהה החבילה שלו תואם. מדריך הפריסה של Apple ל-VPN מתאר את מודל הפרופיל שמאחורי זה (support.apple.com/guide/deployment/vpn-overview-depae3d361d0/web).
ודאו שהאפליקציה המותקנת היא העותק המנוהל
השיוך עוקב אחרי האפליקציה המותקנת והמנוהלת. אם מישהו התקין אותה מחדש מה-App Store תחת Apple ID אישי, החליף אותה בגרסת ארגון מחודשת חתימה, או שהמכשיר נרשם מחדש והאפליקציה חזרה בערוץ אחר, המנהרה עלולה להישאר למטה בעוד האפליקציה עצמה נראית רגילה לגמרי.
בדקו בהשוואה, לא בתצפית אחת. במלאי הניהול האפליקציה צריכה להופיע כמנוהלת עבור אותו מכשיר עם מיפוי ה-VPN ברשומתה. בטלפון המנהרה צריכה לעלות כשהאפליקציה מופעלת והבקשה הראשונה שלה יוצאת, לא רק כשמישהו מפעיל תצורה ידנית נפרדת בהגדרות. אם הפעלת האפליקציה לא משנה דבר והתצורה הידנית כן משנה, האפליקציה כלל אינה קשורה למנהרה לפי אפליקציה.
עדכונים חשובים: עדכון שנדחף דרך הניהול שומר על המיפוי, בעוד התקנה מחדש שיזם המשתמש עלולה לאבד אותו. כשהתלונה מתארכת לעדכון, בדקו את רשומת האפליקציה לפני הרשת.
בדקו מה המנהרה רשאית לקחת
מנהרה לפי אפליקציה נבחרת לפי אפליקציית המקור, כך שהמסלול המוגדר כברירת מחדל של הטלפון עדיין שייך ל-Wi-Fi או לרשת הסלולרית. OverridePrimary הוא המפתח שמשנה זאת. כשפרופיל מגדיר אותו, המנהרה מתנהגת כמנהרה מלאה וכל אפליקציה יורשת אותה, לכן כל מה שעובר דרך ה-VPN הופך לשאלת פרופיל ולא לתקלת אפליקציה.
כללי הפעלה לפי דרישה קובעים את ההתמדות. OnDemandEnabled עם מערך הכללים שלו הם מה שמחזיר את המנהרה כשהאפליקציה שולחת תעבורה, שורד מעבר מ-Wi-Fi לרשת סלולרית, או נופל כשהאפליקציה עוברת לרקע. פריסה שמתחברת ואז מתה בשקט כוללת בדרך כלל כלל שמתאים רק לבדיקה שלעולם לא מופעלת כשהאפליקציה בטלה.
אחר כך קראו את צד המסלולים בכנות. אם פרופיל ספק או ספק משנה מספק רשימת הכללה, מנהרה שנושאת רק 10.20.0.0/16 לא תישא שירות ב-10.30.0.0/16; זו הרשימה שעושה את עבודתה, לא כשל לפי אפליקציה. לפרופיל ה-iOS המובנה אין רשימת הכללה. בלעדיה הפיצול עוקב אחרי ברירות המחדל של הספק ו-IncludeAllNetworks, לא אחרי רשימה נסתרת.
בדקו את האפליקציה, ואז בדקו מה יוצא ממנה
בדקו עם שם, לא רק עם כתובת. פתירת מארח פנימי בתוך האפליקציה המנוהלת מוכיחה שגם ה-DNS עבר דרך המנהרה, כי הפרופיל קובע איזה פותר עונה ואילו דומיינים לחיפוש מיושמים. הניתוב יכול להיות מושלם בעוד חיפוש השם נכשל, ושני הסימפטומים מצביעים על הגדרות שונות.
אחר כך בדקו את הגבול משני הצדדים. אפליקציה אישית או Safari אמורים להגיע לעמוד ציבורי רגיל ולדווח על כתובת המפעיל או הבית, בעוד האפליקציה המנוהלת מגיעה לשירות הפרטי. אם שניהם מדווחים על אותה כתובת ציבורית, המנהרה כבר אינה לפי אפליקציה, מה שלא תרשום רשומת האפליקציה.
זרימות שיוצאות מהאפליקציה יוצרות את הכרטיסים המבולבלים. קישור שנפתח ב-Safari, מסמך שנמסר דרך גיליון השיתוף או כניסת SSO שעוברת לדפדפן יוצאים מתהליך האפליקציה ומהמנהרה יחד איתו. כניסה שמוצגת בתוך האפליקציה מיוחסת בדרך כלל לאפליקציה, לכן כניסה מוטמעת יכולה להצליח במקום שבו אותו URL נכשל ב-Safari; אמתו זאת במקום להניח. כשספק הזהות נגיש רק דרך המנהרה, או שמרו את הכניסה בתוך האפליקציה או הוסיפו את הדומיין של הספק לדומייני Safari של הפרופיל כדי שתעבורת Safari תואמת תילכד.
התאימו את הסימפטום לשכבה
צורת הכשל אומרת לך איזו בדיקה לחזור עליה.
| What you see | Where the repair is |
|---|---|
| Tunnel never appears when the app opens | App-to-payload association, or the app is not the managed copy |
| Tunnel connects, internal name resolves, connection times out | Provider or vendor include list missing the subnet, or a far-side firewall |
| Tunnel connects, internal name fails to resolve | DNS servers or search domains in the payload |
| Every app uses the tunnel | OverridePrimary set, or a full-tunnel payload reused |
| Worked until an update, broken since | Association lost on reinstall, or the payload was replaced |
מאחורי השורות האמצעיות עומדים שני פרטים: מנהרה לפי אפליקציה יכולה להיות תקינה ובכל זאת לפספס תת-רשת שאף רשימת ספק אינה כוללת, וטלפון מנוהל יכול להחזיק יותר מתצורת VPN אחת, אז ודאו לאיזה האפליקציה קשורה במקום להניח שזו זאת שאתם קוראים.
תקנו בסדר הזה: תקנו את רשומת האפליקציה כדי שתפנה לפרופיל הפעיל, התקינו את האפליקציה מחדש דרך הניהול, ודאו שהמנהרה עולה בבקשה הראשונה של האפליקציה, ואז חזרו על בדיקות השם והגבול. אם הבקשה הראשונה כלל אינה יכולה להפעיל מנהרה, עצרו ובדקו את צד הספק, כי לקוח מותאם צריך Network Extension קיים ומזהה שתואם לאפליקציה המותקנת.
החזירו שלוש עובדות במקום צילום מסך: לאיזה פרופיל מפנה רשומת האפליקציה, אם ההגדרות מציגות אותו כפרופיל מותקן, ומה הייתה הבקשה שנכשלה — שם, כתובת או העברה לדפדפן. שלוש התשובות הללו מפרידות טעות פריסה מטעות ניתוב, והאדם הבא יכול לפעול בלי לחזור על האבחון.