ایک پورٹ کے لیے VPN کو بائی پاس کرنے کے لیے پالیسی روٹنگ درکار ہے

درخواست ہمیشہ اسی جملے کی ایک شکل ہوتی ہے: براؤزنگ کے لیے VPN رکھیں، مگر SSH یا بیک اپ کام کو عام کنکشن استعمال کرنے دیں۔ اس بارے میں گردش کرنے والا مشورہ، یعنی پورٹ کو iptables NAT اصولوں سے آگے بھیجنا، یہ کام نہیں کرتا۔ NAT اصول کسی فلو کے اندر پتے اور پورٹیں بدلتا ہے؛ یہ کبھی منتخب نہیں کرتا کہ پیکٹ کس انٹرفیس سے باہر جائے۔ یہ فیصلہ روٹنگ تلاش کا ہے، اور روٹنگ تلاش کو پورٹ دیکھنے کے لیے مدد چاہیے۔

سادہ روٹ پورٹ سے کیوں نہیں مل سکتا

لینکس ٹیبل میں منزل کا پتہ ڈھونڈ کر روٹ منتخب کرتا ہے، اس کے بعد کہ امیدوار ٹیبل پالیسی اصولوں سے فلٹر ہو جائیں۔ یہ اصول فائر وال نشان، ماخذ پتہ، آنے والا انٹرفیس یا UID سے مل سکتے ہیں۔ روٹ اندراج میں خود کوئی پورٹ فیلڈ نہیں ہوتی، کیونکہ روٹ ٹرانسپورٹ ہیڈر کے اہم ہونے سے پہلے منتخب ہو جاتا ہے۔

موجودہ iproute2 اور کرنل اصول منتخب کرنے کی گنجائش بڑھاتے ہیں: ipproto، sport اور dport قبول کیے جاتے ہیں، لہٰذا ip rule add ipproto tcp dport 22 table 100 ارادہ ایک سطر میں ظاہر کرتا ہے۔ ip rule add help اصل ہوسٹ پر چلائیں تاکہ دیکھیں کہ آپ کا بلڈ dport درج کرتا ہے یا نہیں۔ اگر کرتا ہے تو ایک کمانڈ میں کام ہو گیا؛ اگر نہیں تو نیچے نشان والا راستہ اس کے برابر ہے۔

بہرحال اصول محض ایک اشارہ ہے۔ جدول 100 کو اب بھی روٹ چاہیے، اور یہی وہ حصہ ہے جو لوگ بھول جاتے ہیں۔

تین حصے، یا ایک

جدید شکل اوپر والا واحد اصول اور متبادل جدول میں ایک روٹ ہے۔ کلاسیکی شکل درمیان میں netfilter شامل کرتی ہے: پیکٹ کو نشان زد کریں، پھر اصول میں نشان سے مطابقت کریں۔ دونوں ایک ہی تلاش پر ختم ہوتے ہیں؛ فرق یہ ہے کہ پورٹ کہاں پڑھی جاتی ہے۔

نشان والا طریقہ اس لیے ہے کہ netfilter ٹرانسپورٹ ہیڈر دیکھتا ہے اور روٹنگ کوڈ تاریخی طور پر نہیں دیکھتا تھا۔ یہی پورا طریقہ کار ہے، اور یہ بتاتا ہے کہ متبادل راستہ ایک ہوشیار کمانڈ کے بجائے تین مل کر کام کرنے والے حصے کیوں ہے۔

تین حصے ترتیب سے

پہلے، جن فلوؤں کو موڑنا ہے انہیں نشان زد کریں، ایسی چین میں جو روٹ فیصلے سے پہلے نشان موجود ہونے کے لیے کافی جلدی چلے:

nft add table inet vpnexempt
nft 'add chain inet vpnexempt out { type route hook output priority mangle; }'
nft add rule inet vpnexempt out tcp dport 22 meta mark set 0x1

دوم، نشان زد پیکٹ الگ جدول میں بھیجیں:

ip rule add fwmark 0x1/0x1 table 100

سوم، اس جدول کو طبعی لنک کے ذریعے ڈیفالٹ روٹ دیں۔ پتے صرف مثال ہیں؛ اپنے لگائیں:

ip route add default via 192.168.1.1 dev wlan0 table 100

