یک drop-in در OpenVPN همهٔ تونل‌ها را تغییر داد: نمونه در برابر قالب

سیاست راه‌اندازی مجددی که برای یک تونل اضافه شده، شروع می‌کند به اعمال شدن روی هر تونل دستگاه. این باگ systemd نیست؛ تفاوت میان drop-in نمونه و drop-in قالب است. مسیری که فایل را زیر آن می‌نویسید تعیین می‌کند چند سرویس آن را به ارث می‌برند.

دامنه را پیش از تنظیم انتخاب کنید. دو پوشه تقریباً یکسان به نظر می‌رسند و فقط یکی از آن‌ها به نمونه‌ای که منظورتان بود محدود است.

نشانه: یک ویرایش، همهٔ تونل‌ها

drop-in مخصوص یک نمونه زیر پوشه‌ای می‌نشیند که به نام نمونهٔ کامل نام‌گذاری شده است، مانند [email protected]. drop-in قالب زیر [email protected] می‌نشیند، با علامت @ و بدون نام نمونه میان آن‌ها. اولی فقط به office اعمال می‌شود. دومی به هر سرویسی اعمال می‌شود که از آن قالب ساخته شود.

شکل قالب به قالب جداگانهٔ [email protected] نمی‌رسد و به سرویس‌های بی‌ربطی که openvpn در نامشان دارند هم نمی‌رسد.

پوشه‌ای را انتخاب کنید که با دامنه می‌خواند

هر دو پوشه زیر /etc/systemd/system/ قرار دارند. اگر مؤلفهٔ آخر system را حذف کنید، مسیری ساخته می‌شود که systemd آن را به‌عنوان بازنویسی سیستم نمی‌خواند، و این روشی خاموش برای بی‌اثر کردن فایلی است که درست به نظر می‌رسد. مسیر کامل را یک بار بنویسید و دوباره به کار ببرید.

drop-in به سرصفحهٔ بخش درست هم نیاز دارد. تنظیمات سرویس به [Service] تعلق دارد. فایلی که تنظیمات دارد اما بخش ندارد نادیده گرفته یا رد می‌شود، و واحد همان‌طور که پیش‌تر بود رفتار می‌کند در حالی که فایل آنجا نشسته و معتبر به نظر می‌رسد.

اگر بیش از یک drop-in اضافه می‌کنید، هدف را در نام فایل نگه دارید. ترتیب واژه‌ای ادغام را تعیین می‌کند، و نامی که می‌گوید فایل چه می‌کند آن ترتیب را خوانا می‌کند.

پیش از نوشتن، واحد ادغام‌شده را بخوانید

پیش از نوشتن هر چیزی، واحد ادغام‌شده را بخوانید. systemctl cat [email protected] واحد اصلی و هر drop-in معتبر را به ترتیب ادغام چاپ می‌کند. هنگامی که تغییر قالب را در نظر دارید، آن را با نمونهٔ دومی مقایسه کنید. آن مقایسه دقیقاً نشان می‌دهد کدام سرویس‌ها ویرایش را به ارث می‌برند.

فایل نمونه تنظیمات قالب را پاک نمی‌کند. هر دو ادغام می‌شوند، پس مقداری از قالب که فراموش کرده‌اید می‌تواند هنوز معتبر باشد.

drop-inهای نام‌دار دیگر، تنظیمات زمان اجرا و پیکربندی‌ای که بسته‌ها ارائه می‌دهند هم مشارکت دارند. فرض نکنید فایلی که آخر از همه ویرایش کردید تمام واحد است. خروجی ادغام‌شده همان واحد است.

سیاست واحد را از پروفایل بیرون نگه دارید

سیاست واحد و پیکربندی VPN را جدا نگه دارید. یک دستور پروفایل به این دلیل که زیر [Service] نشسته، نحو معتبر systemd نمی‌شود. تنظیم راه‌اندازی مجدد هم به فایل .ovpn تعلق ندارد.

این جداسازی همچنین دلیل آن است که سیاست راه‌اندازی مجدد همان چیزی نیست که OpenVPN خودش برای بازیابی همتا انجام می‌دهد. پیش از انتخاب دامنه تصمیم بگیرید چه رفتاری می‌خواهید.

اعمالش کنید و نمونه را بررسی کنید

پس از تغییر، تعریف‌های مدیر را با systemctl daemon-reload دوباره بارگذاری کنید. آن بارگذاری تونل را دوباره راه‌اندازی نمی‌کند؛ فقط فایل‌های واحد را دوباره می‌خواند. سپس اقدام چرخهٔ عمری را که در نظر داشتید روی همان نمونهٔ دقیق اعمال کنید.

با دوباره خواندن واحد بارگذاری‌شده و تماشای رفتاری که تغییر دادید بررسی کنید. راه‌اندازی مجددی که کار فعال دارد شایستهٔ وقفه‌ای برنامه‌ریزی‌شده است، نه آزمایش سریع روی تونل عملیاتی. هدف و دامنهٔ بازنویسی را کنار استقرار ثبت کنید تا نفر بعدی بداند فایل قرار بود مشترک باشد یا نه.

اگر سیاست واقعاً مشترک است، آگاهانه آن را به قالب منتقل کنید و پیش از تمام‌شده دانستن کار، نمونهٔ دومی را بررسی کنید.مرجع واحد systemd اولویت drop-in و ترتیب ادغام را مستند می‌کند.