VPN سے باہر صرف ایک مقامی ویب سروس کو پورٹ کے مطابق روٹ کریں

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

قاعدہ لکھنے سے پہلے تینوں شرطیں جانچیں

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

دوسری شرط پالیسی ہے، میکینکس نہیں۔ سرنگ کو نظرانداز کرنے والا ہر راستہ سرنگ کے مقصد کا استثنا ہے، اور منظم ہوسٹ پر یہ فیصلہ پالیسی کے مالک کا ہے، ٹائم آؤٹ ڈیبگ کرنے والے شخص کا نہیں۔

جواب ملائیں، کلائنٹ کا منزل پورٹ نہیں

TCP 443 پر سننے والے سرور کا جواب ہوسٹ سے ماخذ پورٹ 443 کے ساتھ نکلتا ہے۔ اسی ہوسٹ کا براؤزر دور دراز کی HTTPS سائٹ سے جڑتے وقت عارضی ماخذ پورٹ اور منزل پورٹ 443 بھیجتا ہے۔ دونوں پورٹ 443 کی ٹریفک ہیں اور ان میں سے صرف ایک کو WAN جدول لینا چاہیے، اسی لیے منزل-پورٹ ملاپ غلط آدھا حصہ پکڑ لے گا۔

جواب کی سمت ہی وہ چیز ہے جو آپ الگ کر سکتے ہیں۔ ماخذ پورٹ ملائیں، قاعدہ کو مقامی طور پر بنائے گئے پیکٹوں تک محدود رکھیں، اور قاعدہ براؤزر کی درخواستوں کو چھوئے بغیر سروس کے اپنے جوابات کا احاطہ کرتا ہے۔

قاعدہ اس کی طرف اشارہ کرنے سے پہلے مکمل واپسی جدول بنائیں

خالی جدول کا مطلب ہے کوئی راستہ نہیں، جو ٹوٹی پالیسی سے زیادہ ٹوٹی سروس جیسا لگتا ہے۔ پہلے اسے بھریں، ایسے جدول نمبر اور ترجیح کے ساتھ جن پر ہوسٹ پر اور کچھ دعویٰ نہ کرے:

ip -4 route add table 100 192.0.2.0/24 dev eth0
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 iif lo ipproto tcp sport 443 lookup 100

اعداد نقل کرنے کے بجائے زندہ ہوسٹ سے پڑھیں۔ ip -4 rule show بتاتا ہے کہ کون سی ترجیحات لی جا چکی ہیں، اور پہلے سے موجود ترجیح پر قاعدہ شامل کرنا الگ الگ درست دکھنے والے دو قواعد کی ترتیب خاموشی سے بدل دیتا ہے۔

یہاں اصل کام دو منتخب کنندہ کرتے ہیں۔ iif lo یہ بتاتا ہے کہ کرنل ہوسٹ کے خود بنائے گئے پیکٹوں کی اطلاع کیسے دیتا ہے، اس لیے قاعدہ باہر سے آنے والی فارورڈ ٹریفک کو غلطی سے نہیں پکڑ سکتا۔ ipproto tcp sport 443 اسے ایک ٹرانسپورٹ اور ایک پورٹ تک محدود کرتا ہے، جو ضرورت کے مطابق جتنا تنگ ہو سکتا ہے اتنا تنگ ہے۔ پروٹوکول منتخب کنندہ ہٹا دیں تو قاعدہ UDP 443 بھی پکڑ لے گا، جو مختلف رویے والی مختلف سروس ہے۔

نجی جوابات سرنگ کے اندر رکھیں

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

ip -4 route add table 100 throw 10.90.0.0/24

throw راستہ اس جدول میں تلاش ختم کرتا ہے اور پیکٹ کو قواعد کی فہرست میں واپس دیتا ہے، تاکہ اگلی VPN پالیسی کو اپنا موقع ملے۔ یہ خود سرنگ میں کچھ روٹ نہیں کرتا، اور اگر بعد کے کسی قاعدے کے پاس مماثل راستہ نہ ہو تو پیکٹ پھر بھی ناکام ہوتا ہے؛ throw کو حل ماننے کے بجائے اگلی پالیسی کی تصدیق کریں۔

ریورس-پاتھ فلٹرنگ اور ہوسٹ فائر وال قواعد آنے والی درخواست پر اب بھی لاگو ہوتے ہیں۔ توثیق نرم کرنے سے پہلے ان کے حقیقی فیصلے دیکھیں، کیونکہ روٹنگ استثنا rp_filter کو ناممکن سمجھے جانے والے واپسی راستے کو قبول کرنے پر مجبور نہیں کرتا۔

TCP، پھر QUIC، پھر ری بوٹ جانچیں

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

HTTP/3 UDP پر پیش کیا جاتا ہے اور TCP قاعدے سے مماثل نہیں ہوگا، اس لیے QUIC سننے والے کو اپنا منتخب کنندہ چاہیے، ورنہ HTTPS کے چلنے کے دوران بھی یہ سرنگ استعمال کرتا رہے گا۔ جن قواعد پر آپ ٹھہریں انہیں انٹرفیس کے مالک اجزاء کے پاس محفوظ کریں، اور دوبارہ جڑنے یا DHCP کی تجدید کے بعد ان کی تصدیق کریں۔ ری بوٹ کے بعد کوئی حریف مینیجر رن ٹائم راستہ ہٹا دے، تو یہ اصل میں درست کرنے والا ملکیت کا مسئلہ ہے، اوپر مزید وسیع NAT قواعد شامل کرنے کی وجہ نہیں۔