OpenVPN PAM: লগইন আর্গুমেন্টটি একটি সার্ভিস, ব্যবহারকারী নয়
auth-pam প্লাগইনের পথের পরের শব্দটি একটি PAM স্ট্যাক বেছে নেয়। সেই স্ট্যাকটি পড়ুন, তার অ্যাকাউন্টের উৎস খুঁজুন, তারপর প্রোফাইল সম্পাদনার আগে pamtester দিয়ে পরীক্ষা করুন।
সার্ভারে একজন ব্যবহারকারী যোগ করা হয়েছে, পাসওয়ার্ড সঠিকভাবে টাইপ করা হয়েছে, তবুও সংযোগটি AUTH_FAILED দিয়ে শেষ হয়। প্লাগইন লাইনটি সাধারণত কারণ ব্যাখ্যা করে: প্লাগইনের পথের পরের শব্দটি একটি PAM সার্ভিসের নাম, এবং এটি ঠিক করে কোন মডিউল স্ট্যাকটি প্রশ্নের উত্তর দেবে। এটি কোনো ব্যবহারকারীর নাম নয়, এবং এটি এমন কোনো পাসওয়ার্ড ফাইলের দিকেও ইঙ্গিত নয় যা OpenVPN নিজেই পড়ে।
দ্বিতীয় শব্দটি কী বেছে নেয়
কনফিগারেশন লাইনটি একটি প্লাগইন পথ এবং একটি আর্গুমেন্ট নেয়:
plugin /usr/lib/openvpn/plugins/openvpn-plugin-auth-pam.so openvpnএই আর্গুমেন্টটি সার্ভিসের নাম হিসেবে PAM লাইব্রেরিতে পাঠানো হয়, ফলে /etc/pam.d/openvpn-এ থাকা স্ট্যাকটিই চলে। সেখানে login লিখলে আপনি বদলে ইন্টারঅ্যাকটিভ লগইন নীতি পাবেন, আপনার ডিস্ট্রিবিউশনে সেই নীতিতে যে মডিউলগুলো থাকে সেগুলোসহ।
ইনস্টল করা প্যাকেজ যে প্লাগইন পথ দেয় সেটি ব্যবহার করুন, অন্য হোস্ট থেকে কপি করা পথ নয়। ফাইলের নাম ও ডিরেক্টরি ডিস্ট্রিবিউশনভেদে আলাদা, আর ভুল পথ প্রমাণীকরণের সময় নয়, শুরুতে প্লাগইন লোড ত্রুটিতে ব্যর্থ হয়।
স্ট্যাকটি আসলে কোথা থেকে অ্যাকাউন্ট পড়ে
PAM একটি ডিসপ্যাচার। সার্ভিস ফাইলটি ক্রম অনুসারে মডিউল তালিকাভুক্ত করে, এবং যে প্রথমটি উত্তর দিতে পারে সেটিই ফলাফল নির্ধারণ করে। pam_unix ডাকা স্ট্যাক স্থানীয় অ্যাকাউন্ট পড়ে; LDAP বা RADIUS মডিউল ডাকা স্ট্যাক পরিচয়পত্র সম্পূর্ণ ভিন্ন জায়গায় পাঠায়।
সার্ভিসের নাম যে ফাইলে সমাধান হয় সেটি পড়ুন, সেটি যা কিছু অন্তর্ভুক্ত করে তা সহ:
cat /etc/pam.d/openvpn
grep -H pam_ /etc/pam.d/openvpn /etc/pam.d/common-authস্ট্যাক যদি কোনো ডিরেক্টরিতে অর্পণ করে, স্থানীয় অ্যাকাউন্ট যোগ করলে কিছুই বদলায় না। যদি এটি স্থানীয় অ্যাকাউন্ট পড়ে, ডিরেক্টরিতে ব্যবহারকারী তৈরি করলেও কিছুই বদলায় না। অ্যাকাউন্টটি অবশ্যই সেখানে থাকতে হবে যেখানে স্ট্যাক তাকায়, এবং এই প্রতিবেদনগুলোর বেশিরভাগে এটাই সম্পূর্ণ রোগনির্ণয়।
এক চেষ্টা, দুটি লগ
উভয় পক্ষে একটি ব্যর্থ সংযোগ মিলিয়ে দেখুন। OpenVPN লগ প্লাগইনের ফলাফল ও ক্লায়েন্টের প্রত্যাখ্যান দেখায়; সিস্টেমের প্রমাণীকরণ লগ দেখায় কোন মডিউল চলেছে এবং কী সিদ্ধান্ত নিয়েছে। একই সময়-জানালায় দুটোই পড়াই একটি অনুপস্থিত সার্ভিস ফাইলকে ব্যাকএন্ড টাইমআউট থেকে আলাদা করে। প্রমাণীকরণ লগে ফাঁক থাকার অর্থ স্ট্যাকটিতে কখনোই পৌঁছানো হয়নি।
journalctl -u openvpn-server@server --since "-2 min"
journalctl -t sshd -t sudo --since "-2 min"PAM-ভাষী একটি ইউটিলিটি দিয়ে সার্ভিসটি সরাসরি পরীক্ষা করুন, যাতে আপনি একসাথে VPN ও স্ট্যাক ডিবাগ না করেন। একই সার্ভিস নাম ও অ্যাকাউন্ট দিয়ে সফল সরাসরি পরীক্ষা সমস্যাটিকে ডেমন কীভাবে পরিচয়পত্র পাঠায় সেখানে সংকুচিত করে, অ্যাকাউন্টে নয়।
pamtester openvpn alice authenticateযদি সরাসরি পরীক্ষা কনসোলে কাজ করা একই পরিচয়পত্র দিয়ে ব্যর্থ হয়, তবে স্ট্যাক আপনার ধরে নেওয়া অ্যাকাউন্টের উৎস পড়ছে না। যদি সফল হয়, প্লাগইন যে কথোপকথন চালায় এবং ক্লায়েন্ট আসলে কী পাঠিয়েছে তা দেখুন। ইচ্ছাকৃতভাবে ভুল পাসওয়ার্ড দিয়েও একবার চালান, যাতে প্রত্যাখ্যান ও মডিউল ত্রুটির পার্থক্য দেখতে পারেন। এই দুটি ফলাফল VPN লগে একই রকম দেখায় এবং এখানে সম্পূর্ণ আলাদা।
নিবেদিত একটি সার্ভিস লগইন সম্পাদনার চেয়ে ভালো
VPN-কে নিজস্ব সার্ভিস ফাইল দিন যখন তার প্রয়োজনীয়তা ইন্টারঅ্যাকটিভ লগইন থেকে আলাদা, যা সাধারণত হয়। login বা common-auth সম্পাদনা করলে সেগুলো অন্তর্ভুক্ত প্রতিটি প্রোগ্রামের নীতি বদলে যায়, আর অসংশ্লিষ্ট লগইন সমস্যা ডিবাগ করা পরের ব্যক্তি আপনার পরিবর্তন উত্তরাধিকার সূত্রে পায়।
প্রয়োজনীয় মডিউলগুলো একটি ছোট সার্ভিস ফাইলে কপি করুন, ক্রম স্পষ্ট রাখুন, এবং কে এর মালিক তা লিখে রাখুন। পাসওয়ার্ড রিসেটের কোনো প্রভাব নেই বলে মনে হলে চেক করার জিনিস হলো সেই ফাইলটি।
ক্লায়েন্ট কী পাঠায়, আর কী পাঠায় না
ক্লায়েন্ট তার সমর্থিত প্রম্পট বা ফাইলের মাধ্যমে একটি ব্যবহারকারীর নাম ও পাসওয়ার্ড জোগায়। সার্ভার প্লাগইন সেই মানগুলো PAM কথোপকথনে পাঠায়; এটি সার্ভারের কনফিগারেশন থেকে সেগুলো পড়ে না। সার্ভারের দিকে এমন একটি লাইন যা পাসওয়ার্ড সংজ্ঞায়িত বলে মনে হয় তা করে না, এবং কোনো প্রোফাইল সম্পাদনা অ্যাকাউন্ট তৈরি করবে না।
ব্যবহারকারীর নাম ও পাসওয়ার্ড ক্লায়েন্ট সার্টিফিকেটের পাশাপাশি থাকতে পারে, এবং PAM চালু করা সার্টিফিকেট যাচাই বন্ধ করার কারণ নয়। ডিপ্লয়মেন্ট যে স্তরগুলো চেয়েছিল সেগুলো রাখুন এবং কেবল অ্যাকাউন্টের উৎস ঠিক করুন।
গ্রহণযোগ্যতা দুইমুখী: অভীষ্ট অ্যাকাউন্টটি সফল হয়, এবং যে অ্যাকাউন্ট প্রত্যাখ্যাত হওয়া উচিত সেটি এখনও ব্যর্থ হয়। ফাইলটি auth-pam প্লাগইনের README সার্ভিস আর্গুমেন্ট এবং যে ব্যাকএন্ডগুলো এটি সামলাতে পারে তা নথিভুক্ত করে, এবং আপনি যে বিন্যাস তৈরি করতে চাইছেন তা নিশ্চিত করার জায়গা সেখানেই।