الخطأ 868 مع عنوان IP؟ ما يحلّه Windows أولًا
تذكر النافذة فشل بحث بينما يبدو الملف الشخصي رقميًا. اقرأ حقل الملف الفعلي، ثم افصل مشكلة الاسم عن خلل قديم في إعادة الاتصال.
تُبلغ النافذة أن اسم الخادم تعذّر حلّه، وحقل الملف الشخصي الذي تحدّق فيه عنوان. هذا الجمع ليس تناقضًا: العميل يحلّ شيئًا غير القيمة التي تظن أنه يقرأها. حدّد ما يتصل به فعليًا قبل أن تستنتج أن 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 كان خاطئًا:
| Observation | Points toward | What to do next |
|---|---|---|
| Fails from one network, works from another | Name resolution on that path | Resolve the stored name from both networks |
| Fails after a disconnect, works after service restart | Client state, not DNS | Record the sequence for the vendor |
| Fails only on a newly provisioned machine | Profile content or scope | Compare ServerAddress and TunnelType |
اقرأ الجدول كمجموعة ملاحظات مميّزة لا كتشخيص. الصف الأول مشكلة اسم، والثاني حالة عميل، والثالث ملف لم يكن صحيحًا قط. كل واحد منها يقود إلى شخص مختلف وإصلاح مختلف.
ما يجب جمعه للمسؤول
دوّن اسم الملف، والعنوان المخزّن، ونوع النفق، والشبكة التي كان عليها العميل، وما إذا كان الفشل قد تلا قطع الاتصال. ذلك السجل يفصل فشل بحث حقيقيًا عن سلوك إعادة الاتصال التاريخي دون أن يضطر أحد إلى التخمين. واحتفظ أيضًا بسجل أحداث العميل حول المحاولة.
الحل المؤقت من الإصدارات الأقدم دليل على أن السلوك كان موجودًا، وليس وعدًا بأن إعادة تشغيل الخدمة نفسها ستصلح جهازًا حاليًا. واستبدال اسم مضيف موثّق بعنوان حرفي ليس إصلاحًا أيضًا.
بعض الملفات تتوقع هوية خادم تطابق الاسم المُهيّأ، لذا قد يقايض حل رقمي خطأً بخطأ آخر. إذا كان الاسم يجب أن يبقى، فأصلح مسار الحل لا نص الملف. وفي كل الحالات، سجّل ما غيّرته ولماذا.