OpenVPN هنگام بوت در Ubuntu: NetworkManager یا systemd؟
یک لپتاپ و یک سرور بدون نمایشگر به مسیرهای بوت متفاوتی نیاز دارند. اتصال ثانویه NetworkManager را با openvpn-client@ و فایل اعتبارنامه آن مقایسه کنید.
بیشتر راهنماها این انتخاب را ظاهری نشان میدهند: یا بگذارید NetworkManager تونل را بالا بیاورد، یا یک نمونه systemd را فعال کنید و تمام. این دو مسیر در یک چیز تفاوت دارند که نتیجه را روی دستگاهی بدون نمایشگر تعیین میکند، و هیچ ربطی به جدیدتر بودن ابزار ندارد. NetworkManager رازها را از طریق یک نشست باز میکند؛ نمونه systemd هیچ نشستی برای باز کردن ندارد. مسیری را انتخاب کنید که شیوه برخوردش با رازها با دستگاهی که پیش روی شماست سازگار باشد.
هر چیز دیگری، از نصب مسیرها تا رفتار اتصال دوباره، از همان تصمیم اول سرچشمه میگیرد.
دستهکلید همان تفاوتی است که کسی از آن حرف نمیزند
وقتی NetworkManager صاحب یک نمایه VPN است، گذرواژه میتواند در دستهکلید ورود قرار بگیرد، که هنگام ورود کاربر باز میشود. این روی لپتاپ خوب کار میکند: شخص حاضر است، دستهکلید باز میشود، تونل بالا میآید. روی سروری که بدون نظارت بوت میشود کسی نیست که چیزی را باز کند، پس نمایه منتظر رازی میماند که هرگز نمیرسد. اتصال پیکربندیشده به نظر میرسد و هرگز فعال نمیشود.
نمونه systemd با خواندن فایل اعتبارنامه از دیسک از این مشکل دوری میکند، و همین فایل را به چیزی تبدیل میکند که از آن محافظت میکنید. chmod 400 بههمراه مالکیت root حداقل است، و فایل باید بیرون از نسخههای پشتیبان و قالبهای تصویری بماند که کنترلشان با شما نیست.
متصل کردن VPN به یک اتصال تضمین بوت نیست
در nm-connection-editor، بهجای VPN اتصال سیمی یا بیسیم را انتخاب کنید، زبانه General را باز کنید، گزینه اتصال خودکار به VPN را تیک بزنید و نمایه را نامگذاری کنید. سپس NetworkManager وقتی اتصال اصلی به وضعیت متصل میرسد، VPN را بهعنوان اتصال ثانویه فعال میکند. این یک وابستگی است، نه قاعده دیوار آتش. بستهها هنوز میتوانند در ثانیههای پیش از بالا آمدن تونل خارج شوند، و راز ذخیرهشدهای که باز نشود دستگاه را بدون آن آنلاین رها میکند.
اگر شرط این است که هیچ چیز بدون تونل خارج نشود، این را بگویید و یک کلید قطع بسازید، چون این تنظیم یکی در اختیار شما نمیگذارد. تعلیق و ادامه را هم آزمایش کنید، زیرا اتصال ثانویه در مسیر بازگشت دوباره ارزیابی میشود.
نمونه systemd به نام فایلی نیاز دارد که مطابقت داشته باشد
نمایه را در پوشه مشتری که بسته انتظار دارد بگذارید، مانند /etc/openvpn/client/office.conf، و از داخل آن با auth-user-pass office.cred به فایل اعتبارنامه اشاره کنید. نام نمونه همان نام فایل بدون پسوند است، پس openvpn-client@office فایل office.conf را میخواند. آن را با sudo systemctl enable --now openvpn-client@office فعال کنید و تطابق را با systemctl cat openvpn-client@office تأیید کنید، نه با اعتماد به نمونهای از یک وبلاگ.
مسیرهای داخل نمایه نسبت به پوشه کاری واحد حل میشوند، نه نسبت به خود نمایه، بنابراین یک خط نسبی ca یا auth-user-pass میتواند هنگام بوت شکست بخورد در حالی که در آزمایش دستی کار میکند. برای هر چیزی که واحد باید پیدا کند از مسیر مطلق استفاده کنید. سپس پس از یک بوت واقعی journalctl -u openvpn-client@office -b را بخوانید؛ واحدی که بدون تونل فعال گزارش میدهد معمولاً در آن گزارش نام فایلی گمشده را میآورد.
بستههای قدیمیتر نام قالب دیگری دارند، پس systemctl list-unit-files 'openvpn*' تعیین میکند کدام روی این میزبان وجود دارد.
رفتار اتصال دوباره تصمیمی جداگانه است
نمایهای با ping-restart پس از قطع شدن تونل را دوباره میسازد، و واحدی با دستور راهاندازی مجدد چیزی مشابه در سطح سرویس انجام میدهد. اینها سیاستهایی هستند که شما انتخاب میکنید، نه پیشفرضهایی که به ارث میبرید. اگر اتصال باید فقط بر اساس تقاضا بالا بیاید، رفتار راهاندازی مجدد را آگاهانه حذف کنید و دلیلش را بنویسید. اگر واحد پیش از قابل استفاده شدن شبکه شروع شود، به سیاست تلاش دوباره نیاز دارد، چون یک تلاش ناموفق هنگام بوت خودبهخود تکرار نمیشود.
توقف هم به همان اندازه تحتاللفظی است: sudo systemctl disable --now openvpn-client@office نمونه در حال اجرا را متوقف میکند و پیوند بوت را حذف میکند. غیرفعال کردن بهتنهایی تونل را تا راهاندازی مجدد بعدی در حال اجرا میگذارد، و این هر کسی را که با غیرفعال کردن آزمایش میکند و میبیند رابط بالا میماند شگفتزده میکند.
راهاندازی مجدد کنید، سپس چهار چیز را به ترتیب بررسی کنید
راهاندازی مجدد سرویس، سرویس را میآزماید؛ راهاندازی مجدد دستگاه، مسیر بوت را میآزماید. پس از راهاندازی مجدد، تأیید کنید که واحد بالا آمده، سپس اینکه مسیری برای زیرشبکه دور وجود دارد، سپس اینکه دستگاه چه نشانی را به اینترنت ارائه میدهد، و در نهایت اینکه نامها از طریق تونل حل میشوند. این چهار بررسی وقتی چیزی اشتباه است به همان ترتیب شکست میخورند، و همین اولین شکست را سودمند میکند.
واحد فعال بدون مسیر معمولاً یعنی نمایه متصل شده اما سرور هیچ مسیری هل نداده، یا مسیر روی رابطی نصب شده که بعداً ناپدید شده است. مسیری که جستوجوی نام در آن کار نمیکند به پیکربندی DNS اشاره دارد، نه به خود تونل.
از پیش تصمیم بگیرید وقتی تونل نمیتواند بالا بیاید چه باید بشود. بازگشت به اتصال ساده یک سیاست است و باید نوشته شود، نه اینکه به هر مدیری که اول شروع کرده واگذار شود.