ونڈوز آپ کے VPN نام ایسے DNS سرور کو کیوں بھیجتی ہے جو آپ نے کبھی سیٹ نہیں کیا

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

آپ نے کیا بدلا، اور اصل میں کیا فیصلہ کرتا ہے

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

اسی لیے ایک ہی لیپ ٹاپ پر دو نام ایک ہی لمحے مختلف راستوں پر جا سکتے ہیں۔ کارپوریٹ لاحقے کے تحت میزبان اپنے قاعدے کی پیروی کرتا ہے؛ عوامی نام طے شدہ راستہ لیتا ہے، جس کا مطلب عموماً وہ ایڈاپٹر ہوتا ہے جو پہلے جواب دیتا ہے۔

جدول نام کو کیسے ملاتا ہے

قواعد نام کی فضا کے مطابق کلید بندھے ہیں، اور سب سے مخصوص مطابقت جیتتی ہے۔ corp.example کے لیے قاعدہ vpn.corp.example پر لاگو ہوتا ہے اور example.net پر لاگو نہیں ہوتا۔ . نام کی فضا والا قاعدہ وہ سب ڈھکتا ہے جو دوسرے قواعد نہیں ڈھکتے، جس سے یہ فہرست کا سب سے خطرناک اندراج بن جاتا ہے اور وہ بھی جسے اس وقت جانچنا چاہیے جب کوئی غیر متعلق سائٹ سرنگ سے حل ہو۔

قاعدے میں تبصرہ، اندراج کو غیر فعال کرنے والی پالیسی، اور ایسی حفاظتی ترتیبات بھی ہو سکتی ہیں جن کا DNS پتوں سے کوئی تعلق نہیں۔ غیر فعال قاعدہ ترتیب میں نظر آتا رہتا ہے مگر اثر نہیں کرتا، اس لیے کاغذ پر درست دکھنے والا اندراج پروفائل تبدیلی کے بعد بھی غیر موثر رہ سکتا ہے۔

خواہشات کی فہرست نہیں، نافذ جدول پڑھیں

ترتیب دیے گئے قواعد اور نافذ قواعد دو الگ سوال ہیں۔ Get-DnsClientNrptRule بتاتا ہے کہ مشین پر کیا موجود ہے۔ Get-DnsClientNrptPolicy -Effective دکھاتا ہے کہ کلائنٹ واقعی کیا لاگو کرے گا، پالیسی اور مقامی ترتیبات سے ملے ہوئے اقدار کے ساتھ۔

اس پیداوار میں لاحقے کا موازنہ آپ کے جانچے جانے والے نام سے حرف بحرف کریں۔ corp.example کے لیے قاعدہ corp.example.com پر ختم ہونے والا نام نہیں پکڑتا، اور ایک جگہ آخر میں نقطہ ہونا اور دوسری جگہ نہ ہونا مطابقت بدلنے کے لیے کافی ہے۔

قاعدے کے بغیر ونڈوز ایک سے زیادہ ایڈاپٹروں سے پوچھتی ہے

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

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

وہ راستے جو حل کنندہ کو مکمل طور پر چھوڑ دیتے ہیں

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

یہ بھی دیکھیں کہ اطلاق پچھلے اجلاس کے محفوظ شدہ پتے سے جڑ رہا ہے یا نہیں۔ Clear-DnsClientCache اور پھر وہی تلاش پرانے نتیجے سے اندازہ لگانے کے مقابلے میں صاف جواب دیتی ہے۔

اسی نام سے جانچ کریں جو ناکام ہوا

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

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