روٹر کا اپنا DNS VPN ٹنل سے کیوں گزرتا ہے؟

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

پیکٹ کی ریکارڈنگ دراصل کس بہاؤ کی ہے

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

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

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

sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53

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

پالیسی راستہ دوسرا استفسار کیوں کبھی نہیں دیکھتا

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

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

pfSense حل کنندہ اپنا بالا رخی راستہ کہاں طے کرتا ہے

pfSense اس تقسیم کو نظر آنے والا بناتا ہے۔ کلائنٹ ٹریفک کو پالیسی راستے سے VPN گیٹ وے سے گزارا جا سکتا ہے، جبکہ فائر وال کی اپنی ٹریفک LAN قواعد کے بجائے حل کنندہ کی اخراجی ترتیب کی پیروی کرتی ہے۔ ویب انٹرفیس میں وہ ترتیب Services > DNS Resolver > Outgoing Network Interfaces کے تحت ہے، اور اس کی قدر ان انٹرفیسوں کی فہرست ہے جنہیں حل کنندہ بالا رخی استفسارات کے لیے استعمال کر سکتا ہے۔

وہاں ٹنل انٹرفیس کا نام دینا، اور صرف اسی انٹرفیس کا، وہی چیز ہے جو روٹر کی اپنی تلاشوں کو ٹنل کی پیروی کرنے پر مجبور کرتی ہے۔ طے شدہ پر چھوڑ دیا جائے تو حل کنندہ روٹنگ جدول سے اخراج چنتا ہے، جو دوہرے WAN یا VPN والے ہوسٹ پر اکثر WAN ہوتا ہے۔

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

ترتیب سے پہلے ناکامی کا رویہ چنیں

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

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

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

دونوں راستے جانچیں اور نتائج الگ رکھیں

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

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

dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lan

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

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