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

האפליקציה והלקוח המקורי נמצאים בשכבות שונות

לקוח ה-VPN המובנה של Apple הוא בפועל לקוח IKEv2. הטופס הידני עדיין מפרט את L2TP מעל IPsec המיושן ואת אפשרויות Cisco IPsec, אבל אין שדה לתעבורת ספק ואין מקום להדביק תצורת OpenVPN או WireGuard. או שאתם ממלאים טופס בהגדרות > כללי > VPN & ניהול מכשיר, או שאתם מייבאים פרופיל עם מטען VPN; המשטח הוא כתובת שרת, שני זהויות, שיטת אימות וכללי דרישה אופציונליים.

אפליקציית ספק פועלת שכבה אחת למעלה. היא מספקת ספק מנהרת מנות Network Extension, כך שקוד הפרוטוקול ולוגיקת הניתוב חיים באפליקציה ו-iOS רק מעביר מנות. יש אפליקציות שמיישמות WireGuard או OpenVPN, אחרות תעבורה מוסווית משלהן, ומעטות רק מתקינות פרופיל IKEv2 ומפעילות את הלקוח המובנה מאחורי מסך נעים יותר. בגלל הקבוצה האחרונה, הבחירה בין אפליקציה לפרופיל היא לפעמים בחירה שווא.

התוצאה מעשית: קובץ .ovpn או WireGuard אינו מחליף את השדות האלה, כי לחיצת היד היא פרוטוקול אחר.

קראו את המטען לפני שאתם משווים תכונות

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

<key>VPNType</key><string>IKEv2</string>
<key>RemoteAddress</key><string>vpn.example.net</string>
<key>RemoteIdentifier</key><string>vpn.example.net</string>
<key>LocalIdentifier</key><string>[email protected]</string>
<key>AuthenticationMethod</key><string>Certificate</string>
<key>ServerCertificateIssuerCommonName</key><string>Example Issuing CA</string>

שלושה שדות נושאים את רוב המשקל האבחוני. RemoteIdentifier הוא השם שהלקוח מצפה שהשרת יציג, כך ששער מאחורי NAT או מאזן עומסים שהתעודה שלו מציינת את הבריכה במקום את הכתובת נכשל למרות שהכתובת נכונה. LocalIdentifier הוא הזהות שהשרת מייחס לכם, ובאימות בתעודה היא חייבת להתאים לזהות שממופה לחשבון שלכם. ServerCertificateIssuerCommonName מצמיד את ה-CA המנפיק, כך שפרופיל יכול להיכשל ביום שבו התעודה מונפקת מחדש, בלי שאף הודעת שגיאה תזכיר תעודות.

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

מה האפליקציה יכולה והלקוח המובנה לא

בחירת הפרוטוקול היא היתרון הברור. אם השרת שלכם מדבר WireGuard או OpenVPN, אפליקציה היא לקוח ה-iOS היחיד שיכול להשתמש בזה, ועריכת הטופס המובנה לא תנהל על זה משא ומתן. אפליקציה יכולה גם ליישם מנהרה מפוצלת לפי יעד או אפליקציה, טיפול DNS משלה, חסימה בסגנון kill switch, בחירת שרת והתחברות מחדש המותאמת לרשת שלה.

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

מה פרופיל IKEv2 המובנה עושה נכון

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

מה שהמסלול המובנה לא נותן הוא גמישות. אין VPN לפי אפליקציה בלי אפליקציות מנוהלות, אין kill switch למשתמש ואין תעבורה שנראית כמו HTTPS ברשת שחוסמת IPsec. ברשתות מלונות שזורקות UDP 500 ו-4500, ל-IKEv2 המובנה אין חלופה.

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

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

What you were givenDevice situationWhat to use
An .ovpn or WireGuard configPersonal phoneProvider app; the native form cannot load it
IKEv2 host plus CA namePersonal or managedProfile, or the app's own IKEv2 mode
IKEv2 with username and secretPersonal phoneEither; the profile is simpler if you never switch servers
A management-installed profileSupervised, MDMNative client; do not add a second app entry
A per-app tunnelling requirementPersonal phoneApp, or accept a full tunnel; iOS cannot split by app without management
IPsec blocked on your main networkAnyApp with a transport that survives the block

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

אמתו את הבחירה בניסוי אחד

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

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

רשימה קצרה כדי שהמכשיר יהיה מוסבר לאדם הבא:

  • רשומת VPN אחת, לא שתיים;
  • הפרופיל או האפליקציה נקראים על שם השרת שאליו הם מתחברים;
  • ערכי הזהות כתובים במקום שבו תוכלו למצוא אותם.

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

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