مسار جهاز OpenVPN: مالك الإعداد أم سكربت التشغيل؟
قد يختفي مسار فرعي صمد بعد إعادة تشغيل واحدة بعد حفظ من واجهة رسومية أو تحديث للبرنامج الثابت. قارن مالك الإعداد المدعوم مع سكربت ترقيع.
تضيف مساراً فرعياً، فيعمل، ثم يزيله تحديث للبرنامج الثابت أو حفظ من واجهة الويب. يبدو إصلاحان في تلك اللحظة معقولين بالقدر نفسه: وضع المسار في مصدر الإعداد المدعوم في الجهاز، أو إلحاقه بالملف المُولَّد من سكربت تشغيل. يتصرفان بالطريقة نفسها لمدة أسبوع ويختلفان عند الترقية الثانية. تقارن هذه المقالة ما يملكه كل منهما فعلاً.
المرشحان يملكان أشياء مختلفة
مصدر الإعداد المدعوم هو كل ما يعده الجهاز مدخلاً: حقل في الواجهة الرسومية، أو ملف تعريف مستورد، أو دليل موثّق لكل عميل، أو قاعدة إعدادات يقرأها حزمة الإدارة. الملف المُولَّد server.conf هو مخرج. تحرير المخرج ينجح حتى يعمل المولّد مرة أخرى، وهذا يحدث عند الحفظ وعند إعادة التشغيل وعند الترقية.
يقوم نهج السكربت بترقيع ذلك المخرج بعد انتهاء المولّد. إنه أسلوب مشروع في مختبر، وهو الافتراضي الخاطئ لمكتب فرعي، لأنه يجعل المسار يعتمد على مطابقة النص بدلاً من حقل موثّق.
| Question | Supported config source | Post-generation script |
|---|---|---|
| Survives a GUI save | Yes | Only if the save does not regenerate the file |
| Survives a package upgrade | Usually, when the field is documented | No guarantee; the wrapper can be replaced |
| Supportable by the vendor | Yes | No |
| Obvious to the next admin | Yes, it is in the UI | No, it lives in a wrapper |
ما يعيد الجهاز توليده، ومتى
تحتفظ حزم الإدارة عادةً بالإعدادات في قاعدة بيانات أو مجموعة قوالب، وتصوغ إعداد الخدمة عند البدء. كثيراً ما يعيد الحفظ من واجهة الويب كتابة الملف كله بدلاً من ترقيع سطر واحد. إذا كان تغييرك يعيش في ذلك الملف، فقد اختفى الآن، ولا يسجّل شيء تحذيراً لأن شيئاً لم يُفقد من وجهة نظر الجهاز.
لأغلفة بدء التشغيل نمط فشل ثانٍ. الأمر grep بحثاً عن توجيه بتباعد معين يتوقف عن المطابقة بعد تغيير القالب، ولا يفعل السكربت شيئاً بصمت. والأسوأ أن تحديث البرنامج الثابت قد يستبدل الغلاف بإصدار جديد، آخذاً الترقيع معه. عندئذ لديك مسار كان موجوداً سنة واختفى خلال صيانة لم يربطها أحد بالتوجيه.
ما يجب أن يعبّر عنه المالك المدعوم
بادئة فرع تحتاج ثلاث عبارات لا واحدة. على العميل أن يتعلم المسار، وعلى الخادم أن يعرف أي عميل موثّق يملك البادئة، وعلى جانب الفرع أن يعيد حركة المرور إلى عنوان النفق الذي أُعطي له. بمصطلحات OpenVPN يعني ذلك route مدفوعاً، ثم iroute مطابقاً مرتبطاً بالعميل، ثم مسار عودة على الجانب الآخر.
هنا تضلّل واجهات الأجهزة. مربع اختيار بعنوان «السماح للعملاء بالوصول إلى شبكة الخادم المحلية» يصف حركة مرور نحو شبكة الخادم نفسها. فرعك في الاتجاه المعاكس: شبكة خلف عميل واحد، يمكن الوصول إليها من جانب الخادم. العنوان نفسه لا يعني دعم ذلك، والتوجيه الصالح في ملف ليس وعداً بأن الحزمة ستحافظ عليه.
عندما لا يوجد تحكم مدعوم
أحياناً لا يستطيع الإصدار المثبّت فعلاً التعبير عن مسار خاص بنظير. عندئذ تكون الخيارات الصادقة بوابة أخرى تتحكم بها، أو وضع موقع-إلى-موقع مدعوم على الطرفين. على الطرفين أن يتحدثا به. صفحة منتج تقول موقع-إلى-موقع لا تجعل ملف تعريف OpenVPN عشوائياً قابلاً للتبادل مع نفق بروتوكول آخر، وفرض ذلك الاقتران ينتج عادةً نفقاً نصف متصل يبدو جيداً في صفحة الحالة.
اختر الخيار الذي تستطيع وصفه في جملة واحدة لمن يرث الشبكة. إذا كان الجواب يتطلب ذكر مسار سكربت ونمط نصي، فالتصميم هش بالفعل.
اجعل النية قابلة للتدقيق
سجّل العقد خارج الجهاز: هوية العميل الفعلية، والبادئة، وبوابة العودة، والحقل المدعوم الذي يوفر كلاً منها. صدّر الإعداد عبر الآلية المدعومة ليكون لإعادة البناء مرجع، وتحقق من الخدمة بعد إعادة الاتصال وإعادة التشغيل والترقية وليس بعد التغيير فقط.
قارن النتيجة المولّدة بذلك السجل عندما ينكسر شيء، بدلاً من استعادة سطر غير مفسّر والأمل في أن ينجح.مرجع OpenVPN 2.6 هو المكان المناسب لتأكيد كيفية تفاعل route و iroute قبل أن تجادل واجهة.
قائمة التحقق للتغيير التالي: سمِّ المالك، واذكر العقد الثلاثي، وصدّر النية، وأعد الاختبار بعد أحداث دورة حياة الجهاز نفسها لا بعد تحريرك.