شروع OpenVPN پیش از آماده بودن شبکه یک خطا نیست
کارخواهی که پیش از دسترس‌پذیر بودن کارساز شروع می‌شود در حال تلاش دوباره است، نه شکست. ترتیب، DNS، احراز هویت و بازیابی پس از اتصال را جدا کنید.
کارخواه را هنگام راه‌اندازی اجرا می‌کنید، واحد فعال گزارش می‌دهد و تونل وجود ندارد. نتیجه طبیعی این است که سرویس نتوانسته شروع شود، و اصلاح طبیعی این است که دوباره شروعش کنید. هر دو به‌قدر کافی غالباً اشتباه‌اند که ارزش یک قاعده را داشته باشند: کارخواه در حال اجرایی که تلاش دوباره می‌کند از بیرون دقیقاً مانند یک کارخواه خراب دیده می‌شود. تفاوت در کاری است که فرایند انجام می‌دهد، نه در وضعیت واحد.
افسانه: سرویس شروع‌شده یعنی تونل کارکننده
واحد فعال اثبات می‌کند که فرایند اجرا شده و خارج نشده است. اثبات نمی‌کند که نمایه بارگذاری شده، گواهی پذیرفته شده یا طرف مقابل پاسخ داده است. کارخواه بسته‌بندی‌شده می‌تواند دقایقی در حلقه تلاش دوباره بماند، در حالی که systemd فقط موفقیت را گزارش می‌دهد. همان شکاف میان وضعیت و رفتار کل ماجراست.
حالت عکس به همان اندازه رایج است. ممکن است فرایند پس از ناتوانی در خواندن یک کلید خارج شده باشد، و سپس واحد وضعیت شکستی را گزارش می‌دهد که درباره دلیل چیزی نمی‌گوید. هر دو وضعیت برای تشخیص از هم به گزارش نیاز دارند.
گزارش را برای نمونه بخوانید، نه وضعیت واحد را. خط دلیل در گزارش است، نه در برچسب وضعیت.
افسانه: تنظیمات تلاش دوباره همه شکست‌ها را پوشش می‌دهد
تجزیه نام و تلاش‌های دوباره انتقال دو کنترل جداگانه با پیش‌فرض‌های جداگانه‌اند. resolv-retry جست‌وجوهای مکرر نام میزبان دور را کنترل می‌کند و پیش‌فرض مستند همچنان بی‌توقف تلاش می‌کند. connect-retry فاصله میان تلاش‌ها را تعیین می‌کند، و connect-retry-max می‌تواند محدود کند که هر مدخل دور چند بار آزمایش شود. پیش از تغییر هر یک، بررسی کنید گزارش کدام مرحله را نام می‌برد.
هیچ‌یک از اینها به نمایه بدشکل، کلید خصوصی ناخوانا یا حساب ردشده مربوط نیست. آنها به اصلاح نیاز دارند و کارخواهی که مدام آنها را دوباره تلاش می‌کند پیشرفتی ندارد.
تلاش دوباره بی‌پایان برای گواهی تأییدنشده دلیلی برای حذف بررسی نیست. دلیلی برای خواندن خطاست.
افسانه: یک راه‌انداز کافی است، پس یکی دیگر اضافه کنید
اتصالی که از قبل NetworkManager یا یک واحد بسته‌بندی‌شده مدیریت می‌کند نیازی به راه‌انداز دوم ندارد. دو فرایند که بر سر مسیرهای یکسان رقابت می‌کنند رابط‌های تکراری، گزارش‌های گیج‌کننده و تونلی می‌سازند که به دلایلی که کسی نمی‌بیند نوسان می‌کند. نسخه دوم معمولاً به‌عنوان راه‌حل موقت برای کند بودن اولی می‌آید.
تصمیم بگیرید کدام مؤلفه مالک تونل است پیش از افزودن هر چیزی. سپس راه‌انداز دیگر را حذف کنید نه اینکه آن را غیرفعال کنید و امیدوار باشید.
مالک همچنین تعیین می‌کند تلاش‌های دوباره و اعتبارنامه‌ها از کجا می‌آیند، به همین دلیل این تصمیم پیش از هر تنظیمی می‌آید. مالکیت دقیقاً به همین دلیل اول است.
آنچه واقعاً به ترتیب نیاز دارد
ترتیب می‌تواند منتظر یک نشانی پیکربندی‌شده بماند و این تنها چیزی است که تضمین می‌کند. network-online.target فعال‌سازی را تا زمانی که مدیر شبکه را بالا بداند به تعویق می‌اندازد، و تعریف بالا بودن به مدیر بستگی دارد. درباره اینکه نام میزبان VPN تجزیه می‌شود، شنونده پاسخ می‌دهد یا درگاه اسیر دستگاه را پذیرفته، چیزی نمی‌گوید.
واحد نصب‌شده و هر فایل drop-in را پیش از افزودن وابستگی‌ها بخوانید. After= گسترده روی هر سرویس شبکه راه‌اندازی را به تعویق می‌اندازد بدون اینکه اتصالی را که واقعاً لازم دارید برقرار کند.
وابستگی‌ای را که می‌توانید بیازمایید مرتب کنید و همه چیز دیگر را با کاوشگر آمادگی بسنجید. کاوشگری که تونل را باز می‌کند از زمان‌سنجی که حدس می‌زند بهتر است.
پس از اولین بالا آمدن تونل چه اتفاقی می‌افتد
راه‌اندازی یک رویداد میان رویدادهای بسیار است. پیوند دسترسی تغییر می‌کند، نشست درگاه منقضی می‌شود، همتا دوباره راه می‌افتد. اتصال دوباره درونی را از خروج فرایند که مدیر سرویس رسیدگی می‌کند جدا کنید، چون این دو مالک متفاوت دارند و شواهد متفاوتی بر جای می‌گذارند.
احراز هویت تعاملی بازیابی بدون نظارت را محدود می‌کند. واحد پس‌زمینه جاکلیدی رومیزی را باز نمی‌کند و به درخواست MFA پاسخ نمی‌دهد، پس ترتیب اعتبارنامه تأییدشده برای بافت سرویس را دنبال کنید.
جداگانه تصمیم بگیرید برنامه‌ها هنگام پایین بودن تونل چه می‌توانند بکنند. تلاش دوباره اتصال را بازمی‌گرداند، در حالی که سیاست مسدودسازی تعیین می‌کند آیا ترافیک مستقیم در آن شکاف مجاز است.