چرا یک واحد VPN پیش از شبکه آغاز می‌شود و سپس می‌میرد

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

مقصد یک نقطه تلاقی است، نه یک مدیر

network-online.target هیچ تصوری از شبکه ندارد. یک نقطه هماهنگی است که هر سرویسی را که قرار است آغاز به کار را تا قابل استفاده شدن اتصال به تعویق بیندازد جمع می‌کند، و تعریف را به هر مدیر شبکه‌ای که صاحب ماشین است واگذار می‌کند. در بیشتر رایانه‌های رومیزی و سرورها این یعنی یک سرویس انتظار که NetworkManager یا systemd-networkd ارائه می‌کند. اگر هیچ‌یک را فعال نکنید، مقصد چیزی ندارد که منتظرش باشد، بنابراین همان لحظه‌ای که چیزی آن را به درون می‌کشد کامل می‌شود، که می‌تواند خیلی پیش از پاسخ DHCP باشد. خط ترتیب در واحد شما صادق بود و با این حال بی‌فایده.

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

به‌جای پرونده واحد، آخرین بوت را بخوانید

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

نمای وابستگی‌ها آن را تأیید می‌کند. اگر زنجیره بحرانی برای واحد تونل هیچ سرویس انتظاری نداشته باشد، هیچ چیز در آن مسیر آغاز به کار را به تعویق نینداخته، و مقصد کاری را که فرض کرده‌اید انجام نداده است. دو نما، یک نتیجه.

systemctl list-units --type=service --state=running | grep wait-online
journalctl -b -o short-monotonic -u openvpn-client@office

انتظار را اضافه کنید، سپس تلاش دوباره

به‌جای ویرایش یک واحد بسته‌بندی‌شده از drop-in استفاده کنید، تا به‌روزرسانی بسته تغییر را بی‌صدا دور نریزد. دو دستور مهم است: واحد باید پس از مقصد مرتب شود، و باید مقصد را به همان تراکنش بکشد. ترتیب به‌تنهایی مقصد را فرا نمی‌خواند؛ خواستن این کار را می‌کند.

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

[Service]
Restart=on-failure
RestartSec=15

چرا یک خواب ثابت تله است

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

بدتر آنکه پنهان می‌کند که سرویس انتظار کار می‌کند یا نه، بنابراین شکست بعدی به عنوان مشکلی کاملاً تازه نمایان می‌شود نه همان مشکل با زمان‌بندی متفاوت. تعویق کوتاه راه‌اندازی دوباره ابزار بهتری است: در یک بوت سالم هیچ هزینه‌ای ندارد و یک مسابقه باخته را به تلاشی دیگر تبدیل می‌کند. فاصله را کم نگه دارید و بگذارید واحد موفق شود. اگر برای همیشه راه‌اندازی دوباره می‌کند، پروفایل خراب است و هیچ مقدار تلاش دوباره آن را تغییر نمی‌دهد، پس ژورنال را بخوانید نه اینکه فاصله را بالا ببرید.

وقتی ترتیب درست است و نام‌ها باز هم شکست می‌خورند

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

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