পুনরায় চালু করার পর মুছে ফেলা WireGuard peer কেন ফিরে আসে

পরিচয়টি চলমান ইন্টারফেস থেকে উধাও হয়ে যায় এবং পরিবর্তনটি সম্পূর্ণ মনে হয়। সার্ভিস পুনরায় চালু হওয়ার পর তা ফিরে আসে, যা দেখে মনে হয় WireGuard কমান্ডটি উপেক্ষা করছে। আসলে যা ঘটেছে তা আরও সরল: বুটের কনফিগারেশনটিতে এখনও peer-টি রয়েছে।

দুটি অবস্থা ওই তালিকাটি ধরে রাখে। কেবল যখন দুটিই তা হারায়, তখনই প্রত্যাহার সত্যিকারের হয়।

wg set আসলে কী বদলায়

wg set wg0 peer <public-key> remove কমান্ডটি কার্নেলের ভিতরে চলমান ইন্টারফেসটি সম্পাদনা করে। এটি ডিস্কে কিছু লেখে না। কনফিগারেশন ফাইল, NetworkManager প্রোফাইল বা রাউটারের সংরক্ষিত অবস্থা অপরিবর্তিত থাকে। এটি নকশা, কোনো ত্রুটি নয়।

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

তাই পরের পুনরায় চালু হওয়ার সময় peer-টি ফিরে আসে, এবং নিজের মূল অনুমোদিত প্রিফিক্সগুলো নিয়েই ফিরে আসে। এর মধ্য দিয়ে রুট করা যেকোনো কিছুও আবার তৈরি হয়। ফলে প্রত্যাহৃত বলে ধরা একটি পরিচয় পুনরায় লোডের পর তার পুরনো গন্তব্যগুলোতে পৌঁছাতে পারে। রানটাইম আউটপুটে কেউ কোনো সতর্কবার্তা পায়নি।

ফাইল সম্পাদনার আগে লেখককে খুঁজুন

ইন্টারফেসটির একটি মালিক আছে। সেটি ফাইল পড়া wg-quick হতে পারে, প্রোফাইল প্রয়োগ করা NetworkManager, রাউটারের নিজস্ব ইন্টারফেস কনফিগারেশন, কিংবা কোনও কনটেইনার এন্ট্রিপয়েন্ট যা শুরুতে ইন্টারফেসটি আবার তৈরি করে। যে ফাইল মালিক কখনও পড়ে না, তা সম্পাদনা করলে কোনো স্থায়ী পরিবর্তন হয় না।

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

wg show wg0 peers
wg show wg0 allowed-ips
systemctl status wg-quick@wg0 --no-pager
ls -l /etc/wireguard

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

SaveConfig ফাঁদ

wg-quick একটি বাঁক যোগ করে যা হাতে ফাইল সম্পাদনাকারীদের ধরে ফেলে। SaveConfig চালু থাকলে এর নথিভুক্ত শাটডাউন আচরণ বর্তমান রানটাইম অবস্থাটি কনফিগারেশন ফাইলের ওপরে লেখে।

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

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

দুটি অবস্থাই বদলান, তারপর পুনরায় লোড করুন

রানটাইমে কী দিয়ে peer-টি সরান। সংরক্ষিত কনফিগারেশনে একই ব্লকটি মালিকের সমর্থিত অপারেশনের মাধ্যমে সরান, চারপাশে সম্পাদনা করে নয়।

তারপর peer-টি কী বহন করত তা পর্যালোচনা করুন। প্রত্যাহৃত পরিচয়ের অধীন একটি রুট করা নেটওয়ার্ক ইচ্ছাকৃতভাবে পুনরায় বরাদ্দ বা সরানো উচিত, পরের সম্পাদিত peer দ্বারা নীরবে উত্তরাধিকারসূত্রে পাওয়া উচিত নয়।

গেটওয়ে যদি আপনার প্রশাসনিক প্রবেশাধিকারও বহন করে, তবে একটি পুনরুদ্ধার পথ খোলা রাখুন। ভুল peer সরানো একটি পুনরায় চালু নিজেই তৈরি করা বিভ্রাট। ভুল রুট সরানো পুনরায় চালুর ক্ষেত্রেও একই কথা প্রযোজ্য।

সফল পরীক্ষা কেমন দেখায়

সার্ভিসটি পুনরায় লোড বা চালু করুন, তারপর peer তালিকাটি আবার পড়ুন। পুরনো কী অনুপস্থিত থাকতে হবে, আর যে peer-গুলো আপনি রাখতে চেয়েছিলেন সেগুলো উপস্থিত ও কার্যকর থাকতে হবে।

wg show wg0 peers
wg show wg0 allowed-ips
sudo wg-quick down wg0 && sudo wg-quick up wg0
wg show wg0 peers

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

কোনো ম্যানেজার যদি peer-টি বারবার ফিরিয়ে আনে, তবে নিম্নস্তরের সরানো পুনরাবৃত্তি করা বন্ধ করুন। ওই লেখক যে ইনভেন্টরি পড়ে তা ঠিক করুন, কারণ ততক্ষণ পর্যন্ত প্রতিটি পুনরায় চালু পরিচয়টির আবার আবির্ভাবের আরেকটি আমন্ত্রণ।