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

خطا سوار شدن ریشه را نام می‌برد، نه پروفایل شما را

systemd خودش واحد سوار شدن ریشه را از اطلاعات سوار شدن کرنل می‌سازد و واحد را -.mount می‌نامد، چون خط تیره نماینده مسیر ریشه است. این واحد معمولاً فقط در حافظه وجود دارد و فایلی پشت آن نیست. وقتی خطا می‌گوید پوشانده شده است، کسی فایل واحدی را جایی گذاشته که systemd آن را بارگذاری می‌کند و آن فایل را به /dev/null اشاره داده است. پوشاندن یک وضعیت واقعی است، نه غلط تایپی در پیام.

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

پیش از عیب‌یابی OpenVPN پوشه زمان اجرا را بررسی کنید

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

ls -l /run/systemd/system/-.mount
systemctl status -.mount
systemctl list-unit-files --state=masked | grep mount

ماشین عادی چنین فایلی ندارد، و فهرست پوشانده‌ها سوار شدن ریشه را در بر نمی‌گیرد. اگر فرمان اول پیوند نمادین به /dev/null چاپ کند، تشخیص قطعی است. همان پوشه می‌تواند پوشاننده tmp.mount را داشته باشد که همان ابزارها ساخته‌اند، و آن همان دسته شکست را با نامی دیگر تولید می‌کند. به کل پوشه نگاه کنید نه فقط به نام در خطا.

ls -la /run/systemd/system/*.mount

اگر پوشه پاک است و واحد هنوز پوشانده شده، پوشاننده جای دیگری در مسیر جست‌وجوست، و systemctl cat -.mount نشان می‌دهد کدام فایل بارگذاری می‌شود.

فایل را حذف کنید، دوباره بارگذاری کنید و از نو شروع کنید

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

sudo rm -f /run/systemd/system/-.mount /run/systemd/system/tmp.mount
sudo systemctl daemon-reload
systemctl status -.mount
sudo systemctl start [email protected]

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

journalctl -u [email protected] -b --no-pager

چون /run یک سیستم فایل موقت است، راه‌اندازی دوباره فایل را هم پاک می‌کند. همین راه‌اندازی دوباره را آزمونی سودمند می‌کند: اگر سرویس پس از راه‌اندازی دوباره کار کند و پس از استقرار بعدی دوباره شکست بخورد، فایل در تصویر پخته می‌شود.

مانع بازگشت آن از تصویر شوید

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

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

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

مقالات مرتبط