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 بیا داخلول یا د لارو سمول هغه پروتوکول-ملاتړ څېړنه نه شي لرې کولی چې مخکې چلېږي، او ناکامي د اعتبارنامې ستونزه ښکاري حال دا چې نه ده.

لومړۍ لاره: اصلي لېګسي سټک هغه ځای کې وساتئ چې لا چلېږي

لېګسي سټک هغه دی چې له سیسټم VPN سکرین څخه IPsec XAuth PSK، IPsec Hybrid RSA او L2TP/IPsec PSK پروفایلونه لولي. په هغه وسیله چې له API 31 څخه ښکته جوړه شوې، له لوړولو وروسته هم دا یوه عملي لاره پاتې کېږي، نو ځکه په زړه لاسي اپاراټ کې ازموینه بریالۍ کېدای شي خو نوی اپاراټ هماغه پروفایل ردوي.

مهمه پرتله د Android نسخې له مخې نه، بلکې د وسیلې طبقې له مخې ده: په فلېټ کې ماډلونه ولیکئ، د هغوی د پیل API کچې ولولئ، او هغوی په داسې وسیلو ووېشئ چې پروفایل لا پیلوي او هغو چې نه شي کولی. نور هر څه داسې ملاتړ پالیسي جوړوي چې د کاروونکي د نوي ټیلیفون پیرودلو په شېبه کې له خپل ځان سره متناقضه شي.

دوهمه لاره: د پلیټ فارم IKEv2 پروفایلونه

د IKEv2 لپاره د Android عامه برابرولو ماډل بل شی دی، نه د نوم بدل شوی IKEv1 پروفایل. د IKEv2 پروفایلونو لپاره پلیټ فارم API له API 30 سره راغی او د هغه تصدیق کړنلارې سره IKEv2 تمه لري چې ګیټوې وړاندې کوي، معمولاً د سند پر بنسټ یا EAP. له IKEv1 XAuth یا Hybrid څخه IKEv2 ته د تار-مطابقت لوړوالی نشته: ګیټوې باید د نوي پروتوکول لپاره تنظیم شي، او پروفایل باید سمه هویت ولري.

دا تر ټولو اوږد عمر لاره ده، او همدا هغه ده چې رښتینی کار ښکاره کوي. د هویت تصدیق، د کاروونکي تصدیق، DNS، د split-tunnel لارې او د سرچینو اجازه باید ټول مهاجرت تېر کړي؛ که یوازې لاس ورکول بریالي شي، کاروونکي په داسې تونل کې پاتې کېږي چې هیچې ته نه رسېږي.

ځای پرځای کول معمولاً د MDM یا مدیریت شوې ترتیب له لارې وي، نه د کاروونکي لخوا د ساحو ټایپ کولو سره. که هغه زیربنا لا نه وي، مهاجرت پلان باید هغه شامل کړي، ځکه په هر وسیله IKEv2 پروفایل په لاس بیا داخلول داسې عملیه نه ده چې مرستې مېز یې وزغمي.

درېیمه لاره: د دریمې ډلې کلینټ اپلیکیشن

ځینې VPN اپلیکیشنونه خپله پروتوکول پلي کول وړاندې کوي او په اصلي لېګسي سټک هېڅ تکیه نه کوي. دا هغوی د هغه فلېټ لپاره چې ژر مهاجرت نه شي کولی قانوني لنډمهاله حل ګرځوي، خو د مطابقت پوښتنه اپلیکیشن ته ځي: ایا هماغه IKEv1 حالت پلي کوي چې ستاسو ګیټوې وایي، د هغه تصدیق او سایفر سوټونو سره چې ګیټوې غواړي.

د پلورنځي تفصیل پر ځای د اپلیکیشن خپل ملاتړ میټریکس واکمن وګڼئ، او د سپارښتنې مخکې یوه ریښتینې وسیله له ریښتیني ګیټوې سره وازموئ. د لرې شوې پلیټ فارم لارې د بیا رغولو لپاره د ټیلیفون ریښه کول هم ساتل شوی حل نه دی؛ دا ستونزه داسې نه ملاتړ شوې ترتیب ته وړي چې بل سیسټم تازه کول یې په خاموشۍ ماتولی شي.

د هغه څه له مخې وټاکئ چې ګیټوې یې وړاندې کولی شي

پرېکړه هغه وخت تنګېږي چې دوه شیان پوه شئ: کومې وسیلې د API 31 یا وروسته پیل شوې، او ایا ګیټوې کولی شي د هماغه نوم لیکنې ماډل سره IKEv2 خدمت وړاندې کړي. که یې شي، مهاجرت وکړئ او په لېګسي پروفایل کې پانګونه بنده کړئ. که لا نه شي، IKEv1 د هغو وسیلو لپاره وساتئ چې لا یې پیلوي، او نویو وسیلو ته د دریمې ډلې کلینټ د مستند شوي، مهال-بندي شوي استثنا په توګه ورکړئ، نه د ناڅرګندې لارې په توګه.

دوه ټکي پلان د دفاع وړ ګرځوي. لومړی، د هر استثنا لامل له ماډل او پیل کچې سره ولیکئ، تر څو پلټونکی وویني چې پوله بې توضیحه غوره توب نه، بلکې د پلیټ فارم ساتونکی دی. دویم، مهاجرت د پلان شوې کار په توګه وګڼئ: IKEv1 د معیارونو په لاره کې له کاره وتلی (RFC 9395)، چې مانا یې دا ده چې پاتې وسیلې به لا کمېږي او استثناوې باید له هغوی سره پای ته ورسیږي.