Windows VPN DNS لیک: میٹرک راستے کو کیوں ہرا دیتا ہے

ایک استفسار مشین سے نکل کر گھر کے راؤٹر تک پہنچتا ہے، جبکہ ہر پیکٹ ٹنل سے گزر رہا ہوتا ہے۔ قدرتی نتیجہ یہ ہے کہ راستہ غائب ہے، مگر راستہ عموماً درست ہوتا ہے۔ Windows انٹرفیس میٹرک کی بنیاد پر طے کر سکتا ہے کہ کس انٹرفیس کے ریزیالور سے پوچھا جائے، اور ٹنل اڈاپٹر یہ موازنہ اکثر وائرلیس سے ہار جاتا ہے۔

ایک لیک کے لیے دو وضاحتیں

راستے کی وضاحت کہتی ہے کہ کچھ ٹریفک ٹنل سے باہر نکل رہا ہے، لہٰذا ڈیفالٹ راستہ یا اسپلٹ ٹنل فہرست غلط ہونی چاہیے۔ اس وضاحت کو ایک ہی کمانڈ سے جانچا جا سکتا ہے، اور جب ڈیفالٹ راستہ ٹنل کے اندر اشارہ کرے تو معاملہ ختم ہے۔ اسے پہلے جانچیں کیونکہ یہ سستا ہے، پھر صاف نتیجہ آنے پر اسے ایک طرف رکھ دیں۔

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

میٹرک اور ریزیالور ایک ساتھ موازنہ کریں

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

Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object InterfaceIndex, InterfaceAlias, InterfaceMetric
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, ServerAddresses

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

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

ٹنل کو اوپر لائیں اور دوبارہ جانچیں

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

Set-NetIPInterface -InterfaceIndex 27 -InterfaceMetric 1
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric

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

پھر ایک اندرونی اور ایک عوامی نام پوچھیں اور دیکھیں کہ کون سا سرور جواب دے۔ Microsoft کا خودکار میٹرک کے بارے میں حوالہ بتاتا ہے کہ سب سے کم قدر کو ترجیح کیوں ملتی ہے اور خودکار تقسیم کیسے حاصل ہوتی ہے۔

اسے دوبارہ جڑنے پر بھی قائم رکھیں

ہر جوڑ پر دوبارہ بننے والے اڈاپٹر پر ہاتھ سے دیا گیا میٹرک غائب ہونے والی ترتیب ہے۔ اگر کلائنٹ انٹرفیس دوبارہ بنائے تو اس اوور رائیڈ کے لیے جوڑ کے بعد کی اسکرپٹ، پالیسی یا ایسی کلائنٹ ترتیب درکار ہے جو جوڑ کے دوران DNS کی مالک ہو۔

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