VPN کے اندر mDNS: .local نام کیوں حل نہیں ہوتے

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

دیکھیں آج کیا حل ہوتا ہے اور کیا صرف حل شدہ دکھتا ہے

پہلے دو سوال الگ کریں: میزبان نام کے لیے unicast استفسار حل کنندہ سے پوچھتا ہے، جبکہ _ipp._tcp کے لیے تلاش مقامی لنک سے پوچھتی ہے۔ Linux پر، avahi-browse -a دکھاتا ہے کہ ملٹی کاسٹ DNS کیا دیکھ سکتا ہے، اور resolvectl query name.local دکھاتا ہے کہ حل کنندہ اسٹیک اس نام کے ساتھ کیا کرتا ہے۔ macOS پر، dns-sd -B _ipp._tcp پہلے پتے کی ضرورت کے بغیر دریافت شدہ خدمات کی فہرست بناتا ہے۔

اگر پتہ جواب دیتا ہے اور نام نہیں، تو راؤٹنگ کام کرتی ہے اور دریافت نہیں۔ .local نام میزبان پر ہی nss-mdns کے ذریعے بھی حل ہو سکتا ہے چاہے avahi-browse انسٹال نہ ہو، اس لیے اس نام پر کامیاب getent یا پنگ اس بات کا ثبوت نہیں کہ دریافت سرنگ عبور کر گئی؛ تلاش کا نتیجہ اور حل کنندہ کا نتیجہ مختلف شواہد ہیں۔ ایپس جو دریافت کرتی ہیں اسے کیش کرتی ہیں، اسی لیے خرابی اکثر کنیکٹ ہونے کے گھنٹوں بعد ظاہر ہوتی ہے، کنیکٹ ہوتے وقت نہیں۔ ایپ بند کر کے دوبارہ کھولیں، پھر دیکھیں کہ کیش شدہ اندراج میں نام ہے یا پتہ، کیونکہ دریافت رکنے کے بعد بھی پتہ طویل وقت تک کام کرتا ہے۔

استفسار کبھی سرنگ کیوں عبور نہیں کرتا

ملٹی کاسٹ DNS استفسارات 224.0.0.251 پر، مقامی نیٹ ورک کنٹرول بلاک کے اندر، UDP پورٹ 5353 پر بھیجتا ہے۔ راؤٹر اس بلاک کے پتے آگے نہیں بھیجتے، اس لیے استفسار اسی لنک پر رہتا ہے جہاں بھیجا گیا تھا۔ بھیجنے والے IP TTL یا IPv6 ہاپ حد کو 255 پر مقرر کرتے ہیں تاکہ وصول کنندہ اس پیکٹ کو مسترد کر سکے جو پہلے ہی راؤٹر عبور کر چکا ہے؛ پروٹوکول لنک سے باہر کی جعل سازی اسی طرح پکڑتا ہے، اس طرح نہیں کہ وہ مقامی رہتا ہے۔ مقامیت منزل کے پتے سے آتی ہے، ایک ہاپ TTL سے نہیں۔

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

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

ایسا نام رکھنے کا ڈیزائن چنیں جو آپ سنبھال سکیں

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

دریافت کی پراکسی یا mDNS منعکس کرنے والا اس خلا کو پل کر سکتا ہے، اور یہ اپنے میزبان، اپنی نمائش اور اپنی کلائنٹ ضروریات والا حقیقی ڈیزائن ہے۔ یہ اس لیے ظاہر نہیں ہوتا کہ آپ نے راستہ شامل کیا۔ کبھی بھی .local استفسارات عوامی حل کنندہ کو آگے نہ بھیجیں: ڈومین RFC 6762 کے تحت مقامی ملٹی کاسٹ استعمال کے لیے مخصوص ہے، اور اسے باہر بھیجنے سے سست ناکامیاں اور غیر ضروری ڈیٹا افشا ہوتا ہے۔

نام نہیں، خدمت کی تصدیق کریں

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

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