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، منقسم ٹنل کے راستے اور وسائل کی اجازت سب کو ہجرت جھیلنی پڑتی ہے؛ اگر صرف ہینڈ شیک کامیاب ہو تو صارف ایسی ٹنل سے جڑے رہتے ہیں جو کہیں نہیں پہنچتی۔

تعیناتی عام طور پر MDM یا منظم کنفیگریشن کے ذریعے ہوتی ہے، صارف کے فیلڈ ٹائپ کرنے سے نہیں۔ اگر وہ انفراسٹرکچر ابھی نہیں ہے تو ہجرت کے منصوبے میں اسے شامل کرنا ہوگا، کیونکہ ہر ڈیوائس پر IKEv2 پروفائل دستی طور پر دوبارہ درج کرنا ایسا عمل نہیں جو ہیلپ ڈیسک سنبھال سکے۔

راستہ تین: تیسرے فریق کا کلائنٹ ایپ

کچھ VPN ایپس اپنی پروٹوکول عمل درآمد لاتی ہیں اور نیٹو لیگیسی اسٹیک پر بالکل انحصار نہیں کرتیں۔ اس سے وہ ایسی فلیٹ کے لیے جائز عارضی حل بن جاتی ہیں جو تیزی سے ہجرت نہیں کر سکتی، لیکن مطابقت کا سوال ایپ کی طرف منتقل ہو جاتا ہے: کیا وہ بالکل وہی IKEv1 موڈ نافذ کرتی ہے جو آپ کا گیٹ وے بولتا ہے، گیٹ وے کی مطلوبہ تصدیق اور سائفر سوٹس کے ساتھ۔

اسٹور کی تفصیل کی بجائے ایپ کے اپنے سپورٹ میٹرکس کو اختیار سمجھیں، اور تجویز کرنے سے پہلے ایک حقیقی ڈیوائس کو حقیقی گیٹ وے کے ساتھ جانچیں۔ ہٹائے گئے پلیٹ فارم راستے کو بحال کرنے کے لیے فون کو روٹ کرنا بھی پائیدار حل نہیں؛ یہ مسئلہ ایسی غیر تعاون یافتہ کنفیگریشن میں منتقل کرتا ہے جسے اگلی سسٹم اپ ڈیٹ خاموشی سے توڑ سکتی ہے۔

گیٹ وے کیا پیش کر سکتا ہے اس کی بنیاد پر چنیں

فیصلہ اس وقت تنگ ہوتا ہے جب آپ دو باتیں جانتے ہوں: کون سی ڈیوائسز API 31 یا بعد میں شروع ہوئیں، اور کیا گیٹ وے اسی اندراج ماڈل کے ساتھ IKEv2 سروس پیش کر سکتا ہے۔ اگر ہاں، تو ہجرت کریں اور لیگیسی پروفائل میں سرمایہ کاری بند کریں۔ اگر ابھی نہیں، تو ان ڈیوائسز کے لیے IKEv1 رکھیں جو اسے اب بھی شروع کرتی ہیں، اور نئی ڈیوائسز کو تیسرے فریق کا کلائنٹ دستاویزی، مدت والی استثنا کے طور پر دیں، نہ کہ غیر بیان شدہ حل کے طور پر۔

دو باتیں منصوبے کو قابل دفاع بناتی ہیں۔ پہلی، ہر استثنا کی وجہ ماڈل اور لانچ سطح کے ساتھ درج کریں، تاکہ آڈیٹر دیکھ سکے کہ حد غیر واضح ترجیح نہیں بلکہ پلیٹ فارم گارڈ ہے۔ دوسری، ہجرت کو منصوبہ بند کام سمجھیں: IKEv1 معیاری راستے کے مطابق متروک ہے (RFC 9395)، جس کا مطلب ہے کہ باقی ڈیوائسز کم ہوتی رہیں گی اور استثنائیں ان کے ساتھ ختم ہونی چاہئیں۔