تیسرا مرحلہ چھوڑ دیں تو نشان زد پیکٹ کو جدول 100 میں کوئی روٹ نہیں ملتا، اس لیے ناکام ہو جاتا ہے۔ علامت ایسی لگتی ہے جیسے اصول نے نیٹ ورک توڑ دیا ہو، حالانکہ درحقیقت اس نے پیکٹ کے پاس بچا ہوا واحد راستہ ہٹا دیا۔

پہلے پیکٹ کے بعد اسے چلتا کیا رکھتا ہے

نشانات باہر جانے والے پیکٹوں پر لاگو ہوتے ہیں۔ جواب طبعی انٹرفیس پر اسی پتے کے ساتھ آتا ہے جو لنک نے دیا تھا، اور بنیادی جدول اس منزل کے لیے اب بھی ٹنل کو ترجیح دے سکتا ہے۔ دو طریقے جواب کا راستہ مستقل رکھتے ہیں: لنک پتے کے لیے ماخذ پر مبنی اصول، اور connection tracking جو فلو کی پوری عمر فیصلہ محفوظ رکھتا ہے۔ نشان کو conntrack میں محفوظ کرنا اور جواب پر بحال کرنا حالت والی استثنا کو مستحکم کرنے کا عام طریقہ ہے۔

معکوس راستہ فلٹرنگ دوسرا خاموش قاتل ہے۔ اگر کرنل واپسی کا راستہ سختی سے جانچے اور جواب ایسے انٹرفیس پر آئے جسے بنیادی جدول منتخب نہ کرتا، تو پیکٹ بغیر پیغام کے گرا دیا جاتا ہے۔ rp_filter ڈیفالٹ اقدار تقسیم کے مطابق اور اس بات پر منحصر ہیں کہ انٹرفیس آگے بھیجا جاتا ہے یا نہیں، لہٰذا یہ فرض کرنے کے بجائے کہ یہ بند ہے، موثر قدر پڑھیں۔

ٹنل کی اپنی ٹرانسپورٹ کو نشان زد نہ کریں۔ WireGuard یا UDP OpenVPN ٹنل TCP 22 نہیں ہے، اس لیے اوپر کا نسخہ محفوظ ہے، مگر ٹنل منزل کے سوا سب کچھ کے طور پر لکھی گئی استثنا خفیہ کردہ پیکٹ پکڑ سکتی ہے اور ٹنل کو ایسے توڑ سکتی ہے جو روٹنگ لوپ جیسا لگے۔

فرض کرنے کے بجائے جانچیں

کرنل سے پوچھیں کہ وہ کون سا راستہ لے گا، منزل کے لیے اور پورٹ کے لیے، پھر اصل منتقلی چلائیں:

ip route get 203.0.113.10
ip rule show
nft list ruleset

اگر نشان موجود ہے مگر کاؤنٹر کبھی نہیں ہلتے، تو اصول مطابقت نہیں رکھتا۔ کاؤنٹر وہ فرق ہیں جو آپ کی لکھی ترتیب اور کرنل کی لاگو پالیسی کے درمیان ہے۔

جب یہ غلط اوزار ہے

پورٹ پر مبنی استثنائیں فطرتاً نازک ہیں۔ سروسز پورٹیں بدلتی ہیں، HTTP/3 بطور UDP 443 آتا ہے، اور ایک ایپلیکیشن مختلف اقسام کے کئی فلو کھول سکتی ہے۔ اگر اصل تقاضا یہ ہے کہ یہ پروگرام عام لنک استعمال کرے تو روٹنگ کی پرت غلط جگہ ہے؛ نیٹ ورک نیم اسپیس یا فی ایپلیکیشن پراکسی زیادہ موزوں ہے۔

اگر تقاضا یہ ہے کہ یہ ذیلی نیٹ عام لنک استعمال کرے تو نشانات بالکل چھوڑ دیں اور زیادہ مخصوص روٹ شامل کریں۔ یہ آسان ہے، ایک جدول میں نظر آتا ہے، اور اگلا شخص اصولوں کا مجموعہ پڑھے بغیر اس کا جائزہ لے سکتا ہے۔

فائر وال کو چھونے سے پہلے لکھیں کہ تین تقاضوں میں سے آپ کے پاس واقعی کون سا ہے۔ اوپر کا طریقہ کار درست ہے، اور غلط پرت پر لاگو درستگی محض ایک طویل تعطل ہے۔