Android 12 ו-IKEv1 VPN: גרסת ההפצה, IKEv2 ואפליקציות צד שלישי

שני טלפונים מציגים Android 12 בהגדרות, ורק אחד מהם עדיין מפעיל את פרופיל ה-IPsec XAuth הישן שהשער שלכם מציע. ההבדל אינו הגדרה שהמשתמש יכול להגיע אליה: השומר שמנהל את הנתיב המקורי של IKEv1 בודק את רמת ה-SDK שאיתה סופק המכשיר, ולא רק את הגרסה שהוא מריץ כעת. הפרט האחד הזה קובע אם השוואת צי בכלל הגיונית, והוא גם קובע איזה משלושת נתיבי ההעברה באמת דרוש לכם.

שני טלפונים עם Android 12 אינם אותו מקרה מבחן

השינוי ב-AOSP שמנע ממכשירים חדשים להפעיל פרופילי IKEv1 ישנים משווה את DEVICE_INITIAL_SDK_INT ל-Android S, כלומר API 31. בנתיב האתחול המקורי, פרופיל מתאים מעלה כשל של פעולה לא נתמכת לפני שקיים בכלל חיבור שימושי. טלפון שסופק עם Android 11 ועודכן מאוחר יותר עדיין עובר את השומר הזה; דגם שהושק עם Android 12 לא.

אפשר לקרוא את שני המספרים במכשיר עם ניפוי באגים מופעל:

adb shell getprop ro.product.first_api_level
adb shell getprop ro.build.version.sdk
adb shell getprop ro.build.version.release

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

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

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

המחסנית הישנה היא זו שקוראת פרופילי IPsec XAuth PSK, IPsec Hybrid RSA ו-L2TP/IPsec PSK ממסך ה-VPN של המערכת. במכשיר שסופק מתחת ל-API 31 היא נשארת נתיב בר-קיימא לאחר שדרוג, ולכן פיילוט במכשיר ותיק יכול להצליח בשעה שמכשיר חדש אינו מפעיל את אותו פרופיל.

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

נתיב שני: פרופילי IKEv2 של הפלטפורמה

מודל האספקה הציבורי של Android ל-IKEv2 הוא אובייקט אחר, לא פרופיל IKEv1 ששונה שמו. ה-API של הפלטפורמה לפרופילי IKEv2 הגיע עם API 30 ומצפה ל-IKEv2 עם שיטת האימות שהשער מציע, בדרך כלל מבוססת תעודה או EAP. אין שדרוג תואם-חוטים מ-IKEv1 XAuth או Hybrid ל-IKEv2: יש להגדיר את השער לפרוטוקול החדש, והפרופיל חייב לשאת את הזהות המתאימה.

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

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

נתיב שלישי: אפליקציית לקוח מצד שלישי

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

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

בחרו לפי מה שהשער יכול להציע

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

שני דברים הופכים את התוכנית לניתנת להגנה. ראשית, תעדו את הסיבה לכל חריגה יחד עם הדגם ורמת ההפצה, כדי שמבקר יראה שהגבול הוא שומר פלטפורמה ולא העדפה לא מוסברת. שנית, התייחסו להעברה כאל עבודה מתוכננת: IKEv1 הוצא משימוש במסלול התקנים (RFC 9395), כלומר המכשירים שנותרו ימשיכו להתמעט והחריגות אמורות לפוג יחד איתם.