ইন্টারফেস চালু আছে কিন্তু wg-quick ব্যর্থ: এরপর কী করবেন

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

আংশিক অবস্থাই স্বাভাবিক ব্যর্থতা

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

যা এখনো নেই তা হলো ব্যর্থ ধাপের পরে যা আসে সবকিছু। যদি ব্যর্থতা রিজলভার ধাপে হয়ে থাকে, তাহলে ঠিকানা ও রুট আছে আর DNS নেই। যদি সেটি রুট হয়ে থাকে, টানেলের একটি ঠিকানা আছে কিন্তু তার ভেতর দিয়ে কোনো পথ নেই।

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

প্রথম ব্যর্থ ধাপটি খুঁজুন

শুধু বর্তমান স্ট্যাটাস নয়, ইউনিটের জার্নাল পড়ুন, আর তা ব্যর্থ রানের শুরু থেকে পড়ুন। শেষ লাইনটি আপনাকে এক্সিট কোড বলে; প্রথম ত্রুটিটি বলে কী মেরামত করতে হবে।

এই কমান্ডগুলি ইউনিটের অবস্থা, সেই ইউনিটের বুট জার্নাল এবং টানেলের জীবন্ত অবস্থা দেখায়:

systemctl status wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager | tail -40
wg show
ip -4 addr show dev wg0

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

মেরামত ঠিক করে দেয় এমন তিনটি শর্ত

আপনি পরিষ্কার করছেন, জায়গায় মেরামত করছেন, নাকি ইউনিটটিকে বুট পথ থেকে সরাচ্ছেন — কিছু লেখার আগেই সেটি ঠিক করুন।

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

এই তিনটি ক্ষেত্রেই রহস্যময় লাল ইউনিটের বেশিরভাগটা ঢেকে যায়। পার্থক্য গড়ে দেয় এই প্রশ্ন: পরিষ্কার অবস্থার মেশিনেও কি একই ব্যর্থতা ঘটত, আর উত্তর সাধারণত প্রথম ত্রুটির লাইন থেকেই আসে।

আবার চেষ্টা করার আগে পরিষ্কার করুন

বিদ্যমান অবস্থার ওপর পুনরায় চেষ্টা নতুন কারণে ব্যর্থ হয়ে মূল কারণটি লুকাতে পারে। যে টুলটি ইন্টারফেস তৈরি করেছিল সেই একই টুল দিয়ে এটি নামিয়ে নিন, তারপর নিশ্চিত করুন কিছুই বাকি নেই।

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

ইউনিট নয়, টানেল প্রমাণ করুন

সবুজ ইউনিট মানে স্টার্টআপ অনুক্রম শূন্য দিয়ে বেরিয়েছে। এর মানে নয় যে একটি প্যাকেট অন্য প্রান্তে পৌঁছেছে, আর এর মানে নয় যে রিজলভার আপনি যেভাবে চেয়েছিলেন সেভাবেই সেট হয়েছে।

টানেলের ভেতর দিয়ে একটি অনুরোধ পাঠান এবং যে অবস্থা তা তৈরি করেছিল তা পড়ুন:

systemctl is-active wg-quick@wg0
wg show wg0 latest-handshakes
ping -c 3 10.63.0.1
resolvectl query internal.example.net

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