OpenVPN بدون هیچ خطایی اجرا نمی‌شود؟ به ژورنال نگاه کنید

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

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

سکوت یعنی شما کانال درست را تماشا نمی‌کردید

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

systemctl status openvpn-client@office
journalctl -u openvpn-client@office -b --no-pager

برای جدا کردن خروج تمیز از سیگنال، این را اضافه کنید: systemctl show -p Result -p ExecMainStatus openvpn-client@office. وضعیت 1 همراه با Result=exit-code یک تصمیم برنامه است؛ Result=signal یا یک تایم‌اوت به‌جای آن به محیط اشاره می‌کنند، و هیچ مقدار ویرایش پروفایل آن‌ها را تغییر نمی‌دهد. هر دو مقدار را پیش از راه‌اندازی مجدد هر چیزی ثبت کنید، چون راه‌اندازی مجدد وضعیت گذرایی را که آن‌ها را تولید کرده پاک می‌کند.

نام نمونه بخشی از مسیر است

واحد قالب بسته‌بندی‌شده مسیر فایل نمی‌گیرد. نام نمونه می‌گیرد و آن نام به یک پوشه افزوده می‌شود تا پروفایل پیدا شود: office به /etc/openvpn/client/office.conf در بسته‌بندی Debian و Ubuntu حل می‌شود. فایلی به نام office-v2.conf که به‌صورت @office آغاز شده باشد هرگز خوانده نمی‌شود، و واحد بی‌صدا خارج می‌شود چون از دید آن کاری نبود که انجام شود. پوشه جست‌وجو بین حالت کلاینت و سرور متفاوت است، بنابراین همان اشتباه هنگام تغییر قالب به جای کاملاً دیگری اشاره می‌کند.

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

ls -l /etc/openvpn/client/
systemctl list-units 'openvpn*' --all

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

وقتی افزونه مالک تونل است، ترمینال چیزی نمی‌بیند

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

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

journalctl -b -u NetworkManager --no-pager | grep -i -A3 openvpn
openvpn --config /etc/openvpn/client/office.conf --verb 4 --log /tmp/ovpn.log

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

دو باینری، یک PATH

ساخت دستی نصب‌شده زیر /usr/local در فراخوانی شل برنده است، چون /usr/local/sbin پیش از /usr/sbin در PATH پیش‌فرض Ubuntu می‌آید. واحد از PATH شما استفاده نمی‌کند؛ مسیر مطلقی را که در ExecStart نوشته شده اجرا می‌کند. پس نسخه‌ای که در ترمینال شما کار می‌کند و نسخه‌ای که به‌عنوان سرویس شکست می‌خورد، واقعاً می‌توانند برنامه‌های متفاوتی باشند.

پیش از بازسازی هر چیزی، این دو را مقایسه کنید. دستور سوم همانی است که تصمیم را می‌گیرد.

command -v openvpn
whereis openvpn
systemctl cat openvpn-client@office | grep ExecStart

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

شکست‌هایی که کلاینت نمی‌تواند گزارش کند

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

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

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