خادم DNS الخطأ في VPN على Windows: المقياس أم ترتيب الربط أم اللاحقة
ثلاث آليات في 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استبدل 11 بمعرّف ifIndex لمحوّل النفق من السطر أعلاه؛ وإذا كان 11 هو محوّل الشبكة المحلية، فإن الأمر نفسه يخفض المسار الخطأ. أما رفع محوّل الشبكة المحلية فيصل إلى الترتيب نفسه من الجهة الأخرى: 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, InterfaceMetricتعطيل IPv6 على محوّل الشبكة المحلية يزيل ذلك المسار والبروتوكول معه؛ أما تغيير المقياس على واجهة IPv6، أو قاعدة NRPT لنطاق الشركة، فيُبقي العائلة ويُصلح التفضيل. اختر الأضيق ما لم تكن قد قررت أن ذلك الرابط يجب ألا يحمل IPv6.
تحقّق مع تسمية المصدر، واحتفظ بمالك واحد
تحقّق بأدوات تُبلّغ عن المصدر الفعّال، لا مجرد ما إذا كانت صفحة ما تُحمّل:
ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type Aثم افصل الترشيح عن الاختيار، لأنهما يبدوان متطابقين من داخل التطبيق. خيار block-outside-dns في OpenVPN يحجب المنفذ 53 على المحوّلات الأخرى؛ لكنه لا يختار محللًا. إذا فشل كل استعلام الآن، فقد يحجب مرشّح الخادم الوحيد الذي يمكن الوصول إليه؛ وإذا كان المحلل المضبوط يُتجاهل، فالترتيب أو قاعدة النطاق خطأ. تغيير الاثنين معًا يجعل استعلامًا محجوبًا واستعلامًا متجاهلًا غير قابلين للتمييز.
احتفظ بمالك واحد لسياسة DNS: ملف VPN، أو نهج إدارة، أو قاعدة NRPT، وليس اثنين منها. وقبل أن تُغلق الأمر:
- المحلل المدفوع يجيب عندما يُسمّى صراحةً، والبحث العادي يستخدمه.
- القاعدة أو المقياس الذي غيّرته يغطي عائلة العناوين التي تحمل الاستعلامات فعلًا.
- الإعداد يصمد بعد قطع الاتصال وإعادة توصيله، أو أنك نقلته إلى الملف المخزّن.
- آلية واحدة فقط هي المرجع، والأخرى تُركت كما كانت.
تعامل مع الترتيب كحالة بيئية لا كشيء تنتهي منه. أعد فحصه بعد إعادة الاتصال وبعد تحديث Windows يمس حزمة الشبكة، لأن أيًّا منهما قد يعيد المحوّل الفيزيائي إلى المقدمة.