OpenVPN চালু হচ্ছে না: কনফিগ নয়, প্রথম লাইনটি পড়ুন

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

তিনটি কেবল-পঠনযোগ্য কমান্ড আপনাকে সেখানে নিয়ে যায়: প্রথমে journalctl -u openvpn@server -b --no-pager, তারপর systemctl status openvpn@server, আর UDP লিসেনার ও তাদের মালিকদের জন্য ss -lunp।

প্রথম লাইনই শাখা বেছে নেয়

পোর্ট দ্বন্দ্ব এবং অনুপস্থিত বাইনারি—দুটিই এক সেকেন্ডের মধ্যে চালু হওয়া থামিয়ে দেয়, আর দুটিই ভিন্ন প্রথম লাইন রেখে যায়। ঠিকানা ইতিমধ্যে ব্যবহৃত—এমন বার্তা পোর্টের নাম বলে; অনুপস্থিত এক্সিকিউটেবল এমন একটি পাথের নাম বলে যা আর নেই; ব্যর্থ শর্ত বা অনুপস্থিত কনফিগ ফাইল ফাইলটির নাম বলে। এই তিনটি ভিন্ন ভিন্ন মেরামতে নিয়ে যায়, আর কোনোটিই ক্লায়েন্ট পুনঃস্থাপনে ভালো হয় না। অন্য কিছু চালানোর আগে প্রথম ব্যর্থতাটি আপনার নোটে কপি করুন।

মূল লাইনটি লুকিয়ে রাখা পুনঃচেষ্টার লুপের দিকে খেয়াল রাখুন। রিস্টার্ট নীতি থাকা একটি ইউনিট প্রথম ব্যর্থতাকে ডজনখানেক অভিন্ন ব্যর্থতার নিচে চাপা দিতে পারে, তাই ইউনিট দিয়ে ফিল্টার করে ওপর থেকে পড়া journalctl -b লেজের চেয়ে ভালো।

আর কে 1194 পোর্ট ধরে আছে

দোষী সাধারণত কেউ সচেতনভাবে কনফিগ করা দ্বিতীয় সার্ভার নয়। আশা করুন অন্য টার্মিনালে এখনো জীবিত হাতে চালানো ক্লায়েন্ট, একই পোর্ট বেছে নেওয়া দ্বিতীয় প্রোফাইল, বা এমন ভেন্ডর বান্ডল যার নিজের টানেল 1194 ধরে আছে। সকেটের মালিক ss -lunp-এ দেখা যায়; ইউনিট দায়ী কি না জানতে ওই PID systemctl status-এ দিন। সিগন্যাল দিয়ে নয়, তার নিজের নিয়ন্ত্রণ পথ দিয়ে এটি নামান।

ইউনিট-পরিচালিত প্রসেসে সিগন্যাল সাধারণত রিস্টার্ট ঘটায়, আর একই ব্যর্থতা মুহূর্ত পরে নতুন সমস্যার মতো ফিরে আসে। ইউনিটের জন্য systemctl stop, ভেন্ডর ইনস্টলের জন্য বান্ডলের নিজের সার্ভিস কমান্ড, আর সিগন্যাল কেবল ওই শেলে হাতে চালানো কিছুর জন্য ব্যবহার করুন।

পার্জের পরে পড়ে থাকা ইউনিট

পার্জ বাইনারি মুছে দেয়; হাতে লেখা ইউনিট ফাইল, সাধারণত /etc/systemd/system-এর নিচে, তা থেকে বেঁচে যায়। তারপর Systemd এমন ইউনিট আবার চেষ্টা করে যা আর নেই এমন পাথের দিকে ইঙ্গিত করে, আর বার্তাটি গতকালের অপসারণ নয়, ওই অনুপস্থিত ফাইল নিয়ে। systemctl status ইউনিটের ফ্র্যাগমেন্ট পাথ ওপরের দিকে দেখায়, তাই কিছু মুছার আগে dpkg -S দিয়ে তা যাচাই করুন। অনাথটি চলে গেলে systemctl daemon-reload ও systemctl reset-failed অবস্থা পরিষ্কার করে; নাহলে পরবর্তী প্রতিটি স্টেটাস চেক তা উত্তরাধিকারসূত্রে পায়।

যখন which openvpn /usr/local-এর নিচের কিছু উত্তর দেয়, তখন ব্যবহৃত বাইনারিটি apt থেকে নয়, ভেন্ডর ইনস্টলার থেকে এসেছে। এমন ইনস্টলার সাধারণত নিজের লিসেনার, নিজের বুট এন্ট্রি ও নিজের কনফিগ ডিরেক্টরি নিয়ে আসে, তাই দৃশ্যমান কমান্ড মুছে দিলেও সকেট দখলেই থাকে।

ভেন্ডর যা নথিভুক্ত করে সেইভাবে এটি আনইনস্টল করুন, ss -lunp দিয়ে পোর্ট মুক্ত কিনা নিশ্চিত করুন, আর প্রয়োজন হলেই ডিস্ট্রিবিউশন ক্লায়েন্ট যোগ করুন।

আবার চেষ্টার আগে অবস্থা ঠিক করুন

এটি থেকে সিদ্ধান্তে পৌঁছানোর আগে ব্যর্থ অবস্থাটি পরিষ্কার করুন: systemctl reset-failed কাউন্টারগুলো সরায়, আর systemctl status তখন ইউনিটের ইতিহাস নয়, বর্তমান অবস্থা জানায়। একবার চালু করুন এবং বাক্সের সমষ্টিগত অবস্থা নয়, ওই দৃষ্টান্তের নিজের জার্নাল পড়ুন। টানেল কিছু না বহন করলেও সক্রিয় বলে জানানো ইউনিট আলাদা সমস্যা, এবং অনেক বেশি সাধারণ। দুটিই বাগ রিপোর্টে মিলে যায়, কারণ দুটিই ব্যবহারকারীর «VPN কাজ করছে না» বলে শেষ হয়।

আপনি যে শাখা নিয়েছেন তা টুকে রাখুন: পোর্ট দ্বন্দ্ব, অনুপস্থিত বাইনারি, অনুপস্থিত কনফিগ। পরেরবার চিনতে দ্রুত হবে।