آپ کی عوامی Linux سروس VPN سے کیوں جواب دیتی ہے

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

غلط فہمی: جواب اُسی انٹرفیس کی پیروی کرتے ہیں جس پر آئے

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

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

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

کرنل اصل میں کیا روٹ کرتا ہے: ماخذ پتہ

آپ کو جو ہینڈل درکار ہے وہ مقامی پتہ ہے جو سروس جوابات کے لیے استعمال کرتی ہے۔ eth0 پتہ مثال کے طور پر 192.0.2.10/24 اور گیٹ وے 192.0.2.1 والے ہوسٹ پر وہ پتہ انٹرفیس پر موجود ہوتا ہے۔ کلاؤڈ VM پر عوامی پتہ اوپر ترجمہ شدہ اور مہمان میں غائب ہو سکتا ہے، اس لیے وہی پتہ استعمال کریں جو ہوسٹ کے پاس واقعی ہے۔

جدول نمبر یا قاعدے کی ترجیح محفوظ کرنے سے پہلے موجودہ حالت دیکھیں۔ موجودہ پالیسی قواعد نئے کو سایہ کر سکتے ہیں، اور اسی نمبر کا پرانا جدول پہلے ہی غیر متعلق راستے رکھ سکتا ہے:

ip -4 addr show dev eth0
ip -4 rule show
ip -4 route show table all

پھر ماخذ کے مطابق جدول منتخب کریں۔ قاعدہ اُن جوابات سے مطابقت رکھتا ہے جو پہلے ہی 192.0.2.10 رکھتے ہیں، یعنی وہی مقامی طور پر ختم شدہ ٹریفک جسے آپ مستثنیٰ کرنا چاہتے ہیں۔ آگے بھیجی گئی ٹریفک اور دیگر مقامی پتوں سے آنے والے پیکٹ مطابقت نہیں رکھتے۔

آدھا ڈیفالٹ نہیں، مکمل واپسی جدول بنائیں

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

ip -4 route add table 100 192.0.2.0/24 dev eth0 src 192.0.2.10
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 from 192.0.2.10/32 lookup 100

مثال نقل کرنے کے بجائے حقیقی سابقہ اور گیٹ وے استعمال کریں۔ on-link گیٹ وے کے ساتھ /32 کے طور پر ترتیب دیا گیا کلاؤڈ انٹرفیس مختلف جڑا ہوا راستہ چاہتا ہے، اور غلط سابقے سے بنایا گیا جدول پہلی چھلانگ پر ہی ناکام رہتا ہے۔ src خصوصیت اُس راستے کے لیے ترجیحی ماخذ بتاتی ہے؛ یہ ماخذ قاعدے کی جگہ نہیں لیتی۔

ترتیب بھی اہم ہے۔ کم ترجیحی نمبر والا وسیع قاعدہ پہلے جانچا جاتا ہے، اس لیے ماخذ قاعدے تک اُس کسی بھی قاعدے سے پہلے پہنچنا چاہیے جو یہ ٹریفک واپس مرکزی جدول میں بھیج دے۔ شامل کرنے کے بعد ip rule show سے ترجیحات جانچیں، صرف بوٹ پر نہیں۔

ماخذ کے مطابق متعین تلاش سے تصدیق کریں

کرنل سے کہیں کہ سروس کے پتے سے ایک آزمائشی منزل کی طرف راستہ بنائے۔ جواب میں ٹنل نہیں، eth0 اور WAN گیٹ وے کا نام ہونا چاہیے:

ip -4 route get 198.51.100.25 from 192.0.2.10

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

حتمی راستے اور قاعدہ اُس نیٹ ورک مینیجر کے تحت رکھیں جو انٹرفیس کا مالک ہے۔ پتہ تبدیلیاں، DHCP کی تجدید اور VPN کے دوبارہ کنکشن سب کرنل کی حالت دوبارہ لکھتے ہیں، اور ہاتھ سے شامل کیا گیا قاعدہ اگلے واقعے کے بعد غائب ہو جاتا ہے یا پرانے گیٹ وے کی طرف اشارہ کرتا ہے۔

یہ استثنا کہاں رکتا ہے

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

یہ ہوسٹ کے عوامی پتے کو انٹرفیس پر ظاہر بھی نہیں کرتا۔ جب اوپر کا NAT اُس پتے کا مالک ہوتا ہے، تب جواب کو اب بھی اُسی راستے سے نکلنا ہوتا ہے جس کی وہ NAT توقع کرتا ہے، اسی لیے WAN جدول کو اندازے والی عوامی حد کے بجائے اصل گیٹ وے اور سابقے کی عکاسی کرنی چاہیے۔

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

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