ڈی این ایس ری ڈائریکٹ کے بعد dnsmasq کے سوالات VPN سے باہر کیوں نکلتے ہیں

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

نشان سوال کے ساتھ سفر نہیں کرتا

پیکٹ کے نشانات conntrack اندراج پر اور اڑتے پیکٹ پر رہتے ہیں۔ ایک REDIRECT قاعدہ اس اڑان کو ختم کرتا ہے: پے لوڈ مقامی ساکٹ کو دیا جاتا ہے، اور اصل اندراج اپنا کام کر چکا ہوتا ہے۔ اس کے بعد روٹر سے جو نکلتا ہے وہ ریزالور کے عمل کا بنایا ہوا نیا ساکٹ ہے، جس کا ماخذ روٹر کا اپنا پتہ ہے۔

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

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

کہاں آگے بھیجنا مقامی حل بنتا ہے

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

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

sudo nft list ruleset | grep -n -B2 -A4 'dport 53'
sudo iptables -t nat -L -n -v | grep -E ':53|dns'
sudo ss -lunp | grep ':53'

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

ریزالور کو اس کی اپنی اخراج پالیسی دیں

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

server=/corp.example/10.30.0.53@tun_work
log-queries

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

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

مشترکہ کیش کیا محفوظ نہیں رکھ سکتا

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

کیش شدہ جواب بھی نئے راستے کے بارے میں ثبوت نہیں ہے۔ جواب یادداشت سے آ سکتا ہے جبکہ بالائی راستہ ٹوٹا رہتا ہے۔

پورٹ 53 کے قواعد ان ایپلی کیشنز کے بارے میں کچھ نہیں کہتے جو DNS کو HTTPS یا TLS پر بولتی ہیں۔ وہ سوالات کبھی ری ڈائریکٹ تک نہیں پہنچتے، اس لیے صرف پورٹ 53 پر بنی پالیسی ٹریفک کا ایک ذیلی مجموعہ بیان کرتی ہے اور اسے ذیلی مجموعے کے طور پر درج کیا جانا چاہیے۔

دوسری گفتگو کی تصدیق کریں، پہلی کی نہیں

کسی ایک نام سے آزمائیں جسے آپ کنٹرول کرتے ہیں اور دونوں طرف دیکھیں۔ کلائنٹ کی طرف کیپچر ثابت کرتی ہے کہ سوال نے LAN چھوڑ دیا؛ آگے کہاں گیا یہ صرف روٹر کی طرف ثابت کرتی ہے۔

sudo tcpdump -ni tun_work udp port 53
ip route get 10.30.0.53
dig +short corp.example @10.30.0.53

ہر کوشش سے پہلے کیش خالی کریں، کیونکہ گرم جواب ٹوٹا ہوا بالائی راستہ چھپا دیتا ہے۔ TCP پر دہرائیں، پھر سرنگ بند کر کے دہرائیں تاکہ دیکھ سکیں کہ ریزالور اپنا پسندیدہ راستہ جانے پر کیا کرتا ہے۔ وہی آخری برتاؤ طے کرتا ہے کہ ڈیزائن fail-closed ہے یا محض خوش قسمت۔