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

שניים מהחריגים האלה מסבירים את רוב הבלבול, ושניהם נוגעים לשירות הסלולרי.

התחילו בפרופיל המנוהל, לא בלכידה

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

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

קראו את החריג הסלולרי כשני מקרים שונים

בתצורות נתמכות, ExcludeCellularServices מחריג תעבורת שירות סלולרי שניתנת לניתוב דרך האינטרנט, אבל רק כשהן מופעל לצד IncludeAllNetworks. הסכימה נותנת את Wi-Fi Calling, IMS ושירותים הקשורים להודעות כדוגמאות לקטגוריה הזו. זרימות אלו יכולות לצאת מהמנה לפי התכנון, ושום סקירת פרופיל לא תעביר אותן דרכה כל עוד החריג פעיל.

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

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

בדקו אילו מפתחות הפלטפורמה שלכם חושפת בפועל

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

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

<key>IncludeAllNetworks</key><true/>
<key>ExcludeCellularServices</key><true/>
<key>ExcludeLocalNetworks</key><true/>

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

קבעו מהו שם מארח לא מוכר

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

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

פתרו את הדרישה במקום להחליש את המערכת

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

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

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