VPN-এর জন্য Linux নেটওয়ার্ক নেমস্পেস: যা তারা বিচ্ছিন্ন করে না

VPN-টি তার নিজের নেমস্পেসের ভিতরে চালু করুন, সেখানে একটি অ্যাপ্লিকেশন চালান, তবুও ট্রাফিক হোস্ট রুট দিয়েই বেরিয়ে যায়। কিছুই ভাঙেনি: নেমস্পেস কেবল তার ভিতরে প্রবেশ করা প্রসেসগুলোকে নিয়ন্ত্রণ করে, আর লিকটি এসেছে এমন একটি প্রসেস থেকে যা কখনও প্রবেশ করেনি। ইন্টারফেস, ঠিকানা, রুট, ফায়ারওয়াল নিয়ম ও সকেট—এগুলোই নেমস্পেসের মালিকানায় থাকে। ফাইল, অ্যাকাউন্ট ও আগে থেকেই চলা সার্ভিসগুলো নয়, আর এখান থেকেই বেশিরভাগ আশ্চর্যের জন্ম।

নেমস্পেস কী মালিকানা রাখে, আর সকেটের জন্ম কোথায়

একটি ইন্টারফেস নেমস্পেসে সরিয়ে নিন, হোস্ট তা হারাবে; ভিতরে একটি টানেল বানান, হোস্ট তা দেখতে পাবে না। এটাই নেমস্পেস-সীমিত VPN-এর কৌশল: ডিভাইসটি এবং তার দিকে নির্দেশ করা রুটগুলো এমন একটি প্রসঙ্গে থাকে যেখানে কেবল বাছাই করা প্রসেসগুলোই পৌঁছাতে পারে। হোস্ট তার ডিফল্ট রুট ধরে রাখে, তাই বাইরের সবকিছু অক্ষত থাকে।

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

নেমস্পেস কী বিচ্ছিন্ন করে না

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

সমাধান হলো /etc/netns/<name>/resolv.conf-এ প্রতি-নেমস্পেস ফাইল, অথবা প্রস্তুত করা ফাইলের একটি bind mount, যা ভিতর থেকে পৌঁছানো যায় এমন রিজলভারের দিকে নির্দেশিত। হোস্টে /etc/resolv.conf সম্পাদনা করলে নেমস্পেস যা দেখে তার কিছুই বদলায় না।

প্রসেস বসানোই হলো নিয়ন্ত্রণ

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

ip netns add vpn1
ip link set wg0 netns vpn1
ip netns exec vpn1 wg show
wg show

নেমস্পেসের ভিতর থেকে প্রথম wg show এবং হোস্ট থেকে দ্বিতীয়টি পড়ুন, আর আশা করুন তাদের একটিই পিয়ারটি তালিকাভুক্ত করবে। দুটোই যদি করে, ডিভাইসটি কখনও সরেনি; কোনোটিই যদি না করে, এটি অন্যত্র গেছে। চালক যখন সার্ভিস ম্যানেজার, তখন unit ফাইলটিই সম্পাদনা করার জিনিস, ডেস্কটপ শর্টকাট নয়। নেমস্পেস সেটিং ছাড়া একটি unit ডেমনটিকে হোস্ট প্রসঙ্গে চালু করে নকশাটি চুপচাপ বাতিল করে দেয়।

অ্যাপ্লিকেশনের প্রসঙ্গ থেকে পরীক্ষা করুন

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

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

ফরওয়ার্ডিং, ব্যর্থতার নীতি ও ক্লিনআপ

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

নেমস্পেসের নাম, ইন্টারফেস এবং কনফিগারেশনের মালিক কে—তা লিখে রাখুন, যাতে ক্লিনআপ কেবল ডিপ্লয়মেন্ট যা তৈরি করেছে তাই সরায়। রোলব্যাকের সময় হোস্ট নেটওয়ার্কিং রিসেট করা ক্লিনআপকে বিভ্রাটে পরিণত করে। network_namespaces(7) পাতাটি ছোট এবং ওই পথের নকশা করার আগে পড়ার মতো।