OpenWrt پالیسی روٹنگ: وہ زنجیر جو مقامی DNS کو پکڑتی ہے

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

دو بہاؤ، ایک حل کنندہ پتہ

پہلا بہاؤ وہی ہے جس کا لوگ تصور کرتے ہیں۔ کلائنٹ روٹر کے حل کنندہ سے پوچھتا ہے، حل کنندہ اوپر کی طرف بھیجتا ہے، اور وہ بھیجا گیا پیکٹ باہر جاتے وقت روٹر سے گزرتا ہے۔ وہ پیکٹ آگے بھیجے گئے ٹریفک کو دیکھنے والی ہر چیز کو نظر آتا ہے۔

دوسرا بہاؤ کبھی کہیں سے نہیں آتا۔ روٹر اسے بناتا ہے، اس لیے نہ کوئی آنے والا پیکٹ ہے اور نہ ملانے کے لیے کوئی فارورڈنگ مرحلہ۔

دونوں ایک ہی حل کنندہ پتے کو نشانہ بنا سکتے ہیں، اور اسی لیے فرق کو نظرانداز کرنا آسان ہے۔ وہی منزل، مختلف اصل، مختلف زنجیر۔ اصل نظر آتے ہی باقی تشخیص پیچھے چلتی ہے۔

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

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

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

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

آؤٹ پٹ زنجیر چنیں، پھر مطابقت کو تنگ کریں

درستی یہ ہے کہ وہی ارادہ آؤٹ پٹ زنجیر سے بھی جوڑا جائے، یا جب روٹر کے اپنے استفسارات آپ کے لیے اہم ہوں تو قاعدہ وہاں منتقل کیا جائے۔ پالیسی روٹنگ پیکیج پر بنے OpenWrt سیٹ اپ میں اس کا مطلب قاعدے کی زنجیر ترتیب میں prerouting کی بجائے output چننا ہے۔ اگر دونوں آبادیوں کو احاطہ درکار ہو تو دونوں قاعدے رکھیں۔

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

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

سرنگ کی اپنی ترسیل قاعدے سے باہر رکھیں

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

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

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

ایک نہیں، دونوں آبادیوں کی جانچ کریں

روٹر کو اپنا استفسار کرتے دیکھیں اور نوٹ کریں کہ کس انٹرفیس نے اسے اٹھایا۔ LAN ہوسٹ سے تلاش دہرائیں اور نوٹ کریں کہ اس نے کون سا راستہ لیا۔ پالیسی قواعد کے کاؤنٹر بغیر اندازے کے دونوں جواب دکھا دیتے ہیں۔

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

پورٹ بھی جانچیں: منزل پورٹ 53 سے ملنے والا قاعدہ 853 پر DNS over TLS یا HTTPS آخری نقطے کے ذریعے پہنچنے والے حل کنندہ کو چھوڑ دیتا ہے۔ اپ اسٹریم جو ترسیل واقعی استعمال کرتا ہے اس سے ملائیں، اور رساؤ درست وجہ سے بند ہوتا ہے۔