غياب طلب TOTP في OpenConnect داخل NetworkManager: أربع فحوص

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

الفحص الأول: اقرأ أين توقفت المصادقة

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

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

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

الفحص الثاني: استخدم العميل الذي يملك التحدي

ينفّذ OpenConnect نفسه المحادثة الكاملة، بما في ذلك جولة التحدي. وتشغيله مباشرة هو الطريقة الأكثر قدرة على التنبؤ للتأكد من أن الحساب والبوابة يعملان:

sudo openconnect --protocol=anyconnect --useragent=AnyConnect vpn.example.net

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

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

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

الفحص الثالث: تحقق مما إذا كانت إضافتك تعرض وضع TOTP

تعرض بعض بنيات NetworkManager OpenConnect وضع رمز وحقل وكيل مستخدم في تبويب الهوية الخاص بالاتصال. اضبط وكيل المستخدم على القيمة التي تتوقعها البوابة، واختر الإدخال اليدوي لـ TOTP، واحفظ الاتصال.

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

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

الفحص الرابع: عامل الرمز المولّد كمقايضة

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

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

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

تأكد من البوابة والحساب نفسيهما

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

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

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