Android VPN-এ Keystore ত্রুটি: আবার নথিভুক্ত করবেন, আনলক করবেন নাকি আবার চেষ্টা করবেন?
Android keystore-এর তিনটি ফলাফলের জন্য তিনটি ভিন্ন পুনরুদ্ধার দরকার। অ্যাপের স্টোরেজ মুছোনোর আগে আনলক, নতুন নথিভুক্তি ও প্রোভাইডারের পুনঃচেষ্টা তুলনা করুন।
প্রোফাইলটি এখনও তালিকায় আছে, সার্টিফিকেটটি এখনও ইনস্টল করা দেখায়, আর কানেক্ট বোতামটি ব্যর্থ হয়ে শুধু «Keystore ত্রুটি» বলে একটি বার্তা দেয়, আর কিছু নয়। অ্যাপের স্টোরেজ মোছার বা ফোনটি জমা দেওয়ার আগে নির্ধারণ করুন কোন কী অপারেশনটি ব্যর্থ হয়েছে। তিনটি ফলাফল একই ডায়ালগ তৈরি করে, এবং তারা তিনটি ভিন্ন পদক্ষেপে সাড়া দেয় — যার মধ্যে কেবল একটি ধ্বংসাত্মক। তুলনাটি দশ মিনিটের যোগ্য, কারণ ভুল শাখাটি আপনাকে সেই পরিচয়টিই খোয়ায় যা আপনি রাখতে চেয়েছিলেন।
একটি ডায়ালগের পিছনে তিনটি ব্যর্থতা
প্রথমটি প্রমাণীকরণ। কী-টি আছে এবং বৈধ, কিন্তু এটি ব্যবহার করতে হলে ব্যবহারকারীকে উপস্থিতি প্রমাণ করতে হয় — ডিভাইস আনলক, বায়োমেট্রিক বা ওয়ার্ক-প্রোফাইল চ্যালেঞ্জ। লক টাইমআউট, নথিভুক্ত বায়োমেট্রিক বা প্রোফাইলের অবস্থা সম্প্রতি বদলে গেলে কী ব্যবহার ব্যর্থ হতে পারে, অথচ কী-টি নিজে পুরোপুরি ঠিক থাকে।
দ্বিতীয়টি স্থায়ীভাবে অকার্যকর হওয়া। কিছু কী উপাদান প্ল্যাটফর্ম নীতির কারণে অকার্যকর হয় যখন লক পদ্ধতি রিসেট হয় বা বায়োমেট্রিক নথিভুক্তি বদলায়, কারণ যে বন্ধন এটি রক্ষা করত তা আর টেকে না। কী-টি মেরামত করা যায় না এবং আবার চেষ্টা করা কোনো পুনরুদ্ধার পরিকল্পনা নয়; পরিচয়টি যে নথিভুক্তি প্রক্রিয়া এটি দিয়েছিল তার মাধ্যমে প্রতিস্থাপন করতে হবে।
তৃতীয়টি প্রোভাইডারের ব্যর্থতা: keystore পরিষেবা এখনই অপারেশনটি সম্পন্ন করতে পারেনি। এটিই সেই শ্রেণি যা মাঝেমধ্যে আবার চেষ্টা করার যোগ্য, এবং একমাত্র।
| Failure | What it means | What recovers it | What does not |
|---|---|---|---|
| User not authenticated | Key needs a presence check | Supported unlock or authorization flow | A VPN account password reset |
| Key permanently invalidated | Binding is gone; key unusable | Replacement enrollment for that identity | Retrying, rebooting, reinstalling the client |
| Transient provider error | Service could not complete now | The provider's documented retry path | Clearing app data |
লক্ষ্য করুন, তিনটির মধ্যে দুটি ধ্বংসাত্মক নয় এবং একটির ডিভাইস পর্যায়ে কোনো সমাধানই নেই। এগুলোর কোনোটিই ফোন মুছে ফেলার মাধ্যমে সমাধান হয় না, অথচ মানুষ প্রথমেই এই পদক্ষেপটি নেয় কারণ ডায়ালগ তাদের আর কিছুই দেয় না।
নতুন নথিভুক্তি বনাম ডেটা মুছে ফেলা
এই দুটি বাইরে থেকে একই রকম দেখায়, কিন্তু নয়। নতুন নথিভুক্তি ইস্যুকারী সিস্টেমের কাছে নতুন পরিচয় চায় — এই ডিভাইসে বাঁধা নতুন সার্টিফিকেট বা কী — এবং পুরোটিকে অবসরে পাঠায়। ডেটা মুছে ফেলা অ্যাপের সংরক্ষিত অবস্থা মুছিয়ে দেয়, যা কী মুছে না ফেলেই কী-এর রেফারেন্স সরিয়ে দিতে পারে, বা কী-টিই মুছে দিয়ে আপনাকে তা পুনরায় তৈরি করার কোনো কর্তৃত্ব ছাড়াই রেখে যেতে পারে।
পার্থক্যটি গুরুত্বপূর্ণ কারণ রপ্তানি-অযোগ্য কী ডিজাইন অনুসারেই বহনযোগ্য নয়। তারা ডিভাইসের keystore-এ থাকে, যে হার্ডওয়্যার বা প্রোভাইডার পাওয়া যায় তার সমর্থনে, এবং ব্যাকআপ সেগুলো ধরে রাখে না আর পুনরুদ্ধার সেগুলো ফিরিয়ে আনে না। যদি ডিপ্লয়মেন্টের পরিচয় রপ্তানি-অযোগ্য কী হয়, তবে পুনরুদ্ধার হিসেবে নতুন নথিভুক্তির পরিকল্পনা করুন এবং আগেই নিশ্চিত করুন যে সেই নথিভুক্তি পাওয়ার অনুমোদিত পথ আপনার আছে — কিছু সংস্থা এর জন্য ব্যক্তিগত নেটওয়ার্ক অ্যাক্সেস দাবি করে, আর ভাঙা VPN ঠিক সেটাই দিচ্ছিল।
তাই ক্রমটি হল: সমর্থিত প্রমাণীকরণ পথটি চেষ্টা করুন, তারপর নির্ধারণ করুন কী-টি স্থায়ীভাবে অকার্যকর কি না, এবং তবেই পরিচয় প্রতিস্থাপন করুন যদি তা হয়। স্টোরেজ মোছা সবার শেষে, কী পুনরায় তৈরি হবে তা জানার পরে, সহজ বলে প্রথমে নয়।
কেবল যা পুনরায় চেষ্টা করার যোগ্য তা-ই আবার চেষ্টা করুন
পুরোনো প্ল্যাটফর্ম সংস্করণগুলো keystore ত্রুটিগুলোকে একটি একক এক্সসেপশনে গুটিয়ে ফেলত, তাই এত ক্লায়েন্ট সবকিছু আবার চেষ্টা করে। API 33 থেকে এক্সসেপশন টাইপ কাঠামো বহন করে: একটি সংখ্যাসূচক ত্রুটি, একটি ক্ষণস্থায়ী-ব্যর্থতার ফ্ল্যাগ এবং একটি পুনঃচেষ্টা নীতি। ক্লায়েন্ট ডেভেলপারের কাছে পুনঃচেষ্টা নীতি কেবল তখনই অর্থবহ যখন ক্ষণস্থায়ী ফ্ল্যাগ সত্য; স্থায়ী অকার্যকরণের কোনো পুনঃচেষ্টা সময়সূচি নেই, আর লুপে তা চালিয়ে যাওয়া কেবল ব্যাটারি খায় ও লগ ভরে।
আপনি যদি ক্লায়েন্ট লেখার বদলে রোগনির্ণয় করছেন, ব্যবহারিক ফল একই। প্রতিটি চেষ্টায় একই ব্যর্থতা এককালীন গোলযোগ বাদ দেয়, কিন্তু স্থায়ীভাবে অকার্যকর কী-কে কিছুদিন ধরে অনুপলব্ধ প্রোভাইডার থেকে আলাদা করে না — প্রোভাইডারের বিভ্রাট দশম চেষ্টাতেও প্রথমটির মতোই দেখায়। API 33-এর কাঠামোবদ্ধ ক্ষেত্র ছাড়া পুনরাবৃত্তিকে দ্বিতীয় সংকেত খোঁজার কারণ হিসেবে ধরুন — ত্রুটি কোড যদি আপনার বিল্ড তা প্রকাশ করে, অপারেটরের স্ট্যাটাস, বা একই ডিভাইসে আরেকটি কী সফল হওয়া — কী-টি মৃত বলে প্রমাণ হিসেবে নয়।
কারণ-শৃঙ্খলা পড়ুন, লেবেল নয়
অ্যাপ্লিকেশনগুলো মূল এক্সসেপশনটি মোড়ায়, আর ইন্টারফেসের বন্ধুত্বপূর্ণ লেখাটি প্রায়ই সেই একমাত্র ক্ষেত্রটিই লুকিয়ে রাখে যা শাখাটি নির্ধারণ করে। কারণ-শৃঙ্খলা ও চেষ্টার সময়চিহ্ন সংরক্ষণ করুন: বাইরের এক্সসেপশন সাধারণত অপারেশনটির নাম বলে, আর কারণটি বলে কী-এর অবস্থা।
দুটি ব্যর্থ অ্যাপ ত্রুটিপূর্ণ হ্যান্ডসেট প্রমাণ করে — এই সিদ্ধান্তের বিরুদ্ধে দাঁড়ান। ভিন্ন কী ভিন্ন প্রোভাইডার ও নিরাপত্তা স্তরে সমর্থিত হতে পারে, আর যে অ্যাপ এখনও কাজ করে সেটি একই অপারেশন আদৌ চালাতেও পারে না — স্বাক্ষর, ডিক্রিপশন ও কী অ্যাটেস্টেশন একই পরিষেবার কাছে ভিন্ন ভিন্ন অনুরোধ। KeyStoreException রেফারেন্স নতুন API স্তরে কাঠামোবদ্ধ ক্ষেত্রগুলোর বর্ণনা দেয় এবং আপনার বিল্ড আসলে কী রিপোর্ট করতে পারে তা যাচাই করার জায়গা।
হার্ডওয়্যারের সিদ্ধান্তকে সমর্থন করবে এমন প্রমাণ বেশিরভাগ মানুষের ধারণার চেয়ে সংকীর্ণ: একই অপারেশন, একই প্রোভাইডারে, স্বাধীন কী জুড়ে কী-স্তরের নয় বরং প্রোভাইডার-স্তরের ত্রুটিতে ব্যর্থ হওয়া। সেটি প্ল্যাটফর্মের রোগনির্ণয়ের প্রশ্ন, ডিভাইসের একটি ব্যাচ নিয়ে সাপোর্ট ফোরামের থ্রেডের নয়।
সিদ্ধান্ত নেওয়ার সময় কী লিখে রাখবেন
Android বিল্ড, ক্লায়েন্ট সংস্করণ, নির্বাচিত প্রোফাইল, যে অপারেশনটি ব্যর্থ হয়েছে এবং সম্প্রতি কিছু বদলেছে কি না তা লিখুন — একটি সিস্টেম আপডেট, লক-স্ক্রিন পরিবর্তন, নতুন ফিঙ্গারপ্রিন্ট, নতুন নথিভুক্তি। ক্রমটিকে কারণের প্রমাণ হিসেবে নয়, প্রসঙ্গ হিসেবে লিখুন; কী ব্যর্থ হওয়ার আগে লক পরিবর্তন একটি বিশ্বাসযোগ্য সম্পর্ক, প্রদর্শন নয়।
তারপর আপনি যে শাখা নির্ধারণ করেছেন সেই অনুযায়ী কাজ করুন। ক্ষণস্থায়ী: পরিচয় রাখুন, সমর্থিত পুনঃচেষ্টা পথ ব্যবহার করুন। প্রমাণীকরণ প্রয়োজন: সমর্থিত আনলক প্রবাহ সম্পূর্ণ করুন এবং ডায়ালগ পেরোতে তা নিষ্ক্রিয় করার বদলে ডিপ্লয়মেন্টের দাবি করা লক নীতি রাখুন। স্থায়ীভাবে অকার্যকর: স্বাভাবিক নথিভুক্তির মাধ্যমে পরিচয় প্রতিস্থাপন করুন ও অবসরে পাঠান।
শেষ করুন একটি নতুন অনুমোদিত সংযোগে ফলাফল প্রমাণ করে, একটি বাস্তব রিসোর্সে, সার্ভার যাচাই সক্রিয় রেখেই। যা কেবল শিথিল সার্টিফিকেট যাচাই নিয়ে কাজ করে তা কী-এর সমস্যা সারায়নি — তা নেটওয়ার্ক স্তরে সরিয়েছে, যেখানে পরে আরও খারাপ লক্ষণ নিয়ে দেখা দেবে।
- তিনটি শাখা: প্রমাণীকরণ প্রয়োজন, স্থায়ীভাবে অকার্যকর, প্রোভাইডার-ক্ষণস্থায়ী।
- কেবল তৃতীয়টিই আবার চেষ্টার সুফল পায়, এবং কেবল তার পুনঃচেষ্টা নীতি অনুসারে।
- প্রতিস্থাপনমূলক নথিভুক্তি অ্যাক্সেস ফিরিয়ে দেয়; ডেটা মুছে ফেলা সেই বিকল্পটি সরিয়ে দেয়।
- একটি নতুন সংযোগ ও স্বাভাবিক সার্ভার পরিচয় যাচাই দিয়ে যাচাই করুন।