openvpn3 session-start আপনার ক্রেডেনশিয়াল ফাইল উপেক্ষা করে

2.x ক্লায়েন্ট দিয়ে সংযোগ করুন, প্রোফাইল কাজ করবে; একই ফাইল 3.x ক্লায়েন্টকে দিলে তা পাসওয়ার্ড প্রম্পটে থেমে যাবে। --auth-user-pass creds.txt কে openvpn3 session-start এর কাছে দিলেও ফল একই, কারণ নতুন ক্লায়েন্টে ফাইলটি পড়ার কোনো ধাপ নেই। অস্বীকৃতিটি ইচ্ছাকৃত: ক্রেডেনশিয়াল সেশনভুক্ত, আর সেশন তৈরি করে একটি সার্ভিস, আপনার টার্মিনালের প্রক্রিয়া নয়। ইন্টারঅ্যাকটিভ প্রম্পট আর অটোলোড হেল্পারের মধ্যে বেছে নিন, এবং জানুন প্রতিটি কী সংরক্ষণ করে।

কেন সংরক্ষিত ফাইলের যাওয়ার জায়গা নেই

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

পুরোনো ধরনটির নাম দেওয়া ভালো, যাতে ভুলে যাওয়া সহজ হয়: একটি প্রোফাইল একটি ক্রেডেনশিয়াল ফাইলের উল্লেখ করে, আর টানেল শুরু হলে ডেমন তা পড়ে। নতুন মডেলে ক্রেডেনশিয়াল সেশনভুক্ত এবং সেই সেশন শুরুর সময় সরবরাহ করা হয়। openvpn3 session-start --config work.ovpn সেগুলো চায়, আর --auth-user-pass creds.txt প্রত্যাখ্যাত হয়, কারণ ওই পথে কিছুই ফাইলটি খুলত না। আপনি যে 2.x রেসিপিই পান না কেন, তা এমন একটি ধাপ ধরে নেয় যা আর নেই।

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

প্রম্পটের পথ এবং এটি যে সেশন রেখে যায়

সেশন শুরুর সময় পাসওয়ার্ড দেওয়াই হলো উদ্দিষ্ট কর্মপ্রবাহ। ক্লায়েন্ট একবার জিজ্ঞাসা করে, ক্রেডেনশিয়াল সেশনের ব্যাকএন্ডে দেয়, এবং এগিয়ে যায়:

openvpn3 session-start --config work.ovpn
openvpn3 sessions-list

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

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

কীবোর্ডে মানুষ ছাড়া অটোমেশন

যেখানে মেশিনকে মানুষ ছাড়া সংযোগ করতে হয়, প্রকল্পটি openvpn3-autoload দেয়। এটি প্রোফাইলের একটি ডিরেক্টরি এবং প্রতিটি প্রোফাইলের জন্য মিলে যাওয়া ডেস্ক্রিপ্টর পড়ে, আর ডেস্ক্রিপ্টর প্লেইন টেক্সটে ক্রেডেনশিয়াল সরবরাহ করে। হেল্পারটি আলাদা বাইনারি, সাধারণত /usr/sbin/openvpn3-autoload এ, session-start এর কোনো ফ্ল্যাগ নয়। এটি সেট আপ করার মানে হলো ডিরেক্টরি তৈরি করা, ডেস্ক্রিপ্টর যে নাম আশা করে সেই নামে প্রোফাইল কপি করা, এবং ডেস্ক্রিপ্টর লেখা।

প্রতি-ব্যবহারকারীর সেটআপ এভাবে দেখায়, যে অ্যাকাউন্ট সেশনটির মালিক হবে সেই অ্যাকাউন্টে চালানো হয়। ডিরেক্টরি মোড অন্য স্থানীয় ব্যবহারকারীদের বাইরে রাখে:

mkdir -m700 -p ~/.openvpn3/autoload
cp work.ovpn ~/.openvpn3/autoload/client.conf
$EDITOR ~/.openvpn3/autoload/client.autoload

ডেস্ক্রিপ্টর ক্রেডেনশিয়ালের নাম দেয় এবং স্বয়ংক্রিয় শুরু চায়। পাসওয়ার্ডের মান সংস্করণ নিয়ন্ত্রণের বাইরে রাখুন:

{
  "autostart": true,
  "user-auth": {
    "autologin": true,
    "username": "svc-vpn",
    "password": "change-this-value"
  }
}

তারপর হেল্পারটি একবার চালান এবং সেশনটি দেখা যাচ্ছে কি না নিশ্চিত করুন। দ্বিতীয় কমান্ডটি যাচাই, আরেকটি সেটআপ ধাপ নয়:

/usr/sbin/openvpn3-autoload --directory ~/.openvpn3/autoload
openvpn3 sessions-list

বুটের সময় openvpn3-autoload.service নামের প্যাকেজকৃত ইউনিট সিস্টেম-ব্যাপী ডিরেক্টরি /etc/openvpn3/autoload ব্যবহার করে, প্রতি-ব্যবহারকারীরটি নয়। ওই অবস্থানের জন্য root মালিকানা ও আরও কঠোর মোড দরকার, আর ডেস্ক্রিপ্টর এখনও পাসওয়ার্ড প্লেইন টেক্সটে রাখে। জোড়-ফেরত স্পষ্ট: পাসওয়ার্ড এখন ডিস্কে বসে আছে, তাই ওই ডিরেক্টরিকে গোপন তথ্য হিসেবে দেখুন, হোস্টের বাইরের ব্যাকআপ থেকে বাদ দিন, এবং মানুষ উপস্থিত থাকলে ইন্টারঅ্যাকটিভ পথ বেছে নিন।

পাসওয়ার্ড ব্যর্থতার মতো দেখতে বাস ব্যর্থতা

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

নিচের কমান্ডগুলো দুটিকে আলাদা করে। প্রথমটি জানায় ব্যাকএন্ড চলছে কি না; দ্বিতীয়টি সাম্প্রতিক বাস ত্রুটি দেখায়:

systemctl status openvpn3-service-client
journalctl -b -u openvpn3-service-client --no-pager | tail -20

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

পুরোনো ক্লায়েন্ট যখন এখনও ব্যবহৃত হয়

2.x ক্লায়েন্ট এখনও একটি ক্রেডেনশিয়াল ফাইল গ্রহণ করে, আর একটি কীরিং গোপন তথ্য কখনো ডিস্কে না পৌঁছেই তার প্রম্পটের উত্তর দিতে পারে। একটি র্যাপার এন্ট্রিটি সমাধান করে, তাই ফাইলটি পাসওয়ার্ড নয়, লুকআপের নাম বলে। এই ব্যবস্থা একটি আনলকড কীরিংয়ের উপর নির্ভর করে, যা লগইন সেশনহীন কন্টেইনার বা কেউ সাইন ইন করার আগেই শুরু হওয়া ইউনিট সরবরাহ করতে পারে না। তখন লুকআপ টুলটি এমন একটি সংগ্রহ জানায় যেখানে এটি লিখতে পারে না, ফলে ত্রুটিটি কীরিংয়ের ত্রুটি হলেও ক্রেডেনশিয়াল ত্রুটির মতো দেখায়।

এর কিছু বানানোর আগে দেখুন প্রোফাইলে কোনো keepalive সেটিংস পুনরায় চালুর প্রয়োজনটাই মুছে দেয় কি না। টিকে থাকা সেশন কখনোই আপনি যেটি স্বয়ংক্রিয় করতে চাইছেন সেই প্রম্পটে পৌঁছায় না।