VPN לפי דרישה של iPhone מתחבר ל-Wi-Fi של המשרד, לא לרשת הסלולרית
כלל ההחרגה שלכם קיים ובכל זאת מפסיד. רשימות לפי דרישה נקראות מלמעלה למטה, ולכן כלל מוקדם אחד שתופס הכול מכריע את הבוקר לפני שכלל המשרד נראה.
בתשע הטלפון מצטרף לרשת האלחוטית של המשרד, והמנהרה עולה מעצמה ונשארת שם כל היום. הרשת הסלולרית מתנהגת אחר כך בדיוק כפי שכולם התכוונו. מישהו הוסיף החרגה לרשת הארגונית לפני שבועות, כך שהפרופיל נראה נקי בסקירה, וכל בוקר עדיין מפיק את אותה תוצאה. המכשיר פועל לפי הרשימה שקיבל, והרשימה אומרת משהו אחר ממה שכותבה האמין.
הרשימה נקראת מלמעלה, וההתאמה הראשונה מנצחת
הרשומות מוערכות לפי הסדר. הראשונה שתנאיה מתקיימים מכריעה את התוצאה לאותו רגע, וכל מה שמתחתיה לא נבחן לעולם. הסדר אפוא נושא משמעות רבה כמו כל תנאי שכתוב בתוך כלל. קריאת המערך מלמעלה מסבירה פרופיל שנראה כאילו הוא מתעלם מהחרגה שהוא בבירור מכיל.
רשומת חיבור אלחוטי כללית שממוקמת מעל החרגת המשרד מבטיחה מנהרה במקום. שום דבר אחר במטען לא צריך לזוז כדי שההתנהגות תתהפך.
רשומת ניתוק עושה שני תפקידים
כאשר הפעולה היא ניתוק, הרשומה סוגרת הפעלה שכבר רצה וחוסמת חדשה כל עוד תנאיה נכונים. שני החצאים חשובים להחרגה, והחצי השני נוטה להישכח. אותה רשומה בפרופיל שני מסבירה קומה שבה ה-VPN מסרב להתחיל בזמן ששאר הבניין עובד. אף אחד לא נגע במנהרה; הרשימה עשתה זאת.
הטבלה מראה את הצורה, החרגה ראשונה, עם שמות שחייבים לבוא מהפריסה שלכם. בדרך כלל שתי רשומות מספיקות, ושלישית לרשת הסלולרית שומרת על יתר הדברים כצפויים.
| Order | Action | Conditions |
|---|---|---|
| 1 | Disconnect | Wireless interface plus office network name |
| 2 | Connect | Wireless interface |
| 3 | Connect | Cellular interface |
השאירו את שני התנאים על ההחרגה
הצמידו את שם הרשת לסוג הממשק. שם לבדו יכול לפעול על קישור משותף שנושא את אותה תווית, ואילו סוג ממשק לבדו מחרג כל רשת אלחוטית שהמשתמש מבקר בה באותו יום. שני החצאים שייכים לרשומה אחת, לא לשני כללים שמקרה עומדים זה לצד זה.
השוואת השמות מדויקת ורגישה לאותיות גדולות וקטנות. זה מתאים לרשת מוכרת אחת ומקשה בכל מקום אחר, כי רשתות אורחים עושות שימוש חוזר בתוויות מוכרות, אתרים משנים שם אחרי מיזוג, ושולחן קווי לא נושא שם כלל. בקשו מצוות הרשת את התווית המדויקת במקום לקרוא אותה משלט על הקיר.
כשבדיקה מנצחת שם
רשומת בדיקה מבקשת כתובת URL וקוראת תשובה מוצלחת כתנאי שמתקיים. בחרו מארח שעונה רק מבפנים, כמו שירות אינטרנט פנימי שאינו ניתן לפתרון פומבי, והכלל מפסיק להתעניין איך הרשת קוראת לעצמה. בדיקה שעונה מכל מקום בודקת את האינטרנט, לא את הבניין. התכונה שמכריעה אם זה עובד היא התשובה שמגיעה בלי הפניה; פורטל אורחים שמחזיר כל בקשה הופך את הבדיקה לרעש.
כללים מבוססי דומיין הם צורה נפרדת: NEEvaluateConnectionRule מתאים דומיינים מבוקשים ויכול להתחבר כשמחפשים שם. תו הכללי שלו מתקבל רק בתור התווית השמאלית ביותר, ולכן *.example.com תקף ואילו example.*.com אינו. אם פרופיל לא משתמש בתנאי ממשק ולא בבדיקות נגישות, בדקו אם הוא משתמש במקומם בסוג הכלל הזה.
מה שכללי דרישה לא שולטים בו
כללים בוחרים אם מנהרה מתחילה ואין להם אומר בהמשך הפעלתה. הפעלה שמופיעה ואז נעלמת כעבור דקות מצביעה על טיימרים של חוסר פעילות, מגבלות הפעלה בשער או גודל הנתיב. כל אחד מאלה משאיר עקבה אחרת, ולכן כדאי לשלול את רשימת הכללים לפני שמשנים משהו מהם. הגדרות שמירת חיבור אינן מסבירות את הדפוס הזה, ושינוי שלהן מעביר את העבודה בלי לגעת בסיבה.
משתמשים יכולים לכבות את האפשרות לפי דרישה בהגדרות, והקצאה מנוהלת יכולה להחזיר אותה בצ׳ק-אין הבא. כשהמתג ממשיך לגלוש חזרה למצבו הקודם, ההקצאה היא הצד הפעיל. ההבחנה חשובה, כי אכיפה חוזרת מעצמה בעוד שהצעה נשארת כבויה.
ודאו איזו קבוצת פרופילים מחזיקה במכשיר והאם הכוונה היא לכפות את המנהרה או רק להציע אותה. התשובה הזו קובעת אם העדפת המשתמש נחשבת לתקלה או לתכונה.