إصلاح فشل AnyConnect في تهيئة النظام الفرعي للاتصال

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

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

اقرأ التوقيت قبل أن تغيّر أي شيء

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

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

الخطوة 1: تأكد من أن خدمة الوكيل تعمل

النافذة التي تنقر عليها واجهة أمامية؛ أما العمل فيجري في خدمة Cisco AnyConnect Secure Mobility Agent، المسجّلة باسم vpnagent. إذا كانت تلك الخدمة متوقفة أو معطّلة، فإن الواجهة الرسومية لا تجد ما تتحدث إليه وتُبلغ عن فشل التهيئة هذا بالضبط. تحقق من الحالة ونوع بدء التشغيل من موجه PowerShell بصلاحيات مرتفعة:

Get-Service vpnagent | Select-Object Name, Status, StartType
sc.exe qc vpnagent
net start vpnagent

المثبّت الذي احترم نوع بدء تشغيل يدويًا سابقًا هو السبب المعتاد لانتهاء الحال إلى التعطيل، لذا تحقق من StartType بدلًا من مجرد الضغط على بدء. إذا بدأت الخدمة وتوقفت خلال ثوانٍ، فاقرأ سجل النظام بحثًا عن إدخالات Service Control Manager قبل النقر على إصلاح:

Get-WinEvent -FilterHashtable @{LogName="System"; ProviderName="Service Control Manager"} -MaxEvents 40

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

الخطوة 2: امسح حالة عدم الاتصال التي يبلّغ عنها مكدّس HTTP

ينزّل العميل ملف تعريفه ويقيّم السياسة عبر مكوّنات HTTP في Windows، لذا فإن علامة عدم الاتصال المضبوطة في إعدادات إنترنت للمستخدم قد تكسر التهيئة بينما لا تزال كل المتصفحات تحمّل الصفحات. تحقق من القيمة مباشرة:

Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" -Name GlobalUserOffline

تعني القيمة 1 أن مكدّس WinINet يخبر المستدعين بأن الجهاز لا يملك اتصالًا، وهي حالة تُضبط عادةً من عنصر قائمة العمل دون اتصال في Internet Explorer أو من نص برمجي للتشغيل الآلي. أعدها إلى 0، ثم سجّل الخروج والدخول مجددًا، وأعد محاولة الاتصال قبل تغيير أي شيء آخر.

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

الخطوة 3: حرّر المحول الافتراضي من Hyper-V أو ICS

يمكن لدورين في Windows أن يحتجزا القطع التي يحتاجها العميل لإنشاء محوله. Hyper-V هو الأول: فعند تشغيل خدمات المحول الافتراضي، قد يفشل إنشاء المحول بطرق تظهر على شكل هذا الخطأ. إيقاف الخدمات إجراء تشخيصي وليس إصلاحًا:

Get-Service vmms, vmcompute | Stop-Service
Get-NetAdapter | Where-Object InterfaceDescription -like "*Hyper-V*"

إذا اتصل العميل مع إيقاف تلك الخدمات، فقد تأكد التعارض وتعرف الآن ما يجب التفاوض عليه مع مالك مضيف Hyper-V. أعد تشغيلها بعد ذلك إلا إذا لم يعد الجهاز يحتاج إلى المحاكاة الافتراضية.

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

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

تحقق، ثم تراجع عمّا لم تكن بحاجة إليه

التحقق ليس الدرع الأخضر في شريط المهام. تأكد من وجود المحول وحمله لعنوان ومروره للحركة: Get-NetAdapter -Name "Cisco AnyConnect*" يجب أن يُظهره قيد التشغيل، وipconfig /all يجب أن يُظهر العنوان المعيّن وخوادم DNS، ويجب أن يُحلّ طلب حقيقي لاسم داخلي عبر النفق لا عبر المحلل المحلي.

احتفظ بقائمة قصيرة بكل تغيير أثناء العمل، مع القيمة التي وجدتها والقيمة التي ضبطتها. إذا عمل الاتصال بعد الخطوة الثالثة، فأعد خدمات Hyper-V واختبر مجددًا قبل إغلاق التذكرة، لأن حلًا مؤقتًا يعطّل المحاكاة الافتراضية بهدوء سيلغيه أول مسؤول يلاحظه.

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