اینڈرائیڈ VPN پر Keystore خرابی: دوبارہ اندراج، ان لاک یا دوبارہ کوشش؟

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

ایک ڈائیلاگ کے پیچھے تین ناکامیاں

پہلی تصدیق ہے۔ کلید موجود ہے اور درست ہے، لیکن اس کا استعمال صارف سے موجودگی ثابت کرنے کا تقاضا کرتا ہے — ڈیوائس ان لاک، بایومیٹرک، یا ورک پروفائل چیلنج۔ اگر لاک ٹائم آؤٹ، رجسٹرڈ بایومیٹرکس یا پروفائل کی حالت حال ہی میں بدلی ہو، تو کلید کا استعمال ناکام ہو سکتا ہے جبکہ کلید خود بالکل ٹھیک ہو۔

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

تیسری فراہم کنندہ کی ناکامی ہے: keystore سروس ابھی کارروائی مکمل نہیں کر سکی۔ یہی وہ قسم ہے جسے کبھی کبھی دوبارہ آزمانا قابلِ قدر ہے، اور صرف یہی۔

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

دوبارہ اندراج بمقابلہ ڈیٹا صاف کرنا

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

یہ فرق اہم ہے کیونکہ ناقابلِ برآمد کلیدیں بناوٹ کے مطابق منتقل نہیں ہو سکتیں۔ وہ ڈیوائس کے keystore میں رہتی ہیں جسے دستیاب ہارڈویئر یا فراہم کنندہ سہارا دیتا ہے، اور یہ ایسی چیز نہیں جسے بیک اپ پکڑ لے اور ری اسٹور واپس لے آئے۔ اگر تعیناتی کی شناخت ناقابلِ برآمد کلید ہے، تو بحالی کے طور پر دوبارہ اندراج کی منصوبہ بندی کریں اور پہلے سے تصدیق کریں کہ آپ کے پاس وہ اندراج حاصل کرنے کا منظور شدہ راستہ ہے — کچھ ادارے اس کے لیے نجی نیٹ ورک تک رسائی مانگتے ہیں، جو بالکل وہی چیز تھی جو خراب VPN فراہم کر رہا تھا۔

تو ترتیب یہ ہے: معاون تصدیق کا راستہ آزمائیں، پھر طے کریں کہ کلید مستقل طور پر باطل ہے یا نہیں، اور شناخت صرف اسی صورت میں بدلیں۔ اسٹوریج صاف کرنا سب سے آخر میں آتا ہے، یہ جاننے کے بعد کہ کیا دوبارہ بنایا جائے گا، نہ کہ آسانی کی وجہ سے سب سے پہلے۔

صرف وہی دوبارہ آزمائیں جو دوبارہ آزمایا جا سکتا ہے

پلیٹ فارم کے پرانے ورژن keystore کی خرابیوں کو ایک ہی استثنا میں سمیٹ دیتے تھے، اسی لیے بہت سے کلائنٹ ہر چیز دوبارہ آزماتے ہیں۔ API 33 سے استثنا کی قسم ڈھانچہ رکھتی ہے: عددی خرابی، عارضی ناکامی کا جھنڈا، اور دوبارہ کوشش کی پالیسی۔ کلائنٹ ڈویلپر کے لیے دوبارہ کوشش کی پالیسی صرف اسی وقت معنی رکھتی ہے جب عارضی ہونے کا جھنڈا درست ہو؛ مستقل بطلان کا کوئی دوبارہ کوشش کا شیڈول نہیں، اور اسے لوپ میں کوٹنا صرف بیٹری ختم کرتا ہے اور لاگ بھرتا ہے۔

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

وجہ کا سلسلہ پڑھیں، لیبل نہیں

ایپلیکیشنز اصل استثنا کو لپیٹتی ہیں، اور UI میں دوستانہ متن اکثر وہ واحد فیلڈ چھپا دیتا ہے جو شاخ کا فیصلہ کرتا ہے۔ وجہ کا سلسلہ اور کوشش کا ٹائم اسٹیمپ محفوظ رکھیں: بیرونی استثنا عام طور پر کارروائی کا نام لیتا ہے، اور وجہ کلید کی حالت کا نام لیتی ہے۔

اس استدلال کے پیچھے نہ لگیں کہ دو ناکام ایپلیکیشنز خراب ہینڈ سیٹ ثابت کرتی ہیں۔ مختلف کلیدیں مختلف فراہم کنندگان اور حفاظتی سطحوں کی پشت پناہی رکھ سکتی ہیں، اور جو ایپ اب بھی کام کر رہی ہے وہ شاید وہی کارروائی سرے سے نہ کر رہی ہو — دستخط، ڈکرپشن اور کلید کی تصدیق ایک ہی سروس کے مختلف مطالبات ہیں۔ KeyStoreException حوالہ نئے API درجوں کے ڈھانچہ جاتی فیلڈز بیان کرتا ہے اور یہی وہ جگہ ہے جہاں آپ دیکھتے ہیں کہ آپ کا بلڈ واقعی کیا رپورٹ کر سکتا ہے۔

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

فیصلہ کرتے وقت کیا ریکارڈ کریں

اینڈرائیڈ بلڈ، کلائنٹ ورژن، منتخب پروفائل، ناکام کارروائی، اور یہ کہ حال ہی میں کچھ بدلا یا نہیں — OS اپ ڈیٹ، لاک اسکرین کی تبدیلی، نیا فنگر پرنٹ، دوبارہ اندراج — ریکارڈ کریں۔ ترتیب کو سیاق و سباق کے طور پر لکھیں نہ کہ وجہ کے ثبوت کے طور پر؛ کلید کی ناکامی سے پہلے لاک کی تبدیلی ایک معقول تعلق ہے، مظاہرہ نہیں۔

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

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

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