WireGuard سرنگ سے باہر ایک Linux عمل کیسے چلائیں

آپ روٹس میں ترمیم کر کے کسی پروگرام کو مکمل سرنگ والے 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 فراہم کنندہ سب نیٹ ورک نام کی جگہ کے دائرے سے باہر ہیں، اور استثنا کو گمنامی سمجھنا وہ غلطی ہے جو ترتیب سے زیادہ جیتی ہے۔