VPN পাসওয়ার্ড রিসেটের পরেও একটি ডিভাইস সংযোগ করতে পারছে না
নতুন পাসওয়ার্ড এক ক্লায়েন্ট ছাড়া সব জায়গায় কাজ করছে। পুরনো মানটি যে স্টোরে এখনও আছে সেটি খুঁজুন, পুনঃপ্রচেষ্টা সীমিত রাখুন এবং একবার চেষ্টা করে যাচাই করুন।
আপনি পাসওয়ার্ড রিসেট করেছেন, পোর্টালে পরীক্ষা করেছেন, তবুও একটি ল্যাপটপ এখনও সংযোগ করতে পারে না। প্রবৃত্তি বলে আবার রিসেট করুন, আর ঠিক এভাবেই অ্যাকাউন্ট লক হয় এবং একটি পুরনো গোপন তথ্য ঘটনায় পরিণত হয়। VPN ক্লায়েন্ট খুব কমই প্রতিবার পাসওয়ার্ড চায়; এটি একবার চায় এবং উত্তরটি এমন জায়গায় সংরক্ষণ করে যা আপনি বেছে নেননি। সেই জায়গাটি খুঁজে বের করাই পুরো কাজ, এবং এটি আরেকবার রিসেটের চেয়ে দ্রুত।
প্রতিটি ক্লায়েন্ট আসলে কী পাঠাচ্ছে তা নিশ্চিত করুন
পাসওয়ার্ডই সমস্যা ধরে নেওয়ার আগে ব্যর্থ ক্লায়েন্টে অ্যাকাউন্ট, ডোমেইন ও গেটওয়ে যাচাই করুন। ওয়েব পোর্টাল লগইন VPN থেকে ভিন্ন পরিচয় ব্যবস্থা ব্যবহার করতে পারে, তাই সফল পোর্টাল সাইন-ইন প্রোটোকলের প্রমাণীকরণ সম্পর্কে কিছুই বলে না। কিছু স্থাপনা পোর্টালে ইমেইল এবং টানেলে ভিন্ন ব্যবহারকারীর নাম গ্রহণ করে। কিছু রিসেট করার আগে ক্লায়েন্ট কোন পরিচয় উপস্থাপন করতে কনফিগার করা আছে তা নিশ্চিত করুন।
ত্রুটির লেখা পড়ুন এবং শ্রেণিবদ্ধ করুন। সার্টিফিকেট ব্যর্থতা, মেয়াদোত্তীর্ণ চ্যালেঞ্জ বা অসমর্থিত সাইফার কোনো পুরনো পাসওয়ার্ড নয়, এবং এটিকে তাই ভেবে সমাধান করলে কোনো ফল ছাড়াই রিসেটের চক্র তৈরি হয়। পরিষেবার লকআউট নীতি থাকলে দুই বা তিনবার ব্যর্থ চেষ্টার পর থামুন এবং চালিয়ে যাওয়ার আগে অ্যাকাউন্টের অবস্থা নিশ্চিত করুন।
অনুমান না করে স্টোরগুলো তালিকাভুক্ত করুন
একটি VPN গোপন তথ্য চারটি স্টোরে রাখে, এবং নিচের সারণি প্রতিটির জন্য দেখায় মানটি কোথায় টিকে থাকে এবং তা মুছে ফেলার প্রকৃত অর্থ কী। নেটিভ OS প্রোফাইল প্ল্যাটফর্মের ক্রেডেনশিয়াল স্টোরে গোপন তথ্য রাখে, তাই এন্ট্রিটি যে অ্যাপ্লিকেশন এটি লিখেছিল তার চেয়ে বেশি দিন টিকে থাকতে পারে। ক্লায়েন্ট কনফিগারেশন ফাইল মানটি সেই ক্লায়েন্ট যেখানে পড়ে সেখানে রাখে—হয় ইনলাইনে, নয়তো রেফারেন্স করা auth ফাইলে, তাই ভিন্ন ফাইল সম্পাদনা করলে কিছুই বদলায় না। ব্রাউজার পোর্টাল কুকি এবং নীতি-প্রদত্ত ক্রেডেনশিয়াল এমন জায়গায় থাকে যা ডিভাইস সত্যিই মালিকানায় পায় না, আর এটাই নির্ধারণ করে কে সেগুলো বদলাতে পারবে।
| Store | Where it lives | How to clear it |
|---|---|---|
| Native OS profile | Windows Credentials, NetworkManager secrets | forget or edit the connection |
| Client configuration file | a referenced auth file or inline value | edit the file the client actually reads |
| Browser session | cookie for the portal SSO | sign out of the portal, not just close the tab |
| Managed policy | delivered by the management service | change it in the manager, not on the device |
সেগুলো একটি নির্দিষ্ট ক্রমে যাচাই করুন: প্রথমে OS ক্রেডেনশিয়াল স্টোর, কারণ ক্লায়েন্ট ডিফল্টভাবে এটিই জিজ্ঞাসা করে, তারপর ক্লায়েন্টের নিজস্ব ভল্ট বা কনফিগ ফাইল, তারপর ব্রাউজার সেশন, এবং শেষে সেই নীতি যা তিনটিকেই ওভাররাইট করতে পারে। ক্রমটি গুরুত্বপূর্ণ কারণ পরের স্টোর আগেরটি নীরবে পুনরুদ্ধার করতে পারে, আর ব্যর্থতা চলতে থাকলে আপনি ভুল স্তর ঠিক করবেন। কোন স্টোর বদলেছেন তা লিখে রাখুন, কারণ সেই নোটই পরের রিসেটকে এক বিকেলের বদলে দুই মিনিটের কাজ করে তোলে।
ক্লায়েন্ট আসলে যে স্টোর ব্যবহার করে সেখানে দেখুন
মুছে ফেলার আগে পড়ুন, যাতে জানতে পারেন কোন এন্ট্রিটি VPN-এর ছিল। নিচের কমান্ডগুলো মুছে ফেলার বদলে তালিকা ও পরিদর্শন করে, যা রোগনির্ণয়কে বিপরীতমুখী রাখে।
# Windows credential store
cmdkey /list | findstr /i vpn# Windows native profile
Get-VpnConnection -Name "Work" | Select-Object -ExpandProperty Guid# macOS Keychain
security find-generic-password -s "Company VPN" -g# Linux NetworkManager
nmcli -s connection show "Work" | grep -i passwordLinux-এ -s এমন গোপন তথ্য দেখায় যা NetworkManager অন্যথায় লুকায়। macOS-এ Keychain কমান্ড সংরক্ষিত আইটেমটি প্রিন্ট করে, তাই টার্মিনালের স্ক্রলব্যাককে সংবেদনশীল হিসেবে ধরুন। ব্যর্থ ক্লায়েন্ট যদি নিজস্ব ভল্টসহ তৃতীয় পক্ষের অ্যাপ হয়, তবে OS স্টোর সঠিক দেখাবে অথচ অ্যাপ নিজের কপি রাখবে, আর সেই ভল্টই পরিবর্তনের সঠিক জায়গা।
অফলাইন থাকা ডিভাইসগুলো সামলান
নিজে থেকে জেগে ওঠা ও পুনঃসংযোগ করা ল্যাপটপ তাদের কপি যতদিন থাকবে ততদিন পুরনো গোপন তথ্য উপস্থাপন করতেই থাকবে। আপডেটটি এমনভাবে পরিকল্পনা করুন যাতে ওই ডিভাইসগুলো একসঙ্গে আবার চেষ্টা করার আগেই সংশোধিত হয়, এবং প্রতিটি সমর্থিত প্রবাহ পার না হওয়া পর্যন্ত আক্রান্ত প্রোফাইলে স্বয়ংক্রিয় সংযোগ বন্ধ করার কথা ভাবুন।
পরিচালিত ফ্লিটের ক্ষেত্রে নীতিটি যেখানে সংজ্ঞায়িত সেখানেই মানটি বদলান। যে ডিভাইসের ক্রেডেনশিয়াল কেন্দ্রীয়ভাবে সরবরাহ হয় তার স্থানীয় কপি সম্পাদনা করা সর্বোত্তম ক্ষেত্রেও সাময়িক; পরের নীতি রিফ্রেশ পুরনো মান ফিরিয়ে দেয় এবং ব্যর্থতা ব্যাখ্যা ছাড়াই ফিরে আসে।
একটি নিয়ন্ত্রিত চেষ্টায় যাচাই করুন
উদ্দিষ্ট এন্ট্রি হালনাগাদ করুন, একবার পুনঃসংযোগ করুন, এবং টানেল নির্দিষ্ট কিছুতে পৌঁছায় কি না নিশ্চিত করুন। একটি নিয়ন্ত্রিত চেষ্টা ব্যর্থ হলে ব্যবহারযোগ্য ত্রুটি দেয়, অন্যদিকে বিশটি লক হওয়া অ্যাকাউন্ট ও এক রহস্য দেয়। স্টোর সংশোধনের পরও কোনো ক্লায়েন্ট ব্যর্থ হলে গোপন তথ্য ছাড়া একটি ত্রুটি ধরে থামুন। সেই ত্রুটিটি ডিভাইসের নামের সঙ্গে রাখুন যাতে পরের শিফট আপনি যেখানে শেষ করেছেন সেখান থেকেই শুরু হয়।
পাসওয়ার্ড পরিবর্তন সার্টিফিকেট, সেশন টোকেন বা MFA নিবন্ধনে হাত দেয় না, এবং সেগুলো নিজস্ব জীবনচক্রসহ আলাদা পরিচয়। নবায়িত সার্টিফিকেট পাসওয়ার্ড ঘোরানোর মাধ্যমে ঠিক হয় না, আর রিসেটের আগে জারি করা টোকেন এখনও বৈধ থাকতে পারে। কোন স্টোরে পুরনো মান ছিল তা লিখে শেষ করুন, কারণ পরের রিসেট একই তালিকায় পৌঁছাবে।