راه‌اندازی مجدد یک سرویس در OpenVPN up: قلاب‌ها بر tun0.device پیروز می‌شوند

اتصال یک سرویس وابسته به tun0.device شبیه اشتراک در تونل به نظر می‌رسد، اما نیست. واحد دستگاه بازتاب‌دهنده وجود رابط است، که می‌تواند در طول یک اتصال ناموفق و اتصال مجدد پس از آن درست بماند. سپس سرویس در لحظه اشتباه عمل می‌کند، یا هرگز، بسته به اینکه رابط در این فاصله ناپدید شده باشد یا نه. قلابی که رویدادی را که واقعاً به آن اهمیت می‌دهید توصیف می‌کند همان است که OpenVPN صدا می‌زند، نه آنکه systemd استنباط می‌کند.

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

واحد دستگاه واقعاً چه چیزی را ردیابی می‌کند

systemd یک واحد دستگاه از دید هسته به یک رابط شبکه می‌سازد، بنابراین tun0.device وقتی رابط ظاهر می‌شود فعال و وقتی حذف می‌شود غیرفعال می‌شود. با persist-tun، راه‌اندازی مجدد نرم رابط را در جای خود نگه می‌دارد، پس واحد هرگز نوسان نمی‌کند و هیچ چیز متصل به آن فعال نمی‌شود. حتی بدون ماندگاری، واحد هیچ چیزی درباره مسیرها، DNS یا پاسخ‌دادن طرف دور نمی‌گوید.

این آن را جانشین بدی برای «VPN آماده است» می‌کند. شنونده‌ای که فقط به نشانی محلی نیاز دارد ممکن است با وجود رابط راضی باشد، در حالی که سرویسی که برنامه‌ای را در شبکه دور صدا می‌زند به مسیرها و دسترس‌پذیری نیاز دارد، که واحد دستگاه نمی‌تواند بیان کند.

up، route-up و up-restart معانی متفاوتی دارند

up پس از باز شدن دستگاه TUN/TAP و پیکربندی رابط اجرا می‌شود، که لحظه درست برای شنونده‌ای است که نشانی تخصیص‌یافته را می‌بندد. route-up پس از نصب مسیرها، مشروط به هر تأخیر مسیر پیکربندی‌شده، اجرا می‌شود و برای کاری مناسب است که به تکمیل مرحله مسیر نیاز دارد. هیچ‌کدام ثابت نمی‌کند که برنامه دور پاسخ می‌دهد. انتخاب بین آن دو پرسشی درباره چیزی است که سرویس نیاز دارد، نه درباره اینکه کدام قلاب کامل‌تر به نظر می‌رسد.

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

کنش را بدون انتظار برای آن بفرستید

قلابی که systemctl restart را همزمان صدا می‌زند می‌تواند در برابر واحدی که ترتیبش منتظر تونل است به بن‌بست بخورد. systemctl --no-block try-restart vpn-dependent.service کار را در صف می‌گذارد و برمی‌گردد، که مانع از آن می‌شود قلاب اتصالی را که به آن واکنش نشان می‌داد مسدود کند. try-restart فقط روی واحد در حال اجرا عمل می‌کند، در حالی که restart واحد غیرفعال را هم شروع می‌کند؛ آگاهانه انتخاب کنید، نه از روی عادت.

قرار دادن در صف تأیید نیست. قلاب به‌محض پذیرفته شدن کار موفقیت برمی‌گرداند، پس بررسی باید در ژورنال واحد هدف یا در وضعیت واقعی شنونده آن رخ دهد.

سیاست راه‌اندازی مجدد در واحد زندگی می‌کند، نه در قلاب

واحد oneshot با RemainAfterExit=yes پس از خروج فرمانش فعال می‌ماند، و درخواست شروع دوم هیچ کاری نمی‌کند چون systemd آن را از قبل شروع‌شده می‌داند. این ویژگی‌ای است که باید حول آن طراحی کرد، نه نقصی که با فراخوانی‌های مکرر شروع دور زده شود. اگر کنش باید برای هر اتصال اجرا شود، واحد به شکلی نیاز دارد که آن را مجاز کند.

After= واحدها را مرتب می‌کند، و BindsTo= عمرها را به هم می‌بندد، اما هیچ‌کدام به معنای «هر بار VPN دوباره وصل شد این را دوباره راه بینداز» نیست. واحدی که به تونل بسته شده وقتی تونل متوقف می‌شود متوقف می‌شود؛ وقتی تونل برمی‌گردد خودش را دوباره راه نمی‌اندازد مگر اینکه چیزی دوباره آن را شروع کند.

سه اتصال مجدد را آزمایش کنید، نه یکی را

شروع سرد، راه‌اندازی مجدد کامل کلاینت و اتصال مجدد نرم هر کدام مسیر متفاوتی را تمرین می‌کنند. اتصال مجدد نرم همانی است که up-restart گمشده، محیط کاهش‌یافته، یا واحد دستگاهی را که هرگز غیرفعال نشد آشکار می‌کند. هر سه را اجرا کنید و هر دو جهت را تأیید کنید: سرویس وقتی تونل بالا می‌آید عمل می‌کند، و در تغییرات پیوند نامرتبط مثل رومینگ Wi-Fi دوباره راه‌اندازی نمی‌شود.

وقتی سرویس وابسته دسترسی مدیریتی خودتان را حمل می‌کند یک مسیر بازیابی مستقل نگه دارید. قلابی که چیزی را که از طریق آن متصل هستید دوباره راه می‌اندازد تغییری است که می‌تواند شما را بیرون قفل کند.