একজন ব্যবহারকারী VPN-এ সাইন ইন করতে পারছেন না: একটি ক্রমবদ্ধ রোগনির্ণয়

যখন একজন ব্যক্তি সংযোগ করতে ব্যর্থ হন আর দলের বাকিরা কাজ চালিয়ে যায়, তখন উপকারী প্রশ্নটি হলো কী নষ্ট হয়েছে তা নয়, বরং কোন স্তরটি একমত হয়নি। সাইন ইন একটি শিকল: ক্লায়েন্ট শুরু হয়, গেটওয়ে উত্তর দেয়, একটি পরিচয় দাবি করা হয়, দ্বিতীয় কারণ সন্তুষ্ট হয়, নীতি মূল্যায়ন হয়, এবং কেবল তখনই ট্রাফিক প্রবাহিত হয়। সেই শিকলের যেকোনো জায়গায় ছেদ ব্যবহারকারীর কাছ থেকে একই বাক্য হিসেবে আপনার কাছে পৌঁছায়, তাই প্রথম কাজ হলো সত্যিই ব্যর্থ হওয়া সংযোগটি খুঁজে বের করা।

প্রতিবেদনটিকে রোগনির্ণয় নয়, শুরুর বিন্দু হিসেবে ধরুন। নিচের পরীক্ষাগুলো সবচেয়ে সস্তা থেকে শুরু হয়, এবং প্রতিটি এমনভাবে লেখা যে ব্যর্থ হলে তদন্ত শেষ হয়ে যায়।

পর্যায় ও টাইমস্ট্যাম্প চিহ্নিত করুন

কোনো কনফিগারেশন স্পর্শ করার আগে চারটি জিনিস লিখে রাখুন: ক্লায়েন্ট ও তার সংস্করণ, স্ক্রিনে থাকা সঠিক শব্দবিন্যাস, চেষ্টার মিনিট, এবং ব্যক্তিটি যে নেটওয়ার্কে ছিলেন। শব্দবিন্যাস সত্যিকারের তথ্য বহন করে, কারণ প্রত্যাখ্যাত শংসাপত্র, উত্তরহীন গেটওয়ে এবং একটি সম্পন্ন সাইন ইন যা তবুও একটি অভ্যন্তরীণ পৃষ্ঠা খুলতে পারে না তিনটি ভিন্ন মালিকের তিনটি ভিন্ন সমস্যা। ক্লায়েন্ট স্থানীয় লগ লাইন তৈরি করেছে কি না লক্ষ্য করুন, কারণ যে ক্লায়েন্ট কখনো প্যাকেট পাঠায়নি তার সার্ভার-সাইড অনুসন্ধানে যোগ করার কিছু নেই। টাইমস্ট্যাম্প লিপিবদ্ধ থাকলে পরবর্তী প্রতিটি জিজ্ঞাসা শিকার নয়, খোঁজে পরিণত হয়।

এই পর্যায়ে পাসওয়ার্ড অনুমান করা বন্ধ করুন। যেখানে অ্যাকাউন্টের পুনঃচেষ্টার সীমা আছে, দ্রুত চেষ্টার ঝাঁক সেটি লক করে আসল ত্রুটির ওপরে দ্বিতীয়, কৃত্রিম ত্রুটি যোগ করতে পারে। ইতিমধ্যে কতবার চেষ্টা করা হয়েছে তা লিখে রাখুন, যাতে লকআউটকে পরে নতুন উপসর্গ ভাবা না হয়। লক হওয়া অ্যাকাউন্ট ভুল পাসওয়ার্ডকে প্রত্যাখ্যাত নীতি থেকে আলাদা করার ক্ষমতাও কেড়ে নেয়, কারণ দুটোই প্রত্যাখ্যান হিসেবে আসে।

সেই একক চেষ্টার পরিচয়-ঘটনাটি পড়ুন

প্রশাসককে আপনার লিপিবদ্ধ মিনিটের সাথে মেলে এমন প্রমাণীকরণ রেকর্ডটি বের করতে বলুন। Windows NPS স্থাপনায় Microsoft-এর NPS সমস্যা সমাধানের নির্দেশিকা প্রত্যাখ্যান ঘটনা 6273 এবং তার সাথে আসা কারণ কোড নথিভুক্ত করে, যা সাধারণত অজানা ব্যবহারকারী, খারাপ শংসাপত্র, নীতি অমিল এবং অসম্পর্কিত কারণে বাদ পড়া কলকে আলাদা করে।

খালি ফলাফলও তথ্য। যদি পরিচয় পরিষেবায় কিছুই পৌঁছায়নি, তবে চেষ্টাটি আরও আগে মারা গেছে: প্রোফাইলে পুরোনো গেটওয়ে ঠিকানা, ক্লায়েন্ট যে লিসেনারে পৌঁছাতে পারে না, বা এমন হোস্ট যা প্রোফাইল টিকে থাকতেই অবসর দেওয়া হয়েছে। যদি রেকর্ড থাকে এবং সফলতা জানায়, তবে শংসাপত্র সমস্যা নয় এবং তর্কটি অনুমোদন বা গেটওয়ের পেছনের রাউটিং-এ সরে যায়। এই দুই ফলাফল বিপরীত দিকে নির্দেশ করে, তাই কেউ ক্লায়েন্ট পুনঃস্থাপন করার আগেই লগ অনুসন্ধান করতে হবে।

কারণ কোডটি টিকিটে রাখুন। এই একটি ক্ষেত্র পরবর্তী ঘটনাকে পুনরায় তদন্তের বদলে পাঁচ মিনিটের খোঁজে পরিণত করে। এটি ক্লায়েন্ট সংস্করণের সাথে জুড়ুন, কারণ একটি বিল্ডে দেখা যায় এমন কোড প্রতিটি বিল্ডে দেখা যায় এমন কোডের চেয়ে ভিন্ন আলোচনা।

নীতির মধ্যে একবারে একটি শর্ত বদলান

প্রলোভন হলো একবারে ক্লায়েন্ট পুনঃস্থাপন, পাসওয়ার্ড রিসেট এবং ল্যাপটপ অন্য নেটওয়ার্কে সরানো। এটি কখনো উপসর্গ সারায় এবং সবসময় প্রমাণ নষ্ট করে। বরং একটি অনুমোদিত বদল বেছে নিন: একই ব্যক্তি দ্বিতীয় নিবন্ধিত ডিভাইসে, বা একই ডিভাইসে অনুমোদিত পরীক্ষা-পরিচয়। প্রতিটি বদল ঠিক একটি প্রশ্নের উত্তর দেয়, তাই সফলতা ত্রুটিকে আপনি যে দিকটি বদলেছেন সেখানে সংকুচিত করে, VPN-কে সামগ্রিকভাবে দোষারোপ না করে।

এই তুলনা করতে সহকর্মীর শংসাপত্র ধার করবেন না। সমর্থিত প্রক্রিয়ার মাধ্যমে পরীক্ষা-পরিচয় ব্যবহার করুন, এবং দ্রুত হবে বলে কখনো ডিভাইস কী কপি করবেন না বা নিবন্ধন এড়াবেন না। যেখানে নীতি বদল সম্পূর্ণ নিষিদ্ধ করে, সেই সীমাবদ্ধতা পরীক্ষাধীন সিস্টেমের অংশ এবং তা কোনো ফাঁকি নয়, রেকর্ডে থাকা উচিত।

মূল পথে মেরামত নিশ্চিত করুন

ভাঙা সংযোগ শনাক্ত হলে কেবল সেই সংযোগটি মেরামত করুন এবং মূল চেষ্টাটি পুনরাবৃত্তি করুন: একই ব্যক্তি, একই ডিভাইস, একই নেটওয়ার্ক, একই অ্যাপ্লিকেশন। অ্যাডমিন VLAN থেকে সংযোগ করা একটি পরীক্ষা-অ্যাকাউন্ট প্রমাণ করে গেটওয়ে জীবিত, এবং ব্যবহারকারীর মঙ্গলবার সকাল সম্পর্কে কিছুই প্রমাণ করে না। ব্যবহারকারীকে সহজতর কাজ নয়, বরং যে কাজটি ব্যর্থ হয়েছিল তা করতে বলুন, কারণ সফল ping প্রত্যাখ্যাত ফাইল শেয়ার সম্পর্কে কম বলে।

কী বাদ পড়েছে এবং কী বদলেছে তা দিয়ে টিকিট বন্ধ করুন। সেই নোটই এককালীন উদ্ধার আর পরবর্তী ডিউটি-ইঞ্জিনিয়ার পুনরায় ব্যবহার করতে পারেন এমন কিছুর মধ্যে পার্থক্য।