systemd VPN পরিষেবা বন্ধ করে: ক্লায়েন্টের সঙ্গে Type= মিলান

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

সফলভাবে চালু হওয়ার কয়েক সেকেন্ড পরেই ইউনিট কেন নিষ্ক্রিয় হয়

systemd যে প্রক্রিয়াটি চালু করেছে তার থেকেই অবস্থা অনুমান করে, তাই Type= সেই প্রক্রিয়া সম্পর্কে একটি দাবি, ডকুমেন্টেশন নয়। Type=simple দিয়ে কমান্ড চলাকালীন ইউনিট সক্রিয় গণ্য হয় এবং কমান্ড ফিরে এলে নিষ্ক্রিয় হয়। তাই যে ক্লায়েন্ট সংযোগটি একটি সহায়ক প্রোগ্রামের হাতে দিয়ে বেরিয়ে যায়, সে ক্র্যাশের মতো দেখায়, এমনকি টানেল চালু থাকলেও। এরপর জার্নাল এমন একটি স্টার্ট-স্টপ ধরন দেখায় যা ত্রুটিপূর্ণ বাইনারির মতো পড়া যায়।

নেটওয়ার্ক কনফিগারেশনে হাত দেওয়ার আগে ক্লায়েন্টের আচরণের পাশে ইউনিটের টাইপ পড়ুন।

ক্লায়েন্টের সঙ্গে যে টাইপ মেলে সেটিই বেছে নিন

দুটি ধরন বেশিরভাগ ভেন্ডর CLI ঢেকে দেয়: একটি কমান্ড যা সেশন কনফিগার করে বেরিয়ে যায়, এবং একটি কমান্ড যা ফেরার আগে একটি সহায়ক প্রোগ্রাম ফর্ক করে। প্রত্যেকের জন্য আলাদা ইউনিট আকৃতি দরকার।

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/protonvpn-cli connect -f
ExecStop=/usr/bin/protonvpn-cli disconnect

oneshot এবং RemainAfterExit=true একসঙ্গে কমান্ড ফিরে আসার পরেও ইউনিট সক্রিয় রাখে, যা কনফিগার-করে-বেরোনো ধরনের সঙ্গে মেলে, আর স্টপ কমান্ড পরিষেবাকে পরিষ্কার সমাপ্তি দেয়। ফর্ক করা ক্লায়েন্ট একই আকৃতি ধরে রাখে, তবে systemd যেন সন্তান প্রক্রিয়া অনুসরণ করে সেজন্য Type=forking দরকার। Restart=on-failure, RestartSec=30 এবং একটি সীমাবদ্ধ StartLimitBurst সেট করুন, যাতে প্রদানকারীর ব্যাঘাত ত্রুটিটিকে চাপা দেওয়া পুনরায় চালুর চক্রে পরিণত না হয়।

তত্ত্বাবধানে থাকা ক্লায়েন্টকে ডেমন হয়ে যেতে দেবেন না

systemd-এর বাইরের তত্ত্বাবধায়কেরা একই দেয়ালে ধাক্কা খায়। যে runit রান স্ক্রিপ্ট একটি ডেমন হওয়া ক্লায়েন্ট চালু করে, সেটি সঙ্গে সঙ্গে তত্ত্বাবধায়কের কাছে ফিরে আসে, আর তত্ত্বাবধায়ক সেই প্রত্যাবর্তনকে ক্র্যাশ পড়ে আরেকটি অনুলিপি চালু করে। প্রতিটি তত্ত্বাবধায়ক সামনের প্রক্রিয়াটির মালিকানা আশা করে, যেমন sshd -D সামনে থাকে। তত্ত্বাবধানে থাকা কমান্ডের জন্য ডেমন ফ্ল্যাগ বাদ দিন এবং পেছনের কাজ তত্ত্বাবধায়ককে করতে দিন। যে মোড়ক স্ক্রিপ্ট টানেল তৈরির আগেই ফিরে আসে, সেগুলোও একই বিভ্রান্তি ঘটায়।

যে প্রক্রিয়া নিজেকে বিচ্ছিন্ন করে ফেলে, তাকে দেখার কথা ছিল যা কিছু, তার কাছে সে অদৃশ্য।

সেশন শেষ হয় আর টানেলটিকে সঙ্গে নিয়ে যায়

ডেস্কটপ সেশন যে ক্লায়েন্ট চালু করে তার মালিক। লগইন শেষ করুন, সেশন বাস উধাও হয়, টানেলকে সঙ্গে নিয়ে যায়, আর এতেই বোঝা যায় কেন শেষ জানালা বন্ধ হলে গ্রাফিক্যাল ক্লায়েন্টের সংযোগ প্রায়ই কেটে যায়। সার্ভারের উচিত সিস্টেম ইউনিট বা NetworkManager প্রোফাইল ব্যবহার করা যা নিজে থেকেই ওঠে। ব্যবহারকারী ইউনিট কেবল তখনই যুক্তিযুক্ত যখন টানেল লগইনের সঙ্গে শেষ হওয়ার কথা, তাই এটিকে গ্রাফিক্যাল সেশন টার্গেটের সঙ্গে বাঁধুন এবং বিবরণে তা লিখুন।

পরিষেবা ব্যবহারকারী একই সমস্যার অন্য অর্ধেক। root-এর মালিকানাধীন এবং মোড 0600-এর একটি কী অন্য অ্যাকাউন্টে চলা ইউনিটের কাছে অপাঠ্য, আপনার শেলে sudo যা-ই অর্জন করুক না কেন।

systemctl cat openvpn-server@work
sudo chown -R openvpn:network /etc/openvpn/server
sudo find /etc/openvpn -type f -perm /077 -ls

ঠিকানা তৈরি হওয়ার পরে নির্ভরশীলগুলো সাজান

যখন কোনো ডেমন এমন টানেল ঠিকানায় বাঁধে যা এখনও তৈরি হয়নি, তখন এটি Cannot assign requested address নিয়ে বেরিয়ে যায়। সমাধান হলো স্পষ্ট ক্রমবিন্যাস, পুনরায় চেষ্টার চক্র নয়।

[Unit]
After=network.target [email protected]
Requires=sys-devices-virtual-net-wg0.device

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

তারপর একবার রিবুট করে নিশ্চিত করুন যে টানেল ডিভাইস দেখা দেওয়ার পরে ইউনিট সক্রিয় আছে। কেবল systemctl start দিয়ে যাচাই করা সংশোধন বুট ক্রম পরীক্ষা করেনি, যা ঠিক করার কথা ছিল তার।