OpenVPN push-peer-info: وسم العملاء دون منح الوصول

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

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

عيّن المتغيّر وفعّل المسار

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

setenv UV_DEPLOY field-support
push-peer-info

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

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

اقرأ الحقل من خطاف على الخادم

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

#!/bin/sh
# /etc/openvpn/server/hooks/label.sh
printf '%s %s\n' "$common_name" "${UV_DEPLOY:-unset}" \
  >> /var/log/openvpn/deploy-labels.log

اقرأ المتغيّر عبر البيئة بدلاً من تحليل السجل، وامنحه دائماً قيمة افتراضية. يُبقي ${UV_DEPLOY:-unset} النص عاملاً مع العملاء الذين لا يرسلون الحقل أبداً، وهي الحالة الطبيعية أثناء طرح تدريجي. لا تُفرغ البيئة كلها في سجل للعثور على الاسم؛ فهي تحتوي أكثر بكثير من الوسم، بما في ذلك قيم لم تقصد الاحتفاظ بها.

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

تحقق مما وصل فعلاً

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

tail -n 5 /var/log/openvpn/deploy-labels.log
# field-support deployed-client-07
# unset         legacy-laptop-02

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

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

تعامل مع الوسم كادعاء لا كهوية

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

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

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

case "${UV_DEPLOY:-}" in
  field-support|field-qa|lab) : ;;
  *) UV_DEPLOY=unknown ;;
esac

تراجع عنه بنظافة

إزالة الميزة هي حذفان وتحقق واحد. احذف سطر setenv وسطر push-peer-info من ملف تعريف العميل، ثم أزل أو عطّل الخطاف وهدفه السجلي على الخادم.

grep -rn 'UV_DEPLOY\|push-peer-info' /etc/openvpn/
tail -n 3 /var/log/openvpn/deploy-labels.log

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

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