এই বাক্যাংশটিকে পাসওয়ার্ড সম্পর্কে নয়, বরং একটি শেয়ার্ড অবজেক্ট ও একটি ফাংশন পয়েন্টার সম্পর্কে বিবৃতি হিসেবে পড়ুন। একই শব্দগুলো আসতে পারে একটি OpenVPN প্লাগইন থেকে, একটি নির্দিষ্ট সার্ভিসের জন্য লোড করা PAM স্ট্যাক থেকে, বা RADIUS ডেমনয়েডের ভেতর থেকে, আর এগুলো তিনটি ভিন্ন তদন্ত। আগে প্রক্রিয়াটি নির্ধারণ করুন।

নিচের পরীক্ষাগুলো ধরে নেয় যে বার্তাটি VPN লগইনে Linux-PAM ইন্টিগ্রেশনের মাধ্যমে এসেছে। যদি এটি RADIUS সার্ভারের নিজস্ব কনফিগারেশন থেকে এসে থাকে, তবে সেই ডেমনয়েডের প্রমাণ থেকেই শুরু করুন।

প্যাকেজের নাম দেওয়ার আগে প্রক্রিয়ার নাম দিন

তিনটি উপাদানকে মডিউল বলা হয় এবং এর কোনোটিই পরস্পর বিনিময়যোগ্য নয়। OpenVPN প্রমাণীকরণ প্লাগইন VPN ডেমনয়েড লোড করে এবং সেই ডেমনয়েডের কলব্যাক ইন্টারফেস বাস্তবায়ন করে। PAM মডিউল হলো একটি শেয়ার্ড অবজেক্ট, যা নির্দিষ্ট সার্ভিসের জন্য libpam লোড করে, এবং pam_sm_authenticate -এর মতো এন্ট্রি পয়েন্ট বাস্তবায়ন করে। FreeRADIUS মডিউল হলো সেই ডেমনয়েডের নিজস্ব কনফিগারেশনের একটি অংশ। একই শব্দযুক্ত বার্তা তিনটির যে কোনোটি থেকে আসতে পারে, তাই প্রথম প্রশ্ন হলো কোন লগ লাইনটি এটি তৈরি করেছে।

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

আগে লোডিং ত্রুটি, তারপর এন্ট্রি পয়েন্ট পড়ুন

PAM অজানা মডিউল রিপোর্ট করে যখন এটি নির্বাচিত শেয়ার্ড অবজেক্ট লোড করতে পারে না, অথবা যখন লোড করা অবজেক্টটি সেই স্ট্যাক এন্ট্রির প্রয়োজনীয় ফাংশন সরবরাহ করে না। এগুলো ভিন্ন মেরামত: প্রথমটি পাথ, প্যাকেজিং বা ABI সমস্যা, দ্বিতীয়টি অসামঞ্জস্যপূর্ণ এন্ট্রি পয়েন্ট। একটি প্রমাণীকরণ লাইনের প্রয়োজন pam_sm_authenticate আর একটি অ্যাকাউন্ট লাইনের প্রয়োজন pam_sm_acct_mgmt, এবং যে লাইব্রেরি এদের একটিমাত্র বাস্তবায়ন করে সেটি অন্যটিতে ব্যর্থ হবে, যেমনটি ডিসপ্যাচার কোড দেখায়। ডিস্কে ফাইলটি খুঁজে পাওয়া কোনোটিই প্রমাণ করে না।

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

স্ট্যাক যে নিশ্চয়তাগুলো দিচ্ছিল সেগুলো ধরে রাখুন

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

একটি বহু-মডিউল স্ট্যাক ব্যর্থ এন্ট্রির আগে অন্য ব্যাকএন্ড চালিয়ে থাকতে পারে, তাই এই ত্রুটি প্রমাণ করে না যে কোনো RADIUS অনুরোধ পাঠানো হয়নি।

মডিউল নয়, লগইন যাচাই করুন

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

মডিউল পরিষ্কারভাবে লোড হওয়া একটি অগ্রগতি, সম্পূর্ণ পরীক্ষা নয়।

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

সম্পর্কিত নিবন্ধ