রিবুটের পরে VPN সার্ভারের পুনরুদ্ধার পরীক্ষা: প্রথমে কী দেখবেন

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

চার মালিক, চারটি ভিন্ন পরীক্ষা

রিস্টার্টের আগে ঠিক করুন টানেলটি ফিরিয়ে আনার কথা কার। আপনি যে পরীক্ষা চালান এবং যে সমাধান প্রয়োগ করেন, দুটোই সেই উত্তরের ওপর নির্ভর করে, আর সাধারণত চার ধরনের মালিক থাকে: VPN ডেমনের জন্য একটি systemd unit, WireGuard ইন্টারফেসের জন্য একটি wg-quick ইনস্ট্যান্স unit, একটি কন্টেইনার রানটাইম, অথবা একটি নেটওয়ার্ক ম্যানেজার প্রোফাইল। মালিকের নাম বলতে না পারলে থামুন এবং সেটি খুঁজুন, কারণ প্রত্যাশিত স্টার্টআপ পথ ছাড়া রিবুট পরীক্ষা কেবল বলে যে কিছু একটা ঘটেছে।

প্রতিটি মালিক তার কনফিগারেশন ভিন্ন জায়গায় রাখে। systemd-পরিচালিত OpenVPN সার্ভার চালু হওয়ার সময় তার কনফিগারেশন পড়ে, তাই বুটের সময় ফাইলে যা থাকে তাই চলে। wg-quick ইন্টারফেস একই ফাইল থেকে তার ঠিকানা, রুট ও DNS নেয়, অর্থাৎ শেল থেকে হাতে তোলা এবং কখনো unit হিসেবে চালু না করা ইন্টারফেস ফিরে আসবে না। কন্টেইনার তার এন্ট্রিপয়েন্ট ফিরিয়ে আনে, কিন্তু হোস্টের ফায়ারওয়াল পরিবর্তন নয়, যদি না সেগুলো কন্টেইনারের বাইরে থাকে।

আগে বেসলাইন, নইলে ফলাফলের কোনো অর্থ নেই

কাজ করার সময়কার অবস্থাটি লিখে রাখুন: টানেলে ঠিকানা, ক্লায়েন্ট সাবনেটের রুট, NAT বা ফরওয়ার্ডিং নিয়ম, লিসেনার সকেট এবং ফরওয়ার্ডিং sysctl। ip addr show wg0, ip route, nft list ruleset বা iptables-save, ss -lunp এবং sysctl net.ipv4.ip_forward বেশিরভাগ হোস্টে যথেষ্ট।

সার্ভিসটি চালু আছে শুধু তা নয়, বরং এটি কীভাবে চালু হওয়ার জন্য কনফিগার করা আছে তা লিখুন। systemctl is-enabled wg-quick@wg0 এবং systemctl is-active wg-quick@wg0 ভিন্ন প্রশ্নের উত্তর দেয়, এবং বুটের সময় গুরুত্বপূর্ণ হলো সক্রিয়কৃত অবস্থা, যেমনটি systemctl(1)-এ বর্ণিত। OpenVPN-এর ক্ষেত্রে দেখুন হোস্টটি কোন টেমপ্লেট ব্যবহার করে, কারণ openvpn@server এবং openvpn-server@server ভিন্ন ডিফল্টসহ ভিন্ন unit।

রিস্টার্ট চালান এবং প্রথম ব্যর্থতা পড়ুন

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

টানেল ব্যবহারের অযোগ্য থাকলেও ডেমন সক্রিয় থাকতে পারে, এবং এটিই সবচেয়ে সাধারণ ভুল পাস। unit যদি network-online.target-এর বদলে কেবল network.target-এর জন্য অপেক্ষা করে, তবে নেটওয়ার্ক অনলাইন হওয়ার আগেই স্টার্টআপ শেষ হতে পারে। সার্টিফিকেট, কী বা CRL-এর মতো উল্লিখিত ফাইল সেই মুহূর্তে পাঠযোগ্য নাও হতে পারে, কারণ একটি মাউন্ট বা সিক্রেটের পথ এখনো প্রস্তুত নয়। unit-এর জার্নাল না পড়া পর্যন্ত কোনো সমস্যাই systemctl status-এ দেখা যায় না।

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

আপনার সমাধান নির্ধারণকারী তিনটি শর্ত

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

সেটিং যার মালিকানায়, সেখানেই সমাধান করুন। ফরওয়ার্ডিং একটি sysctl drop-in-এ রাখুন, NAT নিয়ম বুটে লোড হওয়া রুলসেটে রাখুন, unit চালু করার বদলে সক্রিয় করুন, এবং সিক্রেট এমন পথে রাখুন যা unit চালু হওয়ার আগেই আছে। unit-এ ঘুম যোগ করা নির্ভরতা ঘোষণা না করে লুকিয়ে ফেলে।

runbook-এ ফলাফল লিখুন

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

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