PowerShell کے ذریعے Windows VPN اڈاپٹر پر DNS مقرر کریں، پھر تصدیق کریں

Windows VPN کنکشن اُس پروفائل میں DNS سرور محفوظ نہیں کرتا جو آپ ترتیبات میں ترمیم کرتے ہیں۔ جب ٹنل اُٹھتا ہے، کلائنٹ گیٹ وے کے ساتھ IP کنفیگریشن پر گفت و شنید کرتا ہے، گیٹ وے حل کنندگان کی فہرست بھیجتا ہے، اور Windows اُسے ٹنل اڈاپٹر پر لاگو کرتا ہے۔ وہ اڈاپٹر آپ کے Wi-Fi یا Ethernet سے الگ انٹرفیس ہے، اور فہرست انٹرفیس کی ہے، پروفائل کی نہیں۔ جب آپ جان لیں کہ کون سی شے اس قدر کی مالک ہے، تو PowerShell میں اُسے اوور رائیڈ کرنا ایک ہی حکم ہے؛ اوور رائیڈ کو دوبارہ کنیکٹ ہونے تک برقرار رکھنا وہ حصہ ہے جس کے لیے فیصلہ درکار ہے۔

پتہ کس شے کی ملکیت ہے

RAS ٹنل اڈاپٹر اُس وقت بناتا ہے جب کنکشن کامیاب ہو اور اُس وقت ہٹاتا ہے جب کنکشن منقطع ہو۔ آپ کو ipconfig /all میں نظر آنے والے DNS سرور اُسی کنفیگریشن کے تبادلے کے دوران، IPv4 اور IPv6 پتوں اور راستوں کے ساتھ آتے ہیں۔ چونکہ قدر انٹرفیس سے بندھی ہے، Set-DnsClientServerAddress ایسی چیز میں لکھتا ہے جو صرف اُس وقت تک موجود ہوتی ہے جب تک کنکشن موجود ہو۔

یہی ایک حقیقت VPN DNS کے گرد زیادہ تر الجھن کی وضاحت کرتی ہے۔ پروفائل کو منقطع حالت میں بھی دیکھا جا سکتا ہے، لیکن اشارہ کرنے کے لیے کوئی انٹرفیس نہیں، اس لیے وہ لاگ اِن اسکرپٹ جو VPN عرف پر cmdlet بلاتی ہے، کسی کے کنیکٹ ہونے سے پہلے ہی ناکام ہو جاتی ہے۔ یہ اُس تبدیلی کی بھی وضاحت کرتی ہے جو واپس ہوتی دکھائی دیتی ہے: کچھ واپس نہیں ہوا، انٹرفیس تباہ ہوا اور گیٹ وے کے بھیجے گئے قدروں کے ساتھ دوبارہ بنایا گیا۔

DNS چھونے سے پہلے عرف تلاش کریں

پروفائل کا نام اور انٹرفیس کا عرف عام طور پر ایک ہی سٹرنگ ہوتے ہیں، لیکن وہ ایک ہی شے نہیں۔ Get-VpnConnection پروفائلز کی فہرست دکھاتا ہے؛ Get-NetAdapter وہ انٹرفیس دکھاتا ہے جو Windows کے پاس واقعی ہیں۔ DNS cmdlet دوسرا چاہتے ہیں، اور یہ دونوں لوگوں کی توقع سے زیادہ بار مختلف ہوتے ہیں، خاص طور پر جب کلائنٹ اڈاپٹر کے نام میں "(RAS)" جیسی وضاحت شامل کرے۔

اگر پروفائل موجود نہ ہو، تو PowerShell مقامی اندراج بنا سکتا ہے۔ ٹنل کی قسم اور توثیق کو وہی ہونا چاہیے جو گیٹ وے پیش کرتا ہے، کیونکہ عدم مطابقت بناتے وقت نہیں، کنیکٹ ہوتے وقت ظاہر ہوتی ہے:

Add-VpnConnection -Name "Corporate" -ServerAddress vpn.example.net `
  -TunnelType Ikev2 -EncryptionLevel Required `
  -AuthenticationMethod Eap -AllUserConnection

ایک بار کنیکٹ کریں، پھر کوئی بھی DNS حکم لکھنے سے پہلے اصل عرف پڑھیں:

rasdial.exe "Corporate"
Get-NetAdapter | Where-Object InterfaceDescription -like "*VPN*"
Get-DnsClientServerAddress -InterfaceAlias "Corporate"

اوور رائیڈ کو صحیح ترتیب میں لاگو کریں

ترتیب نحو سے زیادہ اہم ہے۔ اڈاپٹر فعال ہونا چاہیے، عرف حل ہونا چاہیے، اور اکاؤنٹ کو انٹرفیس کی ترتیبات بدلنے کی اجازت ہونی چاہیے۔ فی صارف کنکشن عام طور پر سائن اِن صارف کی طرف سے تبدیلی قبول کرتا ہے؛ -AllUserConnection کے ساتھ بنایا گیا تمام صارفین کا کنکشن عام طور پر بلند shell مانگتا ہے۔

cmdlet بذات خود ایک سطر ہے، Microsoft کے Set-DnsClientServerAddress حوالہ میں درج:

Set-DnsClientServerAddress -InterfaceAlias "Corporate" -ServerAddresses 10.20.0.53,10.20.0.54
Get-DnsClientServerAddress -InterfaceAlias "Corporate" -AddressFamily IPv4

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

دوبارہ کنیکٹ ہونے سے تبدیلی کیوں منسوخ ہو سکتی ہے

اوور رائیڈ انٹرفیس کی ایک ہی مثال سے تعلق رکھتا ہے۔ جب کلائنٹ اڈاپٹر توڑ کر اگلے کنکشن پر دوبارہ بناتا ہے، تو بھیجی گئی قدریں دوبارہ لاگو ہوتی ہیں اور آپ کی فہرست ختم ہو جاتی ہے۔ بعض کلائنٹ ہر کنکشن پر انٹرفیس دوبارہ بناتے ہیں؛ دیگر سیشن بھر اُسے دوبارہ استعمال کرتے ہیں۔ Get-NetAdapter میں انٹرفیس اشاریہ دو کنکشنوں کے درمیان موازنہ کریں، آپ کو معلوم ہو جائے گا کہ آپ کے ہاں کون سا رویہ ہے۔

تین پائیدار جواب موجود ہیں، اور اُن کو ایک پر ایک رکھنا اپنی ہی خرابیاں پیدا کرتا ہے۔ کنکشن سے مخصوص DNS لاحقہ اور NRPT قاعدہ صرف اندرونی نام کی جگہ اندرونی حل کنندہ کو بھیجتے ہیں اور عوامی ناموں کو چھوڑ دیتے ہیں۔ VPN کنکشن پر لاگو گروپ پالیسی یا MDM ترتیب بغیر کسی اسکرپٹ کے کنیکٹ ہونے کے وقت DNS مقرر کرتی ہے۔ کنکشن کے واقعے پر ردِعمل دے کر cmdlet دوبارہ چلانے والا مقررہ کام کھردرا اختیار ہے، لیکن یہ کام کرتا ہے اور لاگ چھوڑتا ہے۔ DNS کے لیے ایک ہی مالک منتخب کریں اور لکھیں کہ کون سا ہے۔

ایک لیبل والے اندرونی ناموں کو بھی لاحقہ تلاش فہرست درکار ہے۔ Set-DnsClientGlobalSetting -SuffixSearchList پوری مشین پر لاگو ہوتا ہے، اس لیے کمپیوٹر کے ہر اڈاپٹر کے لیے، Ethernet سمیت، حل بدلتا ہے۔ تصویر میں جانے سے پہلے تجربہ گاہ کی مشین پر جانچیں۔

صرف ترتیب نہیں، حل کی بھی تصدیق کریں

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

Resolve-DnsName server01.corp.example -Server 10.20.0.53
Resolve-DnsName server01.corp.example

یہ تقسیم بتاتی ہے کہ خرابی کہاں ہے۔ براہِ راست استفسار جواب دیتا ہے اور معمول کا استفسار ناکام ہوتا ہے: اڈاپٹر کی ترتیب یا لاحقہ فہرست نافذ نہیں۔ دونوں ناکام ہوتے ہیں: حل کنندہ ٹنل کے ذریعے قابلِ رسائی نہیں، اس لیے DNS کو دوبارہ چھونے سے پہلے راستے اور فائر وال قواعد دیکھیں۔ براہِ راست استفسار ناکام ہوتا ہے جبکہ معمول کا کہیں اور سے جواب دیتا ہے: منقسم DNS غلط ترتیب دیا گیا ہے اور اندرونی نام کا جواب عوامی حل کنندہ دے رہا ہے، جو کنیکٹیویٹی مسئلے سے پہلے پالیسی کا مسئلہ ہے۔

جانچ دو بار چلائیں، ایک بار کنیکٹ ہونے کے فوراً بعد اور ایک بار منقطع ہو کر دوبارہ کنیکٹ ہونے کے بعد، اور دونوں مرتبہ کے Get-DnsClientServerAddress آؤٹ پٹ کا موازنہ کریں۔ اگر بھیجی گئی قدر دوسرے کنکشن پر واپس آ گئی، تو اوور رائیڈ اڈاپٹر کے ساتھ ہی جیا اور مرا، اور صرف پچھلے حصے کا NRPT یا پالیسی راستہ ہی قائم رہے گا۔ دونوں نقول اور کنکشن کے وقت کے نشان محفوظ رکھیں؛ یہ برقرار رہنے کا سوال ترمیم کے اگلے دور سے زیادہ تیزی سے طے کرتے ہیں۔