ملف بيانات اعتماد OpenVPN أم مقبس الإدارة: أيّهما نبرمج؟

السكربت الذي يشغّل OpenVPN ولا يتصل أبدًا ليس عادةً مشكلة شبكة: العميل جالس عند مطالبة بلا طرفية يرسمها عليها. OpenVPN لديه طريقتان مدعومتان بالضبط للإجابة عن تلك المطالبة بلا إنسان، ملف بيانات اعتماد خلف auth-user-pass ومقبس الإدارة، وهما غير قابلين للتبادل. الملف يكلّف توجيهًا واحدًا ويجيب عن مطالبة واحدة؛ المقبس يجيب عن كل مطالبة ويمنح أي شيء يستطيع فتح منفذ loopback قناة تحكّم غير موثّقة. أيّهما يناسب نشرك يعتمد على أي مطالبة تعوق فعلًا، وعلى أي سرّ تستطيع تحمّل تركه ساكنًا.

سمِّ المطالبة قبل أن تختار آلية

أربع مطالبات تبدو متطابقة على الطرفية. زوج الحساب يأتي من إعداد PAM أو auth-user-pass-verify على الخادم ويُجاب عنه بـ auth-user-pass. عبارة مرور المفتاح الخاص تنتمي إلى ملف المفتاح وتُقرأ عبر --askpass أو تُكتب يدويًا. حزمة PKCS#12 تطلب كلمة مرور خاصة بها. مصادقة الوسيط تستخدم ملف auth الذي يأخذه --http-proxy، لا بيانات اعتماد الحساب.

حين يعمل OpenVPN كطفل systemd أو PHP أو Node لا توجد طرفية، فأيٌّ من هذه يعوق بصمت. تبقى العملية هناك، ويتوقف السجل بعد سطر التشفير، وتنتهي الوحدة أخيرًا بمهلة؛ ذلك الصمت هو سبب إضافة حلقة إعادة محاولة أو sleep بدلًا من النظر في المطالبة المعلّقة. مقبس الإدارة وحده يستطيع الإجابة عن الأربع. ملف بيانات الاعتماد يجيب عن الأولى ولا شيء غيرها.

auth-user-pass: ملف واحد، مطالبة واحدة

يحمل الملف اسم المستخدم في السطر الأول وكلمة المرور في السطر الثاني، ولا شيء آخر: لا علامات اقتباس، ولا أسماء مفاتيح، ولا تعليق. اضبط الوضع 600 واجعل المالك الحساب الذي يشغّل openvpn، وهو في الخدمة غالبًا مستخدم مخصص لا تسجيل دخولك. ملف مملوك لـ root تحت /root هو الفرق بين أمر يعمل في صدفتك ووحدة تفشل عند الإقلاع.

تفصيلان يحوّلان ملفًا صحيحًا إلى مطالبة. المحرر الذي يحفظ CRLF يترك محرف إرجاع عالقًا بكلمة المرور، فيرفض الخادم كلمة مرور تبدو صحيحة في الملف؛ افحص بـ cat -A أو od -c بدلًا من العين. و auth-user-pass بلا وسيط داخل الملف الشخصي يعني «اسأل المستخدم» بحكم التصميم، وقد لا يتجاوزه توجيه ثانٍ على سطر الأوامر، لأن الملف الشخصي يُحلَّل حيث يقع.

ترتيب الخيارات هو الفخ الثالث، وهو خاص بالإصدار. بعض إصدارات OpenVPN 2.4 تتجاهل --auth-user-pass عندما يظهر قبل --config، فالخياران نفسهما بترتيب آخر يتصلان. ضع التوجيه داخل الملف الشخصي، أو بعد --config على سطر الأوامر، وابحث في الملف الشخصي عن كل ظهور قبل تغيير أي شيء آخر.

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

مقبس الإدارة: كل مطالبة، سطح أكبر

ابدأ العميل بمستمع وصرّح صراحةً بأن المطالبات ستُبلَّغ عليه، باستخدام التوجيهات الموثقة في دليل OpenVPN 2.6:

management 127.0.0.1 3030
management-query-passwords

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

exec 3<>/dev/tcp/127.0.0.1/3030
while read -r -u 3 line; do
  case "$line" in
    *"Need 'Auth' username/password"*)
      echo 'username "Auth" alice' >&3
      echo 'password "Auth" secret' >&3 ;;
    *"Need 'Private Key' password"*)
      echo 'password "Private Key" secret' >&3 ;;
  esac
done

الحدّ هو النقل. بروتوكول الإدارة نص صريح فوق TCP على loopback، فلا يجوز نشر المستمع على عنوان LAN أو نفق ليصل إليه متحكم بعيد؛ المتحكم البعيد يعني تحويل SSH، لا ربطًا أوسع. الشيطان المجتمعي يقبل أيضًا عميل إدارة واحدًا في كل مرة، فلا يستطيع GUI أو مراقب مشاركة المقبس مع سكربتك. الاتصال الثاني يُرفض لا يُصفّ، ويبدو الفشل كسكربت أصمّ.

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

أيُّهما يناسب النشر

اختر ملف بيانات الاعتماد عندما تكون المطالبة الوحيدة زوج الحساب، ويعمل العميل كخدمة بمالك مستقر، وتستطيع إبقاء ملف 600 خارج نسخ احتياطية لا تتحكم بها. اختر مقبس الإدارة عندما تكون عبارة مرور مفتاح أو كلمة مرور PKCS#12 في اللعبة، أو عندما يشرف الغلاف على العملية أصلًا، أو عندما تحتاج إلى مراقبة الحالة والمطالبات أثناء تنقيح إعادة اتصال.

شرطان يحرّكان القرار. إذا كان الغلاف /bin/sh، أو وحدة systemd تستدعي الملف التنفيذي مباشرة، أو حاوية دنيا، فإن غراء المقبس الخاص بـ bash غير متاح والملف هو الجواب الأرخص. إذا كان السرّ يدور كثيرًا، فلا أحد الملفين موطن جيد له: استعلم عن حلقة مفاتيح من غلاف صغير ودع الوحدة تستدعي الغلاف، فيبقى التدوير في مكان واحد وكلمة المرور خارج تاريخ الصدفة.

استبدال العملية يقف بين الاثنين ولا ينتمي إلى أيّهما. الأمر الواحد أدناه يعمل لأن bash يوسّعه قبل أن يبدأ openvpn، لا لأن العميل يفهم الصياغة:

openvpn --config client.ovpn --auth-user-pass <(printf "%s
%s
" "$USER" "$PASS")

ينكسر تحت /bin/sh، وفي وحدة تتجاوز الصدفة، وفي صور بلا bash أو /dev/fd. أبقِه للاختبار التفاعلي، لا كعقد تعتمد عليه خدمة.

احمِ السرّ، ثم تحقّق من السجل

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

التشغيل الصحيح يُظهر اكتمال تسلسل المطالبات ووصول الجلسة إلى «Initialization Sequence Completed». إذا توقف العميل عند المطالبة نفسها فقد فشل التطابق: اطبع الأسطر الدقيقة التي أرسلها المقبس، وافحص الاقتباس واسم المطالبة، وأصلح النمط بدلًا من إضافة sleep. النفق الذي يبلّغ عن نجاح ولا يحمل شيئًا مشكلة توجيه أو push، لا مشكلة بيانات اعتماد.

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