could not read Auth username from stdin يبدو كأنه مشكلة مصادقة، وهو ليس كذلك. حاول OpenVPN أن يطلب اسم المستخدم من المدخل القياسي، فلم يجد شيئًا مقروءًا، وتوقّف قبل أن يتصل بالخادم إطلاقًا. قد يكون الحساب صالحًا تمامًا؛ لكن العملية ببساطة لا تجد من يسأله.

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

اقرأ الخطأ كفشل محلي في الإدخال

عندما auth-user-pass يظهر دون وسيطة ملف، يتوقّع العميل أن يطلب الإدخال. في صدفة تفاعلية يعمل هذا الطلب لأن العملية تملك طرفية. أما تحت systemd أو مهمة cron أو حاوية، فالمدخل القياسي عادةً فارغ، وتعود القراءة فورًا بالخطأ الذي تراه.

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

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

امنح الخدمة مصدرًا مدعومًا لبيانات الاعتماد

المصدر المدعوم للتشغيل غير التفاعلي هو ملف بيانات اعتماد يُمرَّر كوسيطة إلى auth-user-pass. يُقرأ الملف كنص عادي: السطر الأول هو اسم المستخدم، والثاني كلمة المرور. أشر إليه بمسار مطلق مثل /etc/openvpn/client/creds كي لا يغيّر دليل عمل حساب الخدمة معنى التوجيه.

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

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

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

لماذا لن يساعد script-security

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

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

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

تحقق من المرحلة التالية بعد أن يقرأ العميل الملف

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

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

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

قائمة التحقق: مسار مطلق لبيانات الاعتماد، مقروء بحساب الخدمة، لا يتطلب طرفية، وscript-security عند حده الأدنى، وواجهة الإدارة فقط إذا كانت مرتبطة ومصادَقًا عليها، واستجابة الخادم الناتجة تُعامَل كحدث منفصل.

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