שני VPN באייפון בו-זמנית: איזה מהם נושא את התעבורה שלכם?

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

מיתוס: שני VPN מחוברים הם שרשרת

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

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

המודל המתועד שמאחורי המיתוס הזה

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

Personal VPN כאן הוא המונח של ה-API למימוש המובנה של IPsec או IKEv2 המנוהל דרך NEVPNManager. NETunnelProviderManager הוא מודל ספק המנהרה. יישום צרכני יכול להשתמש במודל הספק, ולכן שם מוצר שמכיל personal אינו מסווג אותו.

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

מיתוס: ה-VPN האישי מקבל את תעבורת הגלישה

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

לתצורות מנוהלות לפי יישום יש היקף משלהן. אל תשליכו כלל ברמת המכשיר על כל פריסה מנוהלת.

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

קדימות מסלולים עם פרופיל עבודה של מנהרה מפוצלת

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

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

רשמו שתי זרימות ובדקו כל אחת

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

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