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)، یعنی دستگاه‌های باقی‌مانده همچنان کم می‌شوند و استثناها باید با آن‌ها منقضی شوند.