مقبس إدارة OpenVPN: قناة تحكم لا نقطة مقاييس

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

الاعتقاد، وما يكلفه

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

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

ما يملكه العميل المقبول فعليًا

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

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

مقبس مملوك، لا مقبس مفتوح

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

management /run/openvpn/office-management.sock unix /etc/openvpn/management.password
management-client-user vpn-observer
management-client-group vpn-observer

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

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

نشره عبر TCP ليس التصميم نفسه

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

كلمة مرور على نقل نصي صريح هي مصادقة بلا سرية، وهذا المزيج أسوأ مما يبدو لأنه يبدو محميًا.

اعتماديات بدء التشغيل التي لم تطلبها

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

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

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

كيف يبدو القبول

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

توضح وثائق واجهة الإدارة نموذج العميل الواحد والطبيعة ذات الامتيازات للبروتوكول، وهو الجزء الجدير بالقراءة قبل أن توجّه لوحة معلومات إليه.