OpenVPN: اتصال محلی هنگام بوت شکست می‌خورد — انتظار یا تلاش دوباره

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

هر دو بهتر از یک خواب ثابت هستند، که نه منتظر چیزی می‌ماند و نه گزارش می‌دهد منتظر چه بود.

گزینه local در واقع چه می‌خواهد

local نشانی‌ای را نام می‌برد که دیمن سوکت خود را به آن متصل می‌کند، و اتصال به نشانی‌ای که هنوز وجود ندارد فوراً با خطایی درباره نشانی درخواستی شکست می‌خورد. وقتی گزینه غایب است، دیمن روی همه نشانی‌ها گوش می‌دهد، به همین دلیل همان پروفایل روی ماشینی که رابطش بالا نیامده کار می‌کند: به جای یک نشانی که نام برده‌اید، همه‌جا گوش می‌دهد. همین تفاوت تمام خرابی است و تا یک بازراه‌اندازی نامرئی می‌ماند.

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

انتظار برای نشانی در برابر تلاش دوباره برای اتصال

انتظار یعنی یک ExecStartPre که تا ظاهر شدن نشانی نظرسنجی می‌کند، با تعداد محدود تلاش و خروج غیرصفر وقتی زمان تمام شود. تلاش دوباره یعنی گذاشتن فرآیند اصلی تا شکست بخورد و درخواست از مدیر سرویس برای راه‌اندازی دوباره آن، مثلاً Restart=on-failure با RestartSec=5. اولی پیش‌نیاز گمشده را به عنوان یونیت شکست‌خورده گزارش می‌کند، در حالی که دومی آن را به عنوان رشته‌ای از راه‌اندازی‌های مجدد گزارش می‌کند که سرانجام می‌ایستد؛ این در ژورنال پرسروصداتر است اما در برابر نشانی‌ای که به دلایلی که نمی‌توانید پیش‌بینی کنید دیر می‌رسد دوام می‌آورد.

وقتی نشانی یک وابستگی طراحی‌شده است انتظار را ترجیح دهید، و وقتی نشانی معمولاً ظاهر می‌شود اما زمان‌بندی‌اش متغیر است تلاش دوباره را. ترکیب آن‌ها معقول است: انتظار محدود حالت رایج را پوشش می‌دهد و سیاست راه‌اندازی مجدد استثنا را. کاری که هیچ‌کدام نباید بکند اجرای بی‌پایان است، چون یونیتی که بی‌پایان تلاش دوباره می‌کند یک پیکربندی نادرست را پنهان می‌کند به جای گزارش آن.

چرا network-online.target کافی نیست

network-online.target هر چیزی را که پیاده‌سازی فعال شبکه از online می‌فهمد وعده می‌دهد و نه بیشتر. با systemd-networkd، systemd-networkd-wait-online تعیین می‌کند چه وقت آن هدف محقق می‌شود، و برداشت پیش‌فرض آن از online می‌تواند پیش از وجود نشانی مشخص شما برآورده شود. زیر NetworkManager، سرویس wait-online قواعد خودش را اعمال می‌کند. مرتب‌سازی پس از هدف یک پایه سالم است، نه تضمین اینکه یک نشانی، پاسخ DNS یا همتای دوردست آماده باشد.

همین استدلال جایگزین‌های معمول را رد می‌کند. ورودی راه‌اندازی خودکار دسکتاپ منتظر یک نشست کاربر است که ممکن است هرگز روی سرور باز نشود، و فرمان cron تأخیری زمان سپری‌شده را اضافه می‌کند بدون نام بردن از منبعی که امید داشت ظاهر شود. هر دو می‌توانند ماه‌ها موفق به نظر برسند و سپس در همان یک بوت که اهمیت دارد شکست بخورند.

اتصال را پس از یک بوت سرد بررسی کنید

با یک بوت سرد واقعی تأیید کنید، نه با راه‌اندازی مجدد سرویس، چون راه‌اندازی مجدد نشانی‌ای را به ارث می‌برد که توالی بوت باید می‌ساخت. پس از بوت، ss -lntp یا ss -lunp نشانی محلی‌ای را نشان می‌دهد که هر شنونده واقعاً به آن متصل شده، و journalctl -b -u openvpn-server@server نشان می‌دهد آیا تلاش اول شکست خورده است. نشانی متصل‌شده را با نشانی موجود در پروفایل مقایسه کنید، سپس مقایسه را پس از اتصال دوباره شبکه تکرار کنید.

اگر پروفایل هرگز به نشانی ثابت نیاز نداشت، حذف local ساده‌سازی مشروعی است، اما آن را یک تصمیم امنیتی کنید نه عادت عیب‌یابی.

گسترده‌تر کردن شنونده تغییر می‌دهد چه کسی می‌تواند به آن برسد، پس آن تغییر را با سیاست فایروالی جفت کنید که باید محدودش می‌کرد. سرویسی که روی هر رابط به‌طور قابل‌اعتماد بالا می‌آید مشکل اصلی را حل نکرده است؛ مشکل را به لبه شبکه منتقل کرده است.