একটি Linux প্রসেস কীভাবে WireGuard টানেলের বাইরে চালাবেন

রাউট সম্পাদনা করে কোনো প্রোগ্রামকে পূর্ণ-টানেল WireGuard হোস্ট থেকে ছাড় দেওয়া যায় না। রাউট গন্তব্য অনুযায়ী পথ বেছে নেয়, আর আপনি ছাড় দিতে চান একটি প্রসেসকে, তাই কার্নেলের মেলানোর মতো কিছু থাকে না। কাজের উপায় হলো সেই প্রসেসকে তার নিজস্ব নেটওয়ার্ক প্রসঙ্গ দেওয়া: নিজস্ব ইন্টারফেস, ঠিকানা ও ডিফল্ট রাউটসহ একটি নেমস্পেস, যা veth জোড়া দিয়ে হোস্টের সঙ্গে যুক্ত। আমি এটি Ubuntu 24.04-এ wireguard-tools 1.0.20210914 দিয়ে চালিয়েছি, এবং নেমস্পেস কখনোই সমস্যা ছিল না — সমস্যা ছিল হোস্টের ফরওয়ার্ডিং নীতি ও টানেলের মার্কিং নিয়ম।

প্রথমে আপনার কোন ধরনের প্রসঙ্গ দরকার তা বেছে নিন

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

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

যদি দাবিটি সত্যিই হয় যে টানেল থেকে কিছুই বেরোবে না, তবে বরং টানেলটি বন্ধ করুন। নেমস্পেস আছে মিশ্র ক্ষেত্রের জন্য: একটি প্রোগ্রাম বাইরে, বাকি সব ভেতরে, একই মেশিনে, একই সময়ে।

দ্বিতীয় প্রসঙ্গ তৈরি করুন এবং হোস্টের সঙ্গে যুক্ত করুন

একটি নমুনা বিন্যাস: হোস্টে ডিফল্ট রাউট বহনকারী একটি WireGuard ইন্টারফেস আছে, এবংclearnet নামের একটি নেটওয়ার্ক নেমস্পেস, যা veth জোড়া দিয়ে হোস্টের সঙ্গে যুক্ত। নিচের ঠিকানাগুলো উদাহরণ।

ip netns add clearnet
ip link add veth-clear-out type veth peer name veth-clear-in
ip addr add 192.168.100.1/24 dev veth-clear-out
ip link set veth-clear-out up
ip link set veth-clear-in netns clearnet
ip netns exec clearnet ip addr add 192.168.100.2/24 dev veth-clear-in
ip netns exec clearnet ip link set veth-clear-in up
ip netns exec clearnet ip route add default via 192.168.100.1

এই নেমস্পেস এখন হোস্টে পৌঁছাতে পারে আর অন্য কোথাও নয়। হোস্টকে ট্রাফিক ফরওয়ার্ড করতে হবে এবং উৎস ঠিকানা পুনর্লিখন করতে হবে, কারণ 192.168.100.0/24 ব্যক্তিগত এবং আপস্ট্রিম রাউটারের সেখানে ফেরার কোনো রাউট নেই:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o <wan-interface> -j MASQUERADE

আরও এগোনোর আগে নেমস্পেসের দিকটি নিশ্চিত করুন।ip netns exec clearnet ip route veth রাউট এবং 192.168.100.1 দিয়ে ডিফল্ট রাউট দেখানো উচিত, আর ওই ঠিকানায় ping-এর উত্তর আসা উচিত। যদি হোস্ট ঠিকানায় ping ব্যর্থ হয়, তবে ঠিকানা বা লিঙ্কের অবস্থা ভুল এবং কোনো ফায়ারওয়াল নিয়মই কাজে আসবে না।

নাম রিজলভ হয় কিন্তু কিছু ফিরে না এলে FORWARD পড়ুন

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

কিছু যোগ করার আগে চেইনটি পড়ুন:

iptables -S FORWARD
nft list chain inet filter forward

তারপর উভয় দিকে ট্রাফিক অনুমোদন করুন, কাউন্টারসহ, যাতে বোঝা যায় নিয়মটি কখনো মিলেছিল কি না:

iptables -A FORWARD -i veth-clear-out -o <wan-interface> -j ACCEPT
iptables -A FORWARD -i <wan-interface> -o veth-clear-out -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
watch -n1 'iptables -L FORWARD -v -n'

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

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

টানেলের মার্কিং নিয়মগুলো নতুন পথ থেকে দূরে রাখুন

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

দুটি সংযোজন পথ দুটিকে আলাদা করে। নেমস্পেস সাবনেটের জন্য mangle চেইনে আগেভাগে ফিরে যান, এবং একটি উৎস-ভিত্তিক নিয়ম যোগ করুন যা ওই সাবনেটকে মূল টেবিলে রাখে:

iptables -t mangle -I PREROUTING -s 192.168.100.0/24 -j RETURN
ip rule add from 192.168.100.0/24 lookup main priority 100

প্রায়োরিটি 100 আমার হোস্টে টানেল নিয়মের আগে বসে, তাই ওই উৎসের জন্য সাধারণ টেবিলই সিদ্ধান্ত নেয়। সংখ্যাটি অন্ধভাবে কপি করবেন না: যে প্রায়োরিটিগুলোwg-quick ইনস্টল করে সেগুলো সংস্করণে এবং IPv4 ও IPv6 সেটআপে আলাদা, তাই চালান ip rule show এবং এমন প্রায়োরিটি বেছে নিন যা আপনার মেশিনে টানেল নিয়মের সামনে পড়ে।

যাচাই করুন উৎস-নির্দিষ্ট অনুসন্ধান দিয়ে, নিয়মের তালিকায় ভরসা না করে:

ip route get 1.1.1.1 from 192.168.100.2
ip netns exec clearnet ip route get 1.1.1.1

যদি প্রথম কমান্ডটি WireGuard ইন্টারফেস জানায়, তবে নতুন নিয়মটি এখনো টানেল নীতির সামনে নয়। যদি এটি WAN ইন্টারফেস জানায় আর দ্বিতীয়টি এখনো veth ডিফল্ট দেখায়, তবে হোস্ট ও নেমস্পেস একমত নয় এবং আপনার দুটি রাউটিং টেবিলই আবার পড়া উচিত।

কোন প্রসেসটি সংযোগ খোলে সেটি চালু করুন

কমান্ড চালু করা এক লাইন, কিন্তু যে প্রসেসটি সত্যিই সকেট তৈরি করে সেটি চালু করুন।ip netns exec clearnet curl -s https://ifconfig.me হলো সবচেয়ে ছোট সৎ পরীক্ষা: এটি দেখায় নেমস্পেস বিশ্বের কাছে কোন ঠিকানা উপস্থাপন করে, হোস্ট যে ঠিকানা ব্যবহার করত তা নয়।

একটি সার্ভিসের জন্য নেমস্পেসটি পথ দিয়ে সংযুক্ত করুন যাতে প্রসেসটি তার পুরো জীবনকাল সেখানে থাকে:

[Service]
NetworkNamespacePath=/run/netns/clearnet

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

readlink /proc/$(pgrep -f clearnet-profile | head -1)/ns/net
readlink /run/netns/clearnet

দুটি আউটপুট মিলতে হবে। একই পরীক্ষা যেকোনো দীর্ঘকালীন প্রোগ্রামের জন্য কাজ করে, এবং লঞ্চার আপনার উদ্দেশ্য অনুযায়ী কাজ করেছে ধরে নেওয়ার বদলে প্রতি অ্যাপ্লিকেশনে একবার করা উচিত।

নাম রিজলিউশনের নিজস্ব সিদ্ধান্ত দরকার। নেমস্পেস তৈরি করলে তা রিজলভার কনফিগারেশন পায় না; প্রতি-নেমস্পেস ফাইল সমর্থিত হয়/etc/netns/<name>/resolv.conf এর মাধ্যমে, এবং তা ছাড়া আপনি এমন আচরণ উত্তরাধিকারে পান যা সহজেই ভুল পড়া যায়। IPv6-রও একই ব্যবস্থা দরকার: যদি নেমস্পেসের v6 ডিফল্ট রাউট না থাকে আর অ্যাপ্লিকেশন v6 পছন্দ করে, তবে অনুরোধগুলো ফিরে যাওয়ার আগে আটকে যেতে পারে, যা ভাঙা টানেলের মতো দেখায়।

ফ্রেমিং পরীক্ষা করুন, শুধু প্রস্থান ঠিকানা নয়

কাজ করা একটি পাবলিক ঠিকানা রাউট প্রমাণ করে, পুরো দাবি নয়। বাকিটা এই ক্রমে হাঁটুন:

• ip netns exec clearnet ip route get 1.1.1.1 veth ডিফল্ট দেখায়, WireGuard ইন্টারফেস নয়।
• অনুরোধ চলার সময় উভয় নিয়মের FORWARD কাউন্টার বাড়ে।
• অ্যাপ্লিকেশন প্রসেসটি আপনার প্রত্যাশিত নেমস্পেস inode জানায়।
• রিবুটের পর সার্ভিস শুরুর আগেই নেমস্পেস থাকে; আগে চলা unit ব্যর্থ হয়, বা আরও খারাপ, নেমস্পেসের বাইরে চলে।

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