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

العميل يحلّ اسمًا قبل أن يتصل

اتصال VPN أصلي في Windows يقرأ ملفه الشخصي، ويحلّ عنوان الخادم، ويبدأ النفق، ثم يصادق بعد ذلك فقط. الخطأ 868 ينتمي إلى الخطوة الثانية. ولأن الخطوات اللاحقة لا تُنفَّذ أبدًا، قد تبدو النافذة كأنها مشكلة بيانات اعتماد رغم أن البحث فشل أولًا.

هذا الترتيب مفيد لأنه يضيّق الطبقة التي يجب فحصها. عندما يعمل الملف نفسه من شبكة ويفشل من أخرى، يكون الفرق عادةً في حل الأسماء لا في نوع النفق أو الحساب. اختبر البحث حيث يحدث الفشل، لا حيث بُني الملف.

أي اسم، حين يعرض الحقل عنوانًا

اقرأ القيمة المخزّنة بدل الاسم المعروض. تسمية الاتصال ليست عنوان خادمه، ومدخلان بتسميتين متشابهتين يجعلانك تتبع الخطأ:

Get-VpnConnection -Name "Work VPN" |
    Select-Object Name, ServerAddress, TunnelType

إن كان الملف مُهيّأً لكل المستخدمين، فاستعلم ذلك النطاق أيضًا باستخدام -AllUserConnection. ثم حلّ القيمة التي طبعها الأمر بالضبط، من الشبكة التي يحدث فيها الفشل. استخدم البوابة الموثّقة لدى المشغّل، لا اسم التطبيق الداخلي الذي لا يُحلّ إلا بعد قيام النفق. ذلك الاستعلام الثاني يفشل لسبب متوقع ولا يخبرك شيئًا عن الاتصال:

Resolve-DnsName vpn.example.com

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

نمط إعادة الاتصال في Windows 7

يصف الموضوع الذي يقف خلف هذا الخطأ أجهزة اتصلت مرة ثم فشلت في محاولة لاحقة بالخطأ 868، دون أن يتغير شيء في الملف. أفاد مشاركون بأن إعادة تشغيل خدمة Remote Access Connection Manager أو تسجيل الخروج والدخول من جديد أعادت الاتصال مؤقتًا. هذه حلول مؤقتة، لا سبب جذري مُثبت.

اعتبر ذلك النمط فرضية منفصلة. إعادة التشغيل تعيد ضبط حالة العميل، لذا فالنجاح المؤقت بعدها لا يثبت أن سجل DNS كان خاطئًا:

ObservationPoints towardWhat to do next
Fails from one network, works from anotherName resolution on that pathResolve the stored name from both networks
Fails after a disconnect, works after service restartClient state, not DNSRecord the sequence for the vendor
Fails only on a newly provisioned machineProfile content or scopeCompare ServerAddress and TunnelType

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

ما يجب جمعه للمسؤول

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

الحل المؤقت من الإصدارات الأقدم دليل على أن السلوك كان موجودًا، وليس وعدًا بأن إعادة تشغيل الخدمة نفسها ستصلح جهازًا حاليًا. واستبدال اسم مضيف موثّق بعنوان حرفي ليس إصلاحًا أيضًا.

بعض الملفات تتوقع هوية خادم تطابق الاسم المُهيّأ، لذا قد يقايض حل رقمي خطأً بخطأ آخر. إذا كان الاسم يجب أن يبقى، فأصلح مسار الحل لا نص الملف. وفي كل الحالات، سجّل ما غيّرته ولماذا.

مقالات ذات صلة