OpenVPN কোনো ত্রুটি ছাড়াই চালু হচ্ছে না? জার্নাল দেখুন

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

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

নীরবতার অর্থ আপনি সঠিক চ্যানেল দেখছিলেন না

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

systemctl status openvpn-client@office
journalctl -u openvpn-client@office -b --no-pager

যোগ করুন systemctl show -p Result -p ExecMainStatus openvpn-client@office একটি পরিষ্কার প্রস্থানকে সিগন্যাল থেকে আলাদা করতে। 1 অবস্থা এবং Result=exit-code একটি প্রোগ্রামের সিদ্ধান্ত; Result=signal বা একটি টাইমআউট বরং পরিবেশের দিকে ইঙ্গিত করে, এবং প্রোফাইল সম্পাদনার কোনো পরিমাণই তা বদলাবে না। কিছু পুনরায় চালু করার আগে উভয় মান লিখে রাখুন, কারণ পুনরায় চালু করা সেই ক্ষণস্থায়ী অবস্থা মুছে দেয় যা সেগুলো তৈরি করেছিল।

ইনস্ট্যান্সের নাম পথের অংশ

প্যাকেজকৃত টেমপ্লেট ইউনিট কোনো ফাইল পথ নেয় না। এটি একটি ইনস্ট্যান্সের নাম নেয়, এবং সেই নামটি প্রোফাইল খুঁজে পেতে একটি ডিরেক্টরিতে যোগ করা হয়: office এভাবে সমাধান হয় /etc/openvpn/client/office.conf Debian ও Ubuntu প্যাকেজিংয়ে। office-v2.conf নামের একটি ফাইল @office হিসেবে চালু করা হলে কখনো পড়া হয় না, এবং ইউনিটটি চুপচাপ বেরিয়ে যায় কারণ তার দৃষ্টিকোণ থেকে করার কিছু ছিল না। সন্ধানকারী ডিরেক্টরিটি ক্লায়েন্ট ও সার্ভার মোডে আলাদা, তাই টেমপ্লেট বদলালে একই ভুল সম্পূর্ণ ভিন্ন জায়গায় ইঙ্গিত করে।

এই অসঙ্গতিই নীরব ব্যর্থতার সবচেয়ে সাধারণ উৎস, এবং এটি প্রোফাইলে অদৃশ্য কারণ প্রোফাইলটি ঠিক আছে। আসলে কী আছে তা তালিকাভুক্ত করুন এবং দুটি নাম অক্ষর ধরে ধরে তুলনা করুন, প্যাকেজিং যে এক্সটেনশন আশা করে তা সহ।

ls -l /etc/openvpn/client/
systemctl list-units 'openvpn*' --all

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

যখন প্লাগইন টানেলের মালিক, টার্মিনাল কিছুই দেখে না

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

এটির মালিক যে সার্ভিস তার জন্য জার্নাল অনুসন্ধান করুন, তারপর আপনি পড়তে পারেন এমন বিস্তারিত মাত্রায় পার্সটি পুনরুৎপাদন করুন। নিচের দুটি কমান্ড একই ব্যর্থতার ভিন্ন ভিন্ন মালিকের দিকে তাকায়।

journalctl -b -u NetworkManager --no-pager | grep -i -A3 openvpn
openvpn --config /etc/openvpn/client/office.conf --verb 4 --log /tmp/ovpn.log

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

দুটি বাইনারি, একটি PATH

হাতে তৈরি একটি বিল্ড যা /usr/local এর অধীনে ইনস্টল করা, শেল আহ্বানে জয়ী হয়, কারণ /usr/local/sbin এর আগে আসে /usr/sbin ডিফল্ট Ubuntu PATH-এ। একটি ইউনিট আপনার PATH ব্যবহার করে না; এটি ExecStart এ লেখা পরম পথটি চালায়। তাই আপনার টার্মিনালে কাজ করা সংস্করণ এবং সার্ভিস হিসেবে ব্যর্থ হওয়া সংস্করণ সত্যিই ভিন্ন প্রোগ্রাম হতে পারে।

কিছু পুনর্নির্মাণ করার আগে দুটির তুলনা করুন। তৃতীয় কমান্ডটিই যুক্তিটি নির্ধারণ করে।

command -v openvpn
whereis openvpn
systemctl cat openvpn-client@office | grep ExecStart

আরও একটি পরিবেশগত পার্থক্য একই জায়গায় লুকিয়ে আছে। একটি প্যাকেজকৃত ইউনিট /run এর অধীনে systemd যে রানটাইম ডিরেক্টরি তৈরি করে তার উপর নির্ভর করে; সেই সেটিংটি বাদ দেওয়া হাতে লেখা প্রতিস্থাপন ইউনিট একটি ফাইল খোলার আগেই ব্যর্থ হতে পারে, এবং ব্যর্থতাটি OpenVPN বার্তা ছাড়া একটি সাধারণ প্রত্যাখ্যানের মতো দেখায়।

যে ব্যর্থতাগুলো ক্লায়েন্ট জানাতে পারে না

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

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

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