تعيين DNS على محول VPN في Windows باستخدام PowerShell ثم التحقق

لا يخزّن اتصال VPN في Windows خوادم DNS في ملف التعريف الذي تعدّله في الإعدادات. عند ظهور النفق، يتفاوض العميل على إعدادات IP مع البوابة، فتدفع البوابة قائمة محللات أسماء، ويطبّقها Windows على محول النفق. هذا المحول واجهة منفصلة عن Wi-Fi أو Ethernet، والقائمة تخص الواجهة لا ملف التعريف. وبعد أن تعرف الكائن الذي يملك القيمة، يصبح تجاوزها في PowerShell أمرًا واحدًا؛ أما جعل التجاوز يصمد بعد إعادة الاتصال فهو الجزء الذي يحتاج إلى قرار.

أي كائن يملك العنوان

ينشئ RAS محول النفق عند نجاح الاتصال ويحذفه عند انقطاع الاتصال. خوادم DNS التي تراها في ipconfig /all تصل أثناء تبادل الإعدادات ذلك، إلى جانب عناوين IPv4 وIPv6 والمسارات. ولأن القيمة مرتبطة بالواجهة، فإن Set-DnsClientServerAddress يكتب في شيء لا وجود له إلا ما دام الاتصال قائمًا.

تفسّر هذه الحقيقة الواحدة معظم الالتباس حول DNS في VPN. يمكن فحص ملف تعريف وهو غير متصل، لكن لا توجد واجهة للإشارة إليها، لذا يفشل سكربت تسجيل الدخول الذي يستدعي الأمر مقابل الاسم المستعار لـ VPN قبل أن يتصل أي شخص. وتفسّر أيضًا تغييرًا يبدو أنه يتراجع: لم يتراجع شيء، بل دُمّرت الواجهة وأُعيد بناؤها بالقيم التي دفعتها البوابة.

اعثر على الاسم المستعار قبل أن تمسّ DNS

اسم ملف التعريف والاسم المستعار للواجهة عادةً السلسلة نفسها، لكنهما ليسا الكائن نفسه. Get-VpnConnection يسرد ملفات التعريف؛ Get-NetAdapter يسرد الواجهات التي يملكها Windows فعليًا. أوامر DNS تريد الثاني، والاثنان يختلفان أكثر مما يتوقع الناس، خاصة عندما يضيف العميل واصفًا مثل "(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 فيحتاج عمومًا إلى صدفة مرفوعة الصلاحيات.

الأمر نفسه سطر واحد، موثّق في مرجع Set-DnsClientServerAddress:

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

هناك نمطا فشل يستحقان التعرّف عليهما بالنظر. الاسم المستعار الخاطئ ينتج خطأً من الأمر، وهذه النتيجة الجيدة، لأن الصمت سيكون أسوأ. الأمر الصحيح بلا أثر ظاهر يعني عادةً أنك تنظر إلى المحول الخطأ: محول نفق متبقٍّ من عميل آخر، أو بطاقة شبكة فعلية بوصف مشابه، أو محول افتراضي ثانٍ أنشأته أداة شبكات معزولة.

لماذا قد يلغي إعادة الاتصال التغيير

التجاوز يخص نسخة واجهة واحدة. عندما يهدم العميل المحول ويعيد بناءه عند الاتصال التالي، تُطبّق القيم المدفوعة مرة أخرى وتختفي قائمتك. بعض العملاء يعيدون إنشاء الواجهة عند كل اتصال؛ وآخرون يعيدون استخدامها طوال الجلسة. قارن فهرس الواجهة في Get-NetAdapter عبر اتصالين وستعرف أي سلوك لديك.

توجد ثلاثة حلول دائمة، وتكديسها يخلق أخطاءً خاصة به. لاحقة DNS خاصة بالاتصال مع قاعدة NRPT ترسل النطاق الداخلي فقط إلى المحلل الداخلي وتترك الأسماء العامة وشأنها. إعداد Group Policy أو MDM مطبّق على اتصال VPN يعيّن DNS وقت الاتصال دون أي سكربت. مهمة مجدولة تتفاعل مع حدث الاتصال وتعید تشغيل الأمر هي الخيار الفج، لكنه يعمل ويترك سجلًا. اختر مالكًا واحدًا لـ 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 أو السياسة من القسم السابق. احتفظ بكلا السجلين وطوابع وقت الاتصال؛ فهي تحسم سؤال هل يثبت أسرع من جولة تعديلات أخرى.