FortiClient متوقف عند 98%: عطّل IPv6 على ذلك المحول

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

أربع خطوات، وأولها قراءة السجل لا الشريط.

ما الذي يخبر عنه عدّاد 98% فعلاً

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

وثّقت Fortinet هذا العرَض مقابل سبب واحد من جانب العميل: تمكين IPv6 على المحول الذي يستخدمه العميل. وهذا يجعل إعداد المحول أول ما يجب اختباره، لا تفسيراً شاملاً لكل SSL-VPN متوقف.

الخطوة 1: اقرأ السجل قبل الشريط

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

إذا أظهر السجل تسجيل دخول مكتملاً يتبعه لا شيء، فأنت في الإعداد المحلي والمحول مشتبه به مشروع.

الخطوة 2: احصر تغيير IPv6 في محول واحد

التغيير يخص المحول، لا الجهاز. في خصائص المحول في Windows يعني ذلك إلغاء Internet Protocol Version 6 (TCP/IPv6) على الواجهة المحددة، ومن صدفة أوامر هو Disable-NetAdapterBinding -Name "Ethernet 2" -ComponentID ms_tcpip6. تحقّق من الحالة باستخدام Get-NetAdapterBinding -ComponentID ms_tcpip6 قبل إعادة الاتصال. ثم أعد الاتصال وراقب هل يتجاوز الشريط 98% بدلاً من التوقف عنده.

حدّد النطاق أولاً ثم اختبر. تعطيل IPv6 عالمياً تغيير أكبر مما تتطلبه المسألة، ويؤثر في خدمات لم تكن تنوي المساس بها.

الخطوة 3: تحقّق مما كان التوقف يخفيه

النفق الذي يتصل ليس نفقاً يعمل. افحص العنوان الذي أسنده العميل، والمسارات التي ثبّتها الملف الشخصي، وتحليل الأسماء لمضيف داخلي واحد: Resolve-DnsName files.corp.example. العميل الذي يتصل ولا يحل أي اسم لديه مشكلة DNS، ومن السهل أن يُقرأ ذلك خطأً على أنه العطل نفسه يعود.

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

الخطوة 4: اجعل الإصلاح قابلاً للتكرار

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

الإصلاح الذي يوجد في ذاكرة مهندس واحد فقط هو إصلاح يعود في الربع القادم.

إذا ظل الشريط يتوقف عند 98% مع تعطيل IPv6، فلم تعد ملاحظة المورّد تفسّره، والسجل هو دليلك التالي. توقّف عن علاج العرَض وعُد إلى عدّاد المراحل.