Always On VPN מול VPN On Demand ב-iPhone: מה לפרוס

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

שלב 1: לקבוע מה המכשיר יכול לכפות

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

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

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

שלב 2: לקרוא את כללי on-demand ולא את שם התכונה

On Demand הוא רשימת כללים שנבחנים לפי סדר. כל כלל מציין פעולה ואת התנאים שבוחרים בו, והתנאים הם החלק המעניין: סוג ממשק, SSID של Wi-Fi, סיומת דומיין DNS או כתובת URL לבדיקה. מערכת כללים שלעולם אינה מתאימה היא תכונה שלעולם אינה מתחברת.

<key>OnDemandRules</key>
<array>
  <dict>
    <key>Action</key><string>EvaluateConnection</string>
    <key>InterfaceTypeMatch</key><string>WiFi</string>
    <key>SSIDMatch</key><array><string>Office-WiFi</string></array>
  </dict>
</array>

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

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

שלב 3: לבדוק מעברים ולא חיבור סטטי

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

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

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

שלב 4: להכיר את שתי צורות הכשל

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

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

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

שלב 5: לאמת ואז לתרגל את הנסיגה

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

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

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