OpenVPN يقرأ كلمة المرور من الطرفية لا من stdin

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

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

المطالبة لا تأتي من المدخل القياسي

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

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

المنفذ الأول: ملف بيانات اعتماد من سطرين

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

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

المنفذ الثاني: askpass لعبارة مرور المفتاح

المفتاح الخاص المحمي بعبارة مرور يثير مطالبة ثانية مختلفة، ولها جوابها الملفي الخاص: خيار askpass يقرأ عبارة المرور من السطر الأول في ملف. في الأنفاق المبنية على SSH المكافئ هو برنامج askpass ينفذه العميل، ويصبح خرجه القياسي هو السر.

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

المنفذ الثالث: واجهة سطر الأوامر الخاصة بعميل البوابة

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

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

عندما يحتاج التدفق إلى طرفية زائفة

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

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

أسرار تتسرب، وأين تختبئ

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

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