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 أعيدت تسميته. وصلت واجهة برمجة المنصة لملفات IKEv2 مع API 30 وتتوقع IKEv2 بطريقة المصادقة التي تقدّمها البوابة، غالبًا بالشهادات أو EAP. لا توجد ترقية متوافقة سلكيًا من IKEv1 XAuth أو Hybrid إلى IKEv2: يجب تهيئة البوابة للبروتوكول الجديد، ويجب أن يحمل الملف الهوية المطابقة.

هذا هو المسار الأطول عمرًا، وهو أيضًا الذي يكشف العمل الحقيقي. التحقق من الهوية ومصادقة المستخدم وDNS ومسارات النفق المنقسم وتفويض الموارد كلها يجب أن تنجو من الترحيل؛ إنجاح المصافحة وحدها يترك المستخدمين متصلين بنفق لا يصل إلى شيء.

يجري النشر عادة عبر MDM أو تهيئة مُدارة بدلًا من أن يكتب المستخدم الحقول. إذا لم تكن هذه البنية موجودة بعد، فيجب أن يتضمنها مخطط الترحيل، لأن إعادة إدخال ملف IKEv2 يدويًا على كل جهاز ليست عملية يستوعبها مكتب الدعم.

المسار الثالث: تطبيق عميل من طرف ثالث

بعض تطبيقات VPN تشحن تنفيذها الخاص للبروتوكول ولا تعتمد على المخزون الأصلي القديم إطلاقًا. هذا يجعلها حلًا مؤقتًا مشروعًا لأسطول لا يستطيع الترحيل بسرعة، لكن سؤال التوافق ينتقل إلى التطبيق: هل ينفّذ وضع IKEv1 الدقيق الذي تتحدث به بوابتك، مع المصادقة وأجنحة التشفير التي تتطلبها البوابة.

اعتبر مصفوفة الدعم الخاصة بالتطبيق هي المرجع لا وصف المتجر، واختبر جهازًا حقيقيًا مقابل البوابة الحقيقية قبل التوصية به. عمل روت لهاتف لاستعادة مسار منصة أُزيل ليس حلًا مُصانًا أيضًا؛ إنه ينقل المشكلة إلى تهيئة غير مدعومة قد يكسرها تحديث النظام التالي بصمت.

اختر بحسب ما يمكن للبوابة تقديمه

يضيق القرار بمجرد معرفة أمرين: أي الأجهزة أُطلقت على API 31 أو بعده، وهل يمكن للبوابة تقديم خدمة IKEv2 بنموذج التسجيل نفسه. إن أمكن، رحّل وتوقف عن الاستثمار في الملف القديم. وإن لم يمكن بعد، فأبقِ IKEv1 للأجهزة التي ما زالت تشغّله، وأعطِ الأجهزة الجديدة عميل طرف ثالث كاستثناء موثّق ومحدد المدة بدلًا من حل غير معلن.

نقطتان تجعلان الخطة قابلة للدفاع. أولًا، سجّل سبب كل استثناء مع الطراز ومستوى الإطلاق، ليرى المدقق أن الحد حاجز منصة لا تفضيلًا غير مفسّر. ثانيًا، تعامل مع الترحيل كعمل مخطط: IKEv1 مهجور في مسار المعايير (RFC 9395)، ما يعني أن الأجهزة المتبقية ستستمر في التقلص وأن الاستثناءات ينبغي أن تنتهي معها.