Windows VPN میں غلط DNS سرور: میٹرک، بائنڈنگ ترتیب یا لاحقہ
Windows کے تین میکانزم DNS ریزالور منتخب کرتے ہیں، اور وہ مختلف طریقوں سے ناکام ہوتے ہیں۔ نام کی جگہ کے دائرہ کار، عالمی ترتیب، یا اس بات پر فیصلہ کریں کہ اصلاح دوبارہ منسلک ہونے کے بعد قائم رہتی ہے یا نہیں۔
Windows کلائنٹ کے پاس کام کرنے والا سرنگ ہو سکتا ہے، کارپوریٹ ریزالور ہو سکتا ہے اور پھر بھی اندرونی نام گھر کے راؤٹر کو بھیج سکتا ہے۔ کون سا سرور جواب دے گا یہ تین مختلف میکانزم طے کرتے ہیں، اور وہ مختلف طریقوں سے ناکام ہوتے ہیں۔ تینوں ٹھیک کرنے کی ضرورت نہیں: علامت بتاتی ہے کہ کون سی کھیل میں ہے۔ نیچے دیا گیا فیصلہ درخت چند منٹ لیتا ہے اور عام نتیجے کو روکتا ہے، جہاں میٹرک کی تبدیلی، رجسٹری کی دوبارہ ترتیب اور NRPT قاعدہ اکٹھے آتے ہیں اور کسی کو معلوم نہیں کہ کس نے کیا کیا۔
تین میکانزم فیصلہ کرتے ہیں، اور عام طور پر ایک غلط ہوتا ہے
انٹرفیس میٹرک کسی مخصوص پتہ خاندان کے لیے اڈاپٹروں کو ترتیب دیتی ہے۔ Tcpip\Linkage کے تحت بائنڈنگ ترتیب مشین کی سطح پر انٹرفیس شناخت کنندگان کی فہرست ہے جسے پرانے کوڈ راستے اب بھی دیکھتے ہیں۔ نام حل کرنے کی پالیسی جدول (NRPT) ایک نام کی جگہ کو مخصوص سرورز سے باندھتی ہے، اور لاحقہ فہرست طے کرتی ہے کہ مختصر نام آیا بالکل پھیلایا جائے گا۔ یہ آزاد ہیں، اسی لیے VPN اڈاپٹر پر درست ریزالور کہیں اور کی پرانی ترجیح سے ہار جاتا ہے۔
| What you see | Mechanism to check | First command |
|---|---|---|
| Every name is slow, public names sometimes wrong | Global adapter order: metric, then Linkage | Get-NetIPInterface |
| Internal names resolve to a public address | The query left through the home resolver, not the tunnel | Resolve-DnsName intranet.corp.example -Type A, then the same query with -Server 10.20.0.10 |
| Only corp.example names fail, public names fine | Namespace binding: NRPT or suffix | Get-DnsClientNrptRule |
| Short name fails, fully qualified name works | Suffix list on the adapter, with the corporate suffix ahead of other entries, or pushed by the server | Get-DnsClientGlobalSetting |
| Works, then breaks after a reconnect | Runtime setting that was never persisted | Get-VpnConnection for the stored profile, then Get-NetIPInterface again after a reconnect |
ان میکانزم میں سے کوئی بھی سرنگ کا دوسرا کنارہ نہیں ہے۔ اگر VPN جو سرور دھکیلتا ہے وہ نام حل نہیں کر سکتا، تو کلائنٹ کی طرف کی ہر ترتیب صرف سجاوٹ ہے، اس لیے پہلا فیصلہ یہ ہے کہ آیا ریزالور خود براہ راست پوچھے جانے پر جواب دے سکتا ہے۔
پہلا فیصلہ: کیا دھکیلا گیا ریزالور بالکل جواب دے سکتا ہے؟
سرور سے واضح طور پر پوچھیں اور عام تلاش سے موازنہ کریں۔ جوابات کے درمیان فرق انتخاب کے مسئلے کو رسائی کے مسئلے سے الگ کرتا ہے، اور یہاں یہی سب سے تیز شاخ ہے:
Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type Aاگر پہلا کامیاب اور دوسرا ناکام ہو، تو ریزالور قابل رسائی ہے اور Windows غلط انتخاب کر رہا ہے؛ نیچے نام کی جگہ اور ترتیب کے فیصلوں پر جائیں۔ اگر پہلا بھی ناکام ہو، تو کلائنٹ پر کچھ کام نہیں آئے گا: دیکھیں کہ UDP اور TCP 53 سرنگ کے ذریعے سرور تک پہنچتے ہیں، سرور پر کوئی ہوسٹ فائر وال پول کو نہیں گراتا، اور سرور کے اپنے فارورڈر صحت مند ہیں۔
اسی شاخ پر رکیں۔ جس ریزالور تک آپ نہیں پہنچ سکتے اس پر NRPT قاعدہ لگانا وہی ناکامی زیادہ واپس لینے والی ترتیب کے ساتھ دیتا ہے، اور اصل خرابی کو اختیار والا دکھنے والے قاعدے کے پیچھے چھپا دیتا ہے۔
دوسرا فیصلہ: ایک نام کی جگہ یا ہر استفسار؟
دائرہ کار اوزار طے کرتا ہے۔ جب صرف کارپوریٹ نام ناکام ہوں، تو مشین کو دوبارہ ترتیب دینے کے بجائے نام کی جگہ باندھیں: NRPT قاعدہ وہ لاحقہ سرنگ کے ریزالور کو بھیجتا ہے اور باقی سب کو چھوڑ دیتا ہے۔ جب ہر تلاش متاثر ہو، مسئلہ عالمی اڈاپٹر ترجیح ہے، اور میٹرک آغاز کی جگہ ہے کیونکہ یہ سرور کی کوئی ترتیب نہیں بدلتی۔
ہر پتہ خاندان کے لیے، دونوں انٹرفیسز پر میٹرک مقرر کریں، اور پھر ترتیب کی تصدیق کریں:
Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv6اوپر کی سطر سے سرنگ اڈاپٹر کے ifIndex سے 11 بدلیں؛ اگر 11 LAN اڈاپٹر ہے، تو وہی کمانڈ غلط راستہ نیچے کرتی ہے۔ اس کے بجائے LAN اڈاپٹر اوپر اٹھانے سے دوسری طرف سے وہی ترتیب ملتی ہے: netsh int ip set interface interface="Ethernet" metric=15، اور دوسرے خاندان کے لیے netsh int ipv6 set interface interface="Ethernet" metric=15، کیونکہ int ip صرف IPv4 کو چھوتا ہے۔
بائنڈنگ ترتیب پہلا قدم نہیں بلکہ آخری تدبیر ہے۔ HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage آلات کے شناخت کنندگان کی Bind فہرست رکھتا ہے، اور سرنگ کے شناخت کنندہ کو آگے لانا واقعی بدلتا ہے کہ کون سا اڈاپٹر پہلے پوچھا جائے گا، لیکن یہ مشین کی سطح پر رجسٹری قدر ہے جس کا ہر نام کی جگہ کے لیے دائرہ کار نہیں۔ ترمیم سے پہلے اسے برآمد کریں اور پھر سرنگ دوبارہ منسلک کریں، تاکہ ترتیب اس حالت میں لاگو ہو جس کی کلائنٹ توقع کرتا ہے۔
ایک نام کی جگہ کے لیے، تنگ اوزار چنیں:
Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServersتیسرا فیصلہ: کیا اصلاح دوبارہ منسلک ہونے کے بعد بھی قائم رہتی ہے؟
جو میٹرک اگلی ڈائل اپ دوبارہ منسلک ہونے تک چلتی ہے وہ کبھی محفوظ نہیں ہوئی تھی۔ L2TP/IPsec اور دیگر کنکشن پروفائلز کنکشن شروع ہونے پر دوبارہ بنائے جاتے ہیں، اس لیے محفوظ قدر فون بک اندراج میں IpInterfaceMetric کے طور پر رہتی ہے، صرف فعال انٹرفیس پر نہیں۔ کچھ ماحول اس فیلڈ کو بالکل اسی وجہ سے اسکرپٹ کرتے ہیں؛ دیگر انتظامی پالیسی سے ترجیح دھکیلتے ہیں اور آخری نقطہ چھوڑ دیتے ہیں۔
کیش اور رجسٹریشن الگ تہہ ہیں۔ سرنگ اوپر آنے کے بعد انہیں چلانا پرانے اندراجات درست کرتا ہے اور کلائنٹ کو دوبارہ رجسٹر کرتا ہے، لیکن کوئی بھی اڈاپٹر دوبارہ ترتیب نہیں دیتا:
ipconfig /registerdns
ipconfig /flushdnsاسی تہہ میں ایک بند سوئچ ہے۔ جسمانی اڈاپٹر پر متحرک رجسٹریشن بند کرنا کلائنٹ کو اس کے VPN طرف کے پتے کو غلط نام کے تحت اعلان کرنے سے روکتا ہے، اور یہ اوپر کی تجدید سے مختلف مرمت ہے۔
IPv6 فیصلے میں اپنی سطر کا حقدار ہے۔ اگر جسمانی اڈاپٹر کے پاس عالمی IPv6 پتہ ہے جبکہ سرنگ صرف IPv4 لے جاتی ہے، تو Windows نام حل کرنے کے لیے بغیر سرنگ والا راستہ ترجیح دے سکتا ہے۔ اس خاندان کو الگ سے دیکھیں، کیونکہ IPv4 کے لیے مقرر میٹرک اس کے بارے میں کچھ نہیں کہتی:
Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetricLAN اڈاپٹر پر IPv6 بند کرنا وہ راستہ اور اس کے ساتھ پروٹوکول ہٹا دیتا ہے؛ IPv6 انٹرفیس پر میٹرک تبدیلی، یا کارپوریٹ نام کی جگہ کے لیے NRPT قاعدہ، خاندان رکھتا ہے اور ترجیح درست کرتا ہے۔ تنگ تر چنیں، جب تک آپ نے طے نہ کیا ہو کہ اس لنک پر IPv6 نہیں ہونا چاہیے۔
نامزد ماخذ کے ساتھ تصدیق کریں، اور ایک ہی مالک رکھیں
صفحہ لوڈ ہوتا ہے یا نہیں اس کے علاوہ، کون سا ماخذ نافذ ہے یہ بتانے والے اوزاروں سے تصدیق کریں:
ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type Aپھر فلٹرنگ کو انتخاب سے الگ کریں، کیونکہ ایپلیکیشن کے اندر سے دونوں ایک جیسے دکھتے ہیں۔ OpenVPN کا block-outside-dns دیگر اڈاپٹروں پر پورٹ 53 بلاک کرتا ہے؛ یہ ریزالور منتخب نہیں کرتا۔ اگر اب ہر استفسار ناکام ہو، تو کوئی فلٹر واحد قابل رسائی سرور بلاک کر رہا ہو سکتا ہے؛ اگر ترتیب شدہ ریزالور نظر انداز ہو رہا ہے، تو ترتیب یا نام کی جگہ کا قاعدہ غلط ہے۔ دونوں کو اکٹھے بدلنا بلاک شدہ استفسار اور نظر انداز شدہ استفسار کو ناقابل تفریق بنا دیتا ہے۔
DNS پالیسی کے لیے ایک مالک رکھیں: VPN پروفائل، انتظامی پالیسی یا NRPT قاعدہ، ان میں سے دو نہیں۔ بند کرنے سے پہلے:
- دھکیلا گیا ریزالور واضح نام دیے جانے پر جواب دیتا ہے، اور عام تلاش اسے استعمال کرتی ہے۔
- آپ نے جو قاعدہ یا میٹرک بدلا وہ اس پتہ خاندان کو ڈھکتا ہے جو واقعی استفسارات لے جاتا ہے۔
- ترتیب منقطع اور دوبارہ منسلک ہونے کے بعد بھی قائم رہتی ہے، یا آپ نے اسے محفوظ پروفائل میں منتقل کر دیا ہے۔
- ٹھیک ایک میکانزم بااختیار ہے، اور باقی جیسے تھے ویسے ہی چھوڑ دیے گئے ہیں۔
ترتیب کو ختم کرنے والی چیز نہیں بلکہ ماحولیاتی حالت سمجھیں۔ دوبارہ منسلک ہونے کے بعد اور نیٹ ورک اسٹیک کو چھونے والی Windows اپ ڈیٹ کے بعد اسے دوبارہ جانچیں، کیونکہ ان میں سے کوئی بھی جسمانی اڈاپٹر کو دوبارہ آگے لا سکتا ہے۔