هشدار OpenVPN درباره چند اسکریپت --up: فقط یکی اجرا می‌شود

هشدار چند اسکریپتی مثل شکایتی درباره زمان‌بندی به نظر می‌رسد، پس راه‌حل بدیهی این است که خط‌ها را جابه‌جا کنید تا ناپدید شود. اما شکایت زمان‌بندی نیست. تعریف بعدی --up فرمانی را که پیش‌تر برای آن مرحله ذخیره شده جایگزین می‌کند، و تحلیلگر همین را می‌گوید، یعنی از دو اسکریپت شما دقیقاً یکی اجرا شده است. دیگری در صف پشت سرش نیست؛ رفته است.

به همین دلیل این هشدار شایسته توجه است، هرچند مرگبار نیست: چیزی که پیش‌بینی می‌کند یک به‌روزرسانی DNS یا تغییری در مسیر است که بی‌صدا متوقف شده است.

هشدار درباره ترتیب نیست

OpenVPN برای مرحله up یک فرمان اسکریپت کاربر نگه می‌دارد. وقتی تحلیلگر به تعریف دیگری برمی‌خورد، از پروفایل، یک فایل گنجانده‌شده یا خط فرمان، آنچه را قبلاً داشته جایگزین می‌کند و هشدار را صادر می‌کند. هیچ چیز به هم پیوند نمی‌خورد، هیچ چیز دو بار اجرا نمی‌شود، و پرسشی درباره ترتیب وجود ندارد. فرمانی که زنده می‌ماند همان است که تحلیلگر آخرین بار دیده، به همین دلیل جابه‌جا کردن یک خط می‌تواند برنده را عوض کند و اسکریپت دیگر مرده بماند.

همین الگو برای سایر مراحل اسکریپت هم برقرار است: برای هرکدام یک فرمان. اگر دو کار باید هر دو انجام شوند، به یک نقطه ورود نیاز دارند، نه دو دستوری که شبیه یک فهرست‌اند.

هر دو تعریف را در اجرای واقعی پیدا کنید

از آنچه دیمن واقعاً دریافت کرده شروع کنید، نه از پروفایلی که ویرایش کرده‌اید. ps -ef و ExecStart واحد، خط فرمان را نشان می‌دهند که ممکن است --up را از نقطه ورود یک کانتینر یا یک پوشش اضافه کند؛ فایل init یک توزیع هم می‌تواند همین کار را بکند. systemctl cat openvpn-server@server نشان می‌دهد خود سرویس چه چیزی اضافه می‌کند، و یک grep بازگشتی در پوشه پیکربندی تعریف‌های سطح فایل را پیدا می‌کند. تکراری‌ها معمولاً از لایه‌های مختلف می‌آیند، و دقیقاً به همین دلیل ویرایش یک فایل چیزی را عوض نمی‌کند.

کپی کردن اسکریپت به پوشه‌ای دیگر یا تغییر نامش هم یک دستور را حذف نمی‌کند. تحلیلگر تعریف‌ها را می‌شمارد، نه فایل‌ها را.

بگذارید یک hook مالک کار باشد

راه‌حل پایدار یک توزیع‌کننده واحد است که هر دو کنش را به ترتیبی سنجیده اجرا می‌کند. یک اسکریپت shell کوتاه با set -eu که یکپارچه‌سازی لازم و سپس کنش محلی را فرا می‌خواند و "$@" را عبور می‌دهد تا مرزهای آرگومان‌ها زنده بمانند، رفتار را در یک جای قابل بازبینی نگه می‌دارد. عبور دادن آرگومان‌ها فقط آن‌ها را حفظ می‌کند؛ ثابت نمی‌کند که دو کمک‌کننده یک رابط را انتظار دارند، پس قرارداد هرکدام را بخوانید. تصمیم بگیرید که شکست چه باید بکند و آیا تغییرهای جزئی باید برگردانده شوند.

اگر راه‌انداز یک hook افزونه پشتیبانی‌شده ارائه می‌دهد، آن را بر زنجیره دست‌ساز ترجیح دهید. تصویر یک کانتینر یا بسته یک فروشنده اغلب جای مستندی برای کار اضافی دارد، و استفاده از آن باعث می‌شود به‌روزرسانی توزیع‌کننده شما را بازنویسی نکند.

پاک‌سازی متعلق به مرحله down متناظر است. کنش up که DNS را بازنویسی می‌کند یا مسیرها را اضافه می‌کند به یک بازگردانی مستند نیاز دارد، و توزیع‌کننده‌ای که فقط راه‌اندازی را مدیریت می‌کند نیمی از طراحی است.

یکپارچه‌سازی را تأیید کنید، نه فقط سکوت را

حذف هشدار تکراری بخش آسان است؛ یکپارچه‌سازی هنوز باید کار کند. وضعیت resolver را پس از اتصال با resolvectl status یا با خواندن /etc/resolv.conf بررسی کنید، و مسیرها را با ip route تأیید کنید. سپس قطع و دوباره وصل شوید، چون یک hook که با عجله زنجیر شده معمولاً چیزی از نشست قبلی جا می‌گذارد. journalctl -u openvpn-server@server -b نشان می‌دهد که توزیع‌کننده شما اجرا شده و چه چیزی چاپ کرده است.

اختیارات hook را همان‌جا که باید نگه دارید. بالا بردن script-security یا اجرای دیمن با اختیارات بیشتر، راه‌حل یک hook جایگزین‌شده نیست؛ دامنه کاری را که هر اسکریپت آینده می‌تواند بکند گسترش می‌دهد، از جمله اسکریپتی که مهاجم نام آن را انتخاب می‌کند.

نشانه واقعی بودن راه‌حل، سکوت در گزارش نیست. پاسخ DNS، ورودی مسیر و پاک‌سازی است که همه پس از دو اتصال دوباره درست کار می‌کنند.