OpenVPN می‌گوید active (exited)؟ نمونه‌ای را که راه‌اندازی کرده‌اید پیدا کنید

تونل را بررسی می‌کنید، systemctl status openvpn را اجرا می‌کنید و active (exited) را بدون Main PID و با فهرست پردازه‌ای خالی می‌گیرید. خواندن طبیعی این است که سرویس شروع شده و مرده است، پس واحد را باز می‌کنید، /bin/true را پیدا می‌کنید و نتیجه می‌گیرید که بسته خراب است. در بسته‌بندی Debian آن وضعیت، پوشش (wrapper) است که همان‌طور که طراحی شده کار می‌کند و تونل در یکی از واحدهای نمونه که آن آغاز می‌کند زندگی می‌کند. واحد تجمیعی هرگز به شما نخواهد گفت کدام نمونه آن را ساخته است.

active (exited) در این واحد در واقع چه معنایی دارد

واحد بسته‌بندی‌شده یک وظیفه یک‌باره است: ExecStart آن /bin/true است و RemainAfterExit=yes چیزی است که یک واحد تمام‌شده را به صورت active (exited) گزارش‌شده نگه می‌دارد. آن دستور را بردارید و همان وظیفه موفق /bin/true در inactive (dead) پایان می‌یابد، که دقیقاً همان حالتی است که مردم انتظار دارند و در جهت مخالف اشتباه می‌خوانند. فرمان فقط یک جای‌نگهدار است و واحد درباره کاری گزارش می‌دهد که واحدهای دیگر انجام می‌دهند. هیچ‌چیز در این ترتیب خراب نیست و جایگزینی /bin/true قرارداد بسته‌بندی را تغییر می‌دهد نه تونل را.

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

سه خط خروجی status را بخوانید نه کلمه داخل پرانتز را. Loaded نام فایل واحدی را می‌آورد که systemd خوانده است، Active مهر زمان آخرین اجرای موفق را دارد و نبودن Main PID با یک وظیفه یک‌باره تمام‌شده جور است. همان سه خط راه تشخیص این پوشش از سرویسی است که یک ثانیه بعد از شروع از کار افتاده.

پیش از خواندن دوباره status، واحدها را فهرست کنید

پیش از پرسیدن اینکه چه چیزی در حال اجراست، از systemd بپرسید چه چیزی وجود دارد. یک قالب می‌تواند نصب شده باشد در حالی که هیچ نمونه‌ای ساخته نشده است، و تنها یک واحد ساخته‌شده تونل دارد. با مجموعه بارگذاری‌شده شروع کنید:

systemctl list-units 'openvpn*'

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

systemctl list-unit-files 'openvpn*'

دو فهرست را با هم بخوانید، چون قالب در دومی و نمونه در اولی دو پاسخ متفاوت‌اند. قالبی که وجود دارد و نمونه‌ای که اجرا می‌شود یک واقعیت نیستند و تنها دومی به معنای تونل است. چیدمان بسته‌ها میان توزیع‌ها و نسخه‌های OpenVPN هم فرق می‌کند. قالب قدیمی‌تر openvpn@، جفت جداگانه client و server و پوشش توزیع همگی می‌توانند در بسته‌بندی خودشان مشروع باشند.

با ماشین خودتان تطبیق دهید نه با آموزشی که یافته‌اید. نام نمونه در خروجی دیگری ممکن است office باشد در حالی که مال شما home یا work است. آنچه منتقل می‌شود روش است، نه رشته.

نام نمونه را تا فایلی که می‌خواند دنبال کنید

در قالب client بالادستی، پوشه کاری واحد /etc/openvpn/client است و فرمان آن %i.conf را از آنجا برمی‌دارد، بنابراین openvpn-client@office فایل /etc/openvpn/client/office.conf را می‌خواند. این نگاشت را روی واحد نصب‌شده تأیید کنید نه اینکه به مثال اعتماد کنید، چون قالبی که دارید ممکن است قدیمی‌تر یا بازنویسی توزیع باشد:

systemctl cat [email protected]

drop-inهایی را که در پایین آن خروجی می‌آیند بخوانید، چون فایلی زیر .d/ می‌تواند ExecStart، پوشه کاری یا مسیر پیکربندی را تغییر دهد. پروفایلی که با نام office.ovpn دانلود کرده‌اید فایلی که نمونه باز می‌کند نیست. همین شکاف دلیل معمول نام‌بردن مسیری است که هرگز ویرایش نکرده‌اید.

مسیرهای نسبی داخل پروفایل تله بعدی است. جابه‌جا کردن فایل اصلی در حالی که ارجاع‌های ca، cert و key نسبی می‌مانند، خطای فایل گمشده را با خطای فایل گمشده دیگری عوض می‌کند. دومی به فایلی اشاره می‌کند که مطمئن بودید وجود دارد، و به همین دلیل پوشه پروفایل از نام فایل مهم‌تر است.

آن را آغاز کنید و سپس ژورنال همان نمونه را بخوانید

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

sudo systemctl start [email protected]
journalctl -u [email protected] -b

آغاز کردن و فعال کردن دو تصمیم جدا هستند: start واحد را همین حالا اجرا می‌کند، enable بوت بعدی را ترتیب می‌دهد و enable --now هر دو را در یک قدم انجام می‌دهد. daemon-reload تعریف‌های واحد را دوباره می‌خواند و نه یک پردازه در حال اجرا را دوباره راه می‌اندازد و نه پروفایل ویرایش‌شده را اعمال می‌کند. پس از تغییر پروفایل، نمونه را دوباره راه‌اندازی کنید، چون همان است که فایل را دوباره می‌خواند.

مدیر دومی روی همان تونل نگذارید

NetworkManager و مدیران نشست OpenVPN 3 وضعیت اتصال خودشان را دارند و یک نمونه systemd در کنار یکی از آن‌ها دو مالک روی یک تونل می‌گذارد. نشانه، تونلی است که بالا می‌آید و چند ثانیه بعد جایگزین می‌شود، یا تونلی که از متوقف ماندن سر باز می‌زند. مدیری را انتخاب کنید که توزیع شما برای رومیزی مستند کرده است و systemd را آگاهانه روی سرور به کار ببرید.

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

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