למה האפליקציה שלכם ל‑iPhone לא יכולה להפעיל או לכבות את ה‑VPN של המערכת

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

התחילו משלושת הדברים שהמשתמש מתכוון אליהם

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

המשמעות השנייה היא זו שמייצרת את השאלות ב‑Stack Overflow, ואין לה תשובה נתמכת. המתג בהגדרות שייך למשתמש, ובמכשירים מנוהלים לפרופיל. שום API ציבורי לא מונה תצורות VPN, לא מדווח אם מנהרת המערכת פעילה ולא מחליף אותה.

מה אפליקציה באמת יכולה ליצור

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

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

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

קריאת המצב נתקלת באותו קיר

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

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

On Demand ו‑Always On הם המנופים האמיתיים

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

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

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

שלחו את המסלול הנתמך

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

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

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