OpenVPN اجرا نمی‌شود: خط اول را بخوانید، نه پیکربندی را

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

سه فرمان فقط‌خواندنی شما را به آنجا می‌رسانند: ابتدا journalctl -u openvpn@server -b --no-pager، سپس systemctl status openvpn@server، و ss -lunp برای شنونده‌های UDP و صاحبانشان.

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

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

مراقب حلقهٔ تلاش دوباره باشید که خط اصلی را پنهان می‌کند. یک واحد با سیاست راه‌اندازی دوباره می‌تواند اولین شکست را زیر دسته‌ای از شکست‌های یکسان دفن کند، بنابراین journalctl -b که بر اساس واحد فیلتر و از بالا خوانده شود بهتر از انتهای فهرست است.

چه کس دیگری پورت 1194 را گرفته است

مقصر معمولاً سرور دومی نیست که کسی عمداً پیکربندی کرده باشد. منتظر کلاینتی باشید که با دست اجرا شده و هنوز در ترمینال دیگری زنده است، یا پروفایل دومی که تصادفاً همان پورت را انتخاب کرده، یا بستهٔ فروشنده‌ای که تونل خودش 1194 را گرفته است. صاحب سوکت در ss -lunp دیده می‌شود؛ همان PID را به systemctl status بدهید تا بدانید واحدی مسئول است یا نه. آن را از مسیر کنترل خودش پایین بیاورید، نه با سیگنال.

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

واحدهای باقی‌مانده پس از حذف

حذف، فایل‌های باینری را پاک می‌کند؛ فایل‌های واحدی که با دست نوشته شده‌اند، معمولاً زیر /etc/systemd/system، از آن جان سالم به در می‌برند. سپس Systemd دوباره واحدی را امتحان می‌کند که به مسیری اشاره دارد که دیگر وجود ندارد، و پیام دربارهٔ همان فایل گمشده است نه حذف دیروز. systemctl status مسیر قطعهٔ واحد را نزدیک بالا نشان می‌دهد، پس پیش از پاک کردن هر چیزی آن را با dpkg -S بررسی کنید. وقتی یتیم رفت، systemctl daemon-reload و systemctl reset-failed وضعیت را پاک می‌کنند؛ وگرنه هر بررسی وضعیت بعدی آن را به ارث می‌برد.

وقتی which openvpn چیزی زیر /usr/local پاسخ می‌دهد، فایل باینری در بازی از نصب‌کنندهٔ فروشنده آمده است، نه از apt. چنین نصب‌کننده‌ای معمولاً شنوندهٔ خودش، ورودی بوت خودش و پوشهٔ پیکربندی خودش را می‌آورد، بنابراین حذف فرمان قابل مشاهده، سوکت را اشغال باقی می‌گذارد.

آن را به همان روشی که فروشنده مستند کرده حذف کنید، با ss -lunp تأیید کنید که پورت آزاد است، و کلاینت توزیع را فقط اگر لازم دارید اضافه کنید.

پیش از تلاش دوباره وضعیت را مرتب کنید

وضعیت شکست را پیش از نتیجه‌گیری از آن پاک کنید: systemctl reset-failed شمارنده‌ها را برمی‌دارد، و systemctl status سپس وضعیت کنونی واحد را گزارش می‌کند نه تاریخچه‌اش را. یک بار اجرایش کنید و ژورنال همان اجرا را بخوانید، نه وضعیت تجمیعی ماشین را. واحدی که فعال بودن را گزارش می‌کند در حالی که تونل چیزی حمل نمی‌کند، مشکلی جداست و بسیار رایج‌تر. این دو در گزارش‌های باگ یکی می‌شوند چون هر دو با این جملهٔ کاربر تمام می‌شوند که VPN کار نمی‌کند.

شاخه‌ای که انتخاب کردید را یادداشت کنید: تعارض پورت، نبود باینری، نبود پیکربندی. بار بعد سریع‌تر تشخیص داده می‌شود.