নেটওয়ার্ক নেমস্পেসে WireGuard: সকেটটি কেন পিছনে থেকে গেল

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

লক্ষণ: নেমস্পেস ঠিক, কিন্তু প্যাকেট নেই

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

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

এটি সরানোর কোনো ত্রুটি নয়, পিয়ারের ভুল কনফিগারেশনও নয়। কার্নেল বাস্তবায়ন এভাবেই কাজ করে, এবং WireGuard-এর নেমস্পেস নথি সরাসরি তৈরির নিয়মটি বর্ণনা করে।

সকেটের জন্মস্থান কেন আছে

একটি WireGuard ডিভাইস তার এনক্রিপ্টেড পরিবহনের জন্য একটি UDP সকেটের মালিক, এবং সেই সকেট ডিভাইস যেনেমস্পেসে তৈরি হয় সেখানেই খোলে। লিংক কমান্ড দিয়ে ইন্টারফেস সরালে দৃশ্যমান ডিভাইস সরে যায়, কিন্তু পরিবহন যেখানে শুরু হয়েছিল সেখানেই থাকে। তখন দুটি বস্তুর মালিক আলাদা হয়ে যায়।

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

সকেট যেখানে চান সেখানেই এটি তৈরি করুন

সমাধান হলো ডিভাইসটি বাইরে তৈরি করে সরানোর বদলে লক্ষ্য নেমস্পেসের ভেতরেই তৈরি করা। ধরে নিন একটি অনুমোদিত নেমস্পেস আগে থেকেই আছে এবং নামটি অব্যবহৃত:

ip netns exec vpn-apps ip link add wg-demo type wireguard
ip netns exec vpn-apps wg show

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

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

পথের দুই দিক পড়ুন

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

ip netns exec vpn-apps ip route get 10.30.0.9
ip netns exec vpn-apps wg show
tcpdump -ni any udp port 51820

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

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