LAN ہوسٹ نام VPN پر کام نہیں کرتا: لاحقہ، mDNS یا زون؟
مختصر نام تلاش لاحقے پر انحصار کر سکتا ہے، .local نام ملٹی کاسٹ پر اور کمپنی کا نام نجی زون پر۔ صرف راستہ کوئی نام دینے کی خدمت فراہم نہیں کرتا۔
ڈیوائس کے پاس پرنٹر مختصر نام پر جواب دیتا ہے اور فائل سرور عرفی نام پر جواب دیتا ہے۔ ٹنل کے ذریعے دونوں نام وقت سے باہر ہو جاتے ہیں جبکہ ان کے پتے اب بھی کام کرتے ہیں۔ راستہ اپنا کام کر رہا ہے؛ نام دینے کا وہ راستہ جس نے ان مختصر ناموں کو کام کرایا تھا کبھی ٹنل عبور نہیں کیا۔ تین میکانزم یہ رویہ پیدا کرتے ہیں اور ہر ایک کو مختلف اصلاح درکار ہے۔
نام کس میکانزم پر منحصر ہے اس کی نشاندہی سے شروع کریں۔
مختلف طریقے سے برتاؤ کرنے والے تین قسم کے نام
fileserver جیسا واحد لیبل والا نام عام طور پر DNS تلاش لاحقے پر انحصار کرتا ہے جو ریزولور شامل کرتا ہے۔ وہ لاحقہ اکثر مقامی DHCP لیز کے ساتھ آتا ہے، اس لیے VPN سے پتہ حاصل کرنے والے دور دراز کلائنٹ کو اسے جاننے کی کوئی وجہ نہیں۔ راستہ شامل کرنے سے لاحقہ نہیں پہنچتا۔ مختصر نام بطور نام رہنا ہی چھوڑ دیتا ہے، اگرچہ اس کے پیچھے کا پتہ قابل رسائی ہو۔
.local پر ختم ہونے والا نام عام طور پر مقامی لنک پر ملٹی کاسٹ DNS کے ذریعے حل ہوتا ہے، جیسا کہ RFC 6762 بیان کرتا ہے۔ ملٹی کاسٹ روٹ شدہ ٹنل عبور نہیں کرتا جب تک کوئی جان بوجھ کر اسے پل یا پراکسی نہ کرے، اس لیے جس لمحے آپ سیگمنٹ چھوڑتے ہیں نام حل ہونا بند ہو جاتا ہے۔
مکمل طور پر اہل کمپنی کا نام اندرونی زون سے تعلق رکھتا ہے جس کی خدمت تنظیم کے ریزولور کرتے ہیں۔ وہ دور سے اس وقت کام کرتا ہے جب VPN وہ ریزولور دھکیلتا ہے اور کلائنٹ انہیں استعمال کرنے کے لیے ترتیب دیا گیا ہو۔ اور localhost RFC 6761 کے مطابق خصوصی استعمال کا ہے: یہ آپ کے سامنے والی مشین کی طرف اشارہ کرتا ہے، کبھی دور دراز سروس کی طرف نہیں۔
راستہ بدلنے سے پہلے ریزولور پڑھیں
پوچھیں کہ کون سے نام سرور نے جواب دیا اور کون سا لاحقہ شامل ہوا۔ وہی استفسار مختلف ریزولور کے ذریعے مختلف جوابات دیتا ہے، اور یہی فرق آپ کو درکار ثبوت ہے۔
getent hosts fileserver getent hosts fileserver.corp.example.com nslookup fileserver.corp.example.com dig +search fileserver A resolvectl query fileserver.corp.example.com scutil --dns | head -30
اگر مکمل اہل استفسار حل ہو جائے مگر مختصر نہ ہو، تو خرابی لاحقے میں ہے، سرور میں نہیں۔ اگر کوئی بھی حل نہ ہو اور پتہ کام کرے، تو کلائنٹ اندرونی ریزولور بالکل استعمال نہیں کر رہا۔ ریزولور کی فہرست کا موازنہ اس سے کریں جو VPN کو دھکیلنا چاہیے، کیونکہ ہر استفسار کے لیے اپنا مقامی ریزولور رکھنے والا کلائنٹ اندرونی زون کبھی نہیں دیکھے گا۔
درست نام کلائنٹ تک پہنچائیں
منتظم سے دستاویزی دور دراز رسائی کا نام مکمل طور پر طلب کریں اور لاحقوں کا اندازہ لگانے کے بجائے پروفائل میں اسے استعمال کریں۔ اگر تعیناتی split DNS کی حمایت کرتی ہے، تو اندرونی ڈومین کو اندرونی سرورز سے حل کرنے کے لیے ترتیب دیں جبکہ باقی سب مقامی ریزولور رکھیں۔ جہاں کلائنٹ حمایت کرتا ہے وہاں VPN ترتیب کے ذریعے تلاش ڈومین دھکیلیں۔
نتیجہ کلائنٹ پر جانچیں، گیٹ وے پر نہیں۔ سرور پر لاگو کوئی ترتیب جو کبھی کلائنٹ تک نہ پہنچے، کچھ نہیں بدلتی۔
سرٹیفکیٹ کی شناخت محفوظ رکھیں
پتے پر مبنی ایسا امتحان جو سرٹیفکیٹ کی خرابی نظر انداز کرے صرف یہ ثابت کرتا ہے کہ ساکٹ کھلا۔ سروس کا سرٹیفکیٹ ایک نام کے لیے جاری ہوتا ہے، اور کلائنٹ مناسب وجہ سے عدم مطابقت کو مسترد کرتا رہے گا۔ اگر سرٹیفکیٹ میں صرف اندرونی نام درج ہو، تو وہی نام استعمال کریں اور حل درست کریں، یا ایسا سرٹیفکیٹ حاصل کریں جو آپ کے مطلوبہ پتے کا احاطہ کرے۔
جس نام، ریزولور اور لاحقے نے کامیاب کنکشن دیا اسے درج کریں۔ وہ ریکارڈ اگلے شخص کو اس پتے پر مبنی متبادل حل کو دہرانے سے بچاتا ہے جو اصل مسئلہ چھپاتا ہے۔