OpenVPN সেবা প্রাইভেট কী পাসওয়ার্ড চাওয়ার সময় থেমে যায়: সমাধান
সেবার কোনো টার্মিনাল নেই, তাই এনক্রিপ্ট করা কী-এর জন্য askpass ও পাঠযোগ্য ফাইল দরকার। কী-এর পাসফ্রেজ সার্ভার লগইন থেকে আলাদা করুন এবং unit যাচাই করুন।
OpenVPN লোকাল মেশিনে প্রাইভেট কী-এর পাসফ্রেজ চায়, তাই একটি কাজ করা লগইন ফাইল কখনো তার উত্তর দেয় না। সেবার মধ্যে টাইপ করার টার্মিনাল থাকে না, আর শুরু হওয়া হয় আটকে যায়, নয়তো জার্নালে এমন একটি এন্ট্রি নিয়ে ব্যর্থ হয় যা কারণ নয়, অনুপস্থিত ইনপুটের নাম বলে। এখানে দুটি গোপন তথ্য জড়িত, আর unit পুনরায় চালু করার আগে প্রত্যেকের নিজস্ব পাঠযোগ্য উৎস দরকার। নিচের ধাপগুলি সেগুলি আলাদা করে, তারপর যে পরিচয়টি আসলে প্রতিটি ফাইল খোলে তা যাচাই করে।
দুটি অনুরোধের পার্থক্য বুঝুন
কী-এর পাসফ্রেজ লোকাল প্রাইভেট কী ডিক্রিপ্ট করে; অ্যাকাউন্টের ক্রেডেনশিয়াল সার্ভারের সঙ্গে সেশন প্রমাণ করে। এগুলি ভিন্ন জায়গা থেকে আসে, ভিন্ন সময়ে ব্যর্থ হয় এবং ভিন্ন বার্তা দেয়। এদের গুলিয়ে ফেললে মানুষ পাসওয়ার্ড রিসেট খুঁজতে যায়, অথচ অ্যাকাউন্ট সেখানেই ছিল না। কোনো অপশন বদলানোর আগে অনুরোধের লেখাটি পড়ুন, কারণ কোন গোপন তথ্য অনুপস্থিত তার একমাত্র নির্ভরযোগ্য সংকেত ওই শব্দবিন্যাস।
Community OpenVPN 2.x-এ askpass এমন একটি ফাইল বোঝায় যার প্রথম লাইনে কী-এর পাসফ্রেজ থাকে, আর auth-user-pass এমন ফাইল বোঝায় যার এক লাইনে ব্যবহারকারীর নাম ও পরের লাইনে পাসওয়ার্ড থাকে। কোনও ফাইলই অন্য অপশনটি মেটাতে পারে না। ডেস্কটপ অ্যাপ বা NetworkManager প্রোফাইল দুটিই নিজের গোপন ভাণ্ডারে রাখতে পারে, যা কমান্ড-লাইন ক্লায়েন্ট কখনো পড়ে না, তাই কোনও পথ লেখার আগে নিশ্চিত করুন আপনি কোন ক্লায়েন্ট কনফিগার করছেন।
দুটি অপশনই পাঠযোগ্য ফাইলের দিকে নির্দেশ করুন
যে প্রোফাইলে দুটি ইনপুটই দরকার, শেষে তার তিনটি ফাইল রেফারেন্স থাকে: এনক্রিপ্ট করা কী, তা খোলার পাসফ্রেজ, এবং লগইন জোড়া। CA ও পরিচয় যাচাই না ছুঁয়ে সেগুলি যোগ করুন, কারণ ওগুলি ঠিক করে সার্ভার কে এবং এই সমস্যার অংশ নয়। যদি ডিপ্লয়মেন্ট অ্যাকাউন্ট ক্রেডেনশিয়াল একেবারেই না ব্যবহার করে, তবে auth-user-pass যোগ করলে এমন ইনপুট তৈরি হয় যা কেউ দিতে পারবে না।
key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.authখালি অপশনগুলি পথযুক্ত অপশন থেকে আলাদা আচরণ করে, আর সেবার ক্ষেত্রে এই পার্থক্যটি গুরুত্বপূর্ণ। আর্গুমেন্ট ছাড়া askpass এখনও কনসোল পড়ে, আর শুধু ব্যবহারকারীর নাম থাকা auth-user-pass ফাইল এখনও একটি পাসওয়ার্ড অনুরোধ অপেক্ষায় রেখে যায়। ক্লায়েন্ট ডেমন হয়ে গেলে টার্মিনাল থেকে ইনপুট চাইতেই পারে না, তাই এভাবে কনফিগার করা সেবা চালু হয় না।
পরম পথ কাজের ডিরেক্টরির প্রশ্ন সরিয়ে দেয়, কিন্তু প্রবেশাধিকার দেয় না। এরপর আসে মালিকানা, মোড ও পথচলা, আর তিনটিই প্রসেস যে অ্যাকাউন্টে চলে তার বিপরীতে যাচাই হয়।
প্রোফাইলের আগে unit-এর কনফিগারেশন পড়ুন
ইনস্ট্যান্স কোন কনফিগারেশন লোড করবে তা ঠিক করে unit, আপনি যে ফাইল সম্পাদনা করছিলেন তা নয়। এর কমান্ড লাইন ও সব drop-in পড়ুন, তারপর কাজের ডিরেক্টরি ধরে যে প্রোফাইলটি সত্যিই ব্যবহৃত হচ্ছে সেখানে যান। অন্য একটি .ovpn ফাইলে যোগ করা পাসফ্রেজ রেফারেন্স এই ইনস্ট্যান্সের জন্য কিছুই বদলায় না।
তিনটি শুধু-পড়ার কমান্ড এর বেশিরভাগের উত্তর দেয়। প্রথমটি unit ও সব drop-in দেখায়, দ্বিতীয়টি প্রসেসকে সীমিত করা পরিচয় ও স্যান্ডবক্স সেটিংস দেখায়, আর তৃতীয়টি দেখায় শেষবারের শুরু আসলে কী নিয়ে অভিযোগ করেছিল। হোস্টে যে ইনস্ট্যান্স নাম আছে সেটিই ব্যবহার করুন:
systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -bProtectHome এবং প্রোফাইলের নিজের user, group ও chroot অপশনে মন দিন। হোম ডিরেক্টরির নিচের ফাইল আপনার শেলে পাঠযোগ্য হতে পারে, কিন্তু হোম ডিরেক্টরি লুকানো হলে সেবার ভিতরে অদৃশ্য হয়ে যায়। systemd যে অ্যাকাউন্টে শুরু করে, শেষে কী খোলা সেই অ্যাকাউন্ট সবসময় সেটি নয়।
প্রমাণ করুন রানটাইম পরিচয় দুটি ফাইলই খুলতে পারে
শুধু মোড পড়া যথেষ্ট নয়, কারণ পথের প্রতিটি ডিরেক্টরি একই পরিচয়ের জন্য পার হওয়া যোগ্য হতে হবে। পথটি উপাদান ধরে ধরে হাঁটুন, তারপর প্রসেস যে অ্যাকাউন্ট ব্যবহার করে সেই হিসেবে খোলাটি পরীক্ষা করুন। root-এর মালিকানাধীন ও মোড 600 ফাইল কেবল তখনই কাজ করে যখন প্রসেস এখনও root, আর অনেক প্রোফাইলের বিশেষাধিকার কমানোর পর তা সত্য নয়। দুটি কমান্ড পথচলা ও খোলা দুটিই ঢেকে দেয়:
namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readableপ্রথম কমান্ড প্রতিটি উপাদানের মোড দেখায় এবং যেখানে অ্যাকাউন্ট পার হতে পারে না সেখানে ব্যর্থ হয়; দ্বিতীয়টি একমাত্র গুরুত্বপূর্ণ প্রশ্নের উত্তর দেয়, অর্থাৎ রানটাইম পরিচয় ফাইলটি পড়ার জন্য খুলতে পারে কি না। কোনওটিই ফাইলের বিষয়বস্তু দেখায় না, আর ফাইলে পাসফ্রেজ থাকলে এটাই আসল কথা। লগইন ফাইলের জন্যও পরীক্ষাটি পুনরাবৃত্তি করুন, কারণ দুটি প্রায়ই ভিন্ন মালিকানায় সংরক্ষিত থাকে।
যদি প্রসেস chroot বা সীমিত namespace ব্যবহার করে, একই পরীক্ষা ওই দৃশ্যের ভিতর থেকে চালান, নয়তো উত্তর ভুল ফাইলসিস্টেমের কথা বলে। লুকানো হোম ডিরেক্টরির নিচে রাখা পাসফ্রেজ হলো unit-এর বাইরে পাস করে ভিতরে ব্যর্থ হওয়া পরীক্ষার সাধারণ উদাহরণ।
প্রথম শুরু দেখুন, তারপর পুনঃসংযোগ
ইনস্ট্যান্সটি একবার চালু করুন এবং শেষ নয়, প্রথম ব্যর্থতাটি পড়ুন। অনুপস্থিত ইনপুট ফাইল, কী ডিক্রিপ্টে ব্যর্থতা আর সার্ভারের দিকের AUTH_FAILED তিনটি আলাদা ঘটনা, তিনটি আলাদা সমাধান। অনুমতি-সংক্রান্ত সতর্কবার্তা সারানো কী খোলা হয়েছে তা প্রমাণ করে না।
জার্নালের লাইন বলে দেয় তিনটির কোনটি আপনার ক্ষেত্রে। কোন ইনপুট ব্যর্থ হয়েছে তা থেকেই সমাধান আসে:
| What the journal shows | Which input failed | Where to look |
|---|---|---|
| A path that cannot be opened | The file the profile names | Askpass or login path, and the unit's working directory |
| A key decryption error | The key passphrase | First line of the askpass file, and read access for the runtime identity |
AUTH_FAILED from the server | The account credentials | Login file contents, and whether the account is still valid |
তারপর আপনার সত্যিই প্রয়োজনীয় জীবনচক্র পরীক্ষা করুন: বুটে শুরু এবং সমর্থিত যেকোনো পুনঃসংযোগ, শুধু আপনার শেল থেকে হাতে চালানো নয়। auth-nocache থাকলে প্রথম ব্যবহারের পরেই ইনপুটগুলি ফেলে দেওয়া হয়, তাই পরের পুনঃসংযোগেও পাঠযোগ্য উৎস দরকার। ডেস্কটপ লগইনে খোলা keyring এমন সেবার জন্য পাওয়া যায় না যা কেউ লগইন করার আগেই শুরু হয়েছে, আর এটাই হাতে পরীক্ষা পাস করে রিবুটে ব্যর্থ হওয়ার সাধারণ কারণ। প্রথম শুরু সফল হয়ে পরের পুনঃসংযোগ ব্যর্থ হলে, আবার অনুমতি বদলানোর আগে পুনঃসংযোগের ঘটনার জন্য জার্নাল পড়ুন।
কী-এর পাশে পাসফ্রেজ রাখলে এনক্রিপশন যা দেয় তা কমে যায়, তাই ওই ফাইল ও তার ব্যাকআপ সীমিত রাখুন। কী-এর পাসফ্রেজ সরানোকে অনুপস্থিত ইনপুটের সমাধান নয়, আলাদা ক্রেডেনশিয়াল সিদ্ধান্ত হিসেবে দেখুন। মানুষর অনুমোদন বা ইন্টার্যাক্টিভ MFA-নির্ভর ডিপ্লয়মেন্টের জন্য সমর্থিত agent বা ম্যানেজমেন্ট ইন্টিগ্রেশন দরকার; স্থায়ীভাবে সংরক্ষিত এককালীন কোড সমতুল্য বিকল্প নয়।