WireGuard: সাবনেট পরিবর্তনের পর পিয়ারে রুট নেই — দুইটি উপায়
সাবনেট পরিবর্তন WireGuard-কে দুই জায়গায় ভাঙে: AllowedIPs এবং ফেরার পথ। জায়গায় নম্বর বদলানোর সঙ্গে ইন্টারফেস পুনর্নির্মাণ তুলনা করুন।
wg show-তে হ্যান্ডশেক টাটকা, এন্ডপয়েন্ট ঠিক, কী কখনো বদলায়নি — তবুও ping বলছে পিয়ারে রুট নেই। এক ঘণ্টা আগে আপনি টানেলের সাবনেট বদলেছেন। এই লক্ষণ কী-এর সমস্যা নয়, প্রিফিক্সের অমিলের চিহ্ন: WireGuard হ্যান্ডশেক সম্পন্ন করেছে, তারপর ডেটা ফেলে দিয়েছে কারণ সোর্স ঠিকানা আর গ্রহণকারী পিয়ার যা মেনে নেবে তার সঙ্গে মেলে না। সাবনেট পরিবর্তন আনতে দুইটি যুক্তিসঙ্গত উপায় আছে, আর তারা ভিন্ন ভিন্ন জায়গায় ব্যর্থ হয়।
পরিবর্তন আনার দুই উপায়, এবং প্রতিটির দাম
বিকল্প A হলো জায়গায় নম্বর বদলানো: ইন্টারফেস ঠিকানা, পিয়ার রেঞ্জ, রুট এবং কনফিগের প্রতিটি কপি সম্পাদনা করে রিলোড করা। বিকল্প B হলো পুরোনোটির পাশে নতুন প্রিফিক্সে দ্বিতীয় ইন্টারফেস তৈরি করা, পিয়ারগুলো সরানো, এবং ট্রাফিক সত্যিই সরে যাওয়ার পর পুরোনো ইন্টারফেসটি সরিয়ে ফেলা।
| A: renumber in place | B: parallel interface | |
|---|---|---|
| Downtime | The reload window, per host | None if peers are added to both |
| Rollback | Re-apply the previous files | Point peers back at the old interface |
| Risk | Half-applied change: new address, old ranges | Two live interfaces with overlapping intent |
| Effort | Small, if the deployment has one owner | Higher, and needs a cleanup step |
| Fits | Two or three peers you control | Many peers, remote sites, or no maintenance window |
আধা-প্রয়োগ করা অবস্থাই বিকল্প A-কে বিপজ্জনক করে, কারণ এটি ভাঙা দেখায় না। ইন্টারফেস উঠে আসে, হ্যান্ডশেক সফল হয়, আর কেবল ডেটা পথ ব্যর্থ হয়। বিকল্প B বেশি পরিশ্রম চায় কিন্তু প্রতিটি রেফারেন্স খুঁজে বের করার সময় একটি কার্যকর পথ বাঁচিয়ে রাখে।
আপনার প্রান্তে কী কী একসঙ্গে সরাতে হবে
স্থানীয় হোস্টে চারটি জিনিস একই সাবনেট বর্ণনা করে, আর একটির পরিবর্তন মানে সবগুলোর পরিবর্তন: ইন্টারফেসের ঠিকানা, প্রতিটি পিয়ারের AllowedIPs, সিস্টেম ওই গন্তব্যগুলোর জন্য যে রুট ব্যবহার করে, এবং ম্যানেজার আপনার হয়ে যা ইনস্টল করে। wg-quick-এর সঙ্গে শেষ দুটি প্রতিবার ইন্টারফেস ওঠার সময় কনফিগ থেকে তৈরি হয়, তাই পুরোনো কপি চুপচাপ পুরোনো প্রিফিক্স আবার বসিয়ে দেয়।
কোনোটিকে বিশ্বাস না করে কনফিগার করা আর লাইভ যা চলছে তা তুলনা করুন:
wg show
wg showconf wg0
ip addr show wg0
ip route get 10.90.0.5রুট লুকআপই সেই ধাপ যা মানুষ এড়িয়ে যায়। এটি বলে দেয় কার্নেল কোনো গন্তব্যের জন্য আসলে কী করবে, যার মধ্যে ম্যানেজার বা কন্টেইনার রানটাইম ফেলে রাখা আরও নির্দিষ্ট রুটও থাকে। যদি এটি টানেলের চেয়ে ভিন্ন ইন্টারফেস দেখায়, তবে কনফিগ সমস্যা নয়।
চালু ইন্টারফেসের জন্য টানেল না ভেঙে সম্পাদিত ফাইলটি প্রয়োগ করুন:
wg syncconf wg0 <(wg-quick strip wg0)এটি পিয়ার ও রেঞ্জ জায়গাতেই হালনাগাদ করে। এটি ইন্টারফেস ঠিকানা বা রুট হালনাগাদ করে না, কারণ সেগুলো WireGuard সেটিং নয় — তাই নম্বর বদলানোর জন্য এখনো ইন্টারফেস পুনরায় তৈরি বা ip দিয়ে ঠিকানা বদলানো, তারপর রাউটিং আবার যাচাই করা দরকার।
দূর প্রান্তে কী কী একসঙ্গে সরাতে হবে
এখানেই সাধারণত সাবনেট পরিবর্তন মরে যায়। AllowedIPs কেবল রাউটিং ইঙ্গিত নয়; এটি সেই সোর্স ঠিকানাগুলোর তালিকাও, যা একটি পিয়ার উপস্থাপন করতে পারে। যখন আপনি ক্লায়েন্টদের নম্বর বদলান আর সার্ভারের AllowedIPs পুরোনো প্রিফিক্সে রেখে দেন, সার্ভার হ্যান্ডশেক মেনে নেয়, এনক্রিপ্টেড প্যাকেট পায়, আর সেগুলো ফেলে দেয় কারণ ভেতরের সোর্স ওই পিয়ারের সঙ্গে যুক্ত কোনো রেঞ্জের সঙ্গে মেলে না। কোনো ত্রুটি লগ হয় না, আর ক্লায়েন্ট টাইমআউট দেখে।
তাই গ্রহণকারী প্রান্ত সচেতনভাবে হালনাগাদ করুন: সার্ভারে পিয়ার এন্ট্রিতে নতুন ক্লায়েন্ট প্রিফিক্স থাকতে হবে, সার্ভারের নিজের ফেরার রুট ওই প্রিফিক্সের জন্য টানেলে নির্দেশ করতে হবে, আর সার্ভারের পেছনের যেকোনো ডাউনস্ট্রিম নেটওয়ার্ককে নতুন পথ শিখতে হবে। পুরোনো রেঞ্জের নাম বলা ফায়ারওয়াল নীতিরও একই চিকিৎসা দরকার, এবং সোর্স-ভিত্তিক নির্বাচন করা যেকোনো কিছুরও।
দুই ব্যর্থতা আলাদা করার ডায়াগনস্টিক সস্তা। সাম্প্রতিক হ্যান্ডশেক কিন্তু ডেটা নেই মানে টানেল চালু আর ভেতরের অ্যাড্রেসিং মিলছে না। একেবারেই হ্যান্ডশেক না থাকলে আপনি পৌঁছানোর ক্ষমতা বা কী দেখছেন। প্রিফিক্স সমস্যার জন্য কী ঘোরাবেন না; এতে যে একটি জিনিস কাজ করছিল সেটিই রিসেট হয়।
আপনার সম্পাদনার পরেও টিকে থাকা পুরোনো কপি
ফাইল সম্পাদনা করা চালু সিস্টেম বদলানোর সমান নয়, আর কপির সংখ্যা মানুষের প্রত্যাশার চেয়ে বেশি: ইন্টারফেসের মালিক যে ইউনিট বা ম্যানেজার, অন্য ডিরেক্টরিতে একই নামের দ্বিতীয় প্রোফাইল, ইমেজের ভেতরে কনফিগ বেক করা একটি কন্টেইনার, নিজের সম্পাদিত সংস্করণ ধরে রাখা রাউটার UI, আর চালু হওয়ার সময় সংরক্ষিত টানেল আবার আমদানি করা ক্লায়েন্ট অ্যাপ। আপনার পরিবর্তন সম্পূর্ণ দেখানোর পরেও প্রত্যেকটি পুরোনো প্রিফিক্স ফিরিয়ে আনতে পারে।
নামও ভ্রমণ করে। সংখ্যাগত রুট কাজ করলে কিন্তু হোস্টনেম ব্যর্থ হলে, একটি অভ্যন্তরীণ DNS রেকর্ড বা সেবা কনফিগ এখনো পুরোনো টানেল ঠিকানায় নির্দেশ করে। প্রতিটি পিয়ার রেঞ্জ চওড়া করার বদলে রেফারেন্সটি ঠিক করুন, কারণ তাতে আসল সমস্যা ঢাকা পড়ত আর একইসঙ্গে সোর্স ACL বড় হতো।
কাজ করার সময় একটি পুনরুদ্ধার পথ খোলা রাখুন: হোস্টে ঢোকার দ্বিতীয় উপায়, সিরিয়াল কনসোল, বা কনফিগ ফাইলগুলোর নির্ধারিত রোলব্যাক। যে টানেল পরিবর্তন আপনাকে আপনি যে মেশিনটি বদলাচ্ছেন তা থেকেই লক আউট করে, এই কাজটিকে সন্ধ্যায় পরিণত করার সবচেয়ে সাধারণ উপায় সেটিই।
দুটির মধ্যে বাছাই, আর কাট যাচাই
A বাছুন যখন প্রতিটি পিয়ার আপনার, সংখ্যা কম, আর অল্প বিরতি গ্রহণযোগ্য। B বাছুন যখন পিয়ারগুলো দূরের হাত যাদের আপনি নিয়ন্ত্রণ করেন না, যখন সাইট-টু-সাইট লিঙ্ক চালু থাকতে হবে, বা যখন প্রতিটি কপি এক পাসে হালনাগাদ হবে তা নিশ্চিত করতে পারেন না। সেক্ষেত্রে নতুন প্রিফিক্স দুই ইন্টারফেসেই যোগ করুন, পিয়ারগুলো একবারে একটি করে সরান, নতুনটিতে ট্রাফিক দেখুন, তারপরেই পুরোনো ইন্টারফেস ও তার রুট সরান।
যেকোনো বিকল্পে পরিবর্তন শেষ হয় যখন চারটি যাচাই পাস করে: হ্যান্ডশেক সাম্প্রতিক, নতুন প্রিফিক্সের গন্তব্যের রুট লুকআপ টানেলের নাম বলে, কয়েকশ বাইটের পেলোড দুই দিকেই যায়, এবং হোস্ট বা ম্যানেজার রিস্টার্টের পরেও একই থাকে। এর জন্য wg(8) ম্যানুয়াল প্রতিটি দিকে AllowedIPs-এর অর্থ কী তার রেফারেন্স, আর উপসর্গ মিটিয়ে দেওয়ার জন্য রেঞ্জ চওড়া করার আগে এটি আবার পড়া উচিত।
- হ্যান্ডশেক সাম্প্রতিক আর ডেটা নেই: কী ছোঁয়ার আগে গ্রহণকারীর AllowedIPs দেখুন।
- রুট লুকআপ ভুল ইন্টারফেস দেখাচ্ছে: রুটের মালিক ম্যানেজার বা কন্টেইনার, আপনার ফাইল নয়।
- সংখ্যাগত ঠিকানা ঠিক আর হোস্টনেম ভাঙা: পুরোনো রেফারেন্স, রাউটিং লুপ নয়।
- পরিবর্তন সম্পূর্ণ কেবল তখনই যখন রিস্টার্টের পরেও নতুন প্রিফিক্স ব্যবহৃত হয়।