journalctl برای گزارش‌های VPN: کدام واحد مالک اتصال است؟

با واحدی از systemd شروع کنید که واقعاً مالک اتصال VPN است، نه با فرمان گزارشی که به یاد دارید. سرویس مستقیم OpenVPN، یک واحد wg-quick و یک پروفایل NetworkManager پیام‌های مفید خود را در واحدهای مختلف می‌گذارند و پرس‌وجو از واحد اشتباه نتیجه خالی می‌دهد که شبیه سکوت است. سه مالک رایج را مقایسه کنید، پنجره را باریک کنید و سپس مراحل را به ترتیب بخوانید.

سه مالک رایج را مقایسه کنید

سرویس کلاینت OpenVPN معمولاً یک واحد نمونه است که به نام پروفایل نام‌گذاری شده، مانند [email protected]. پیام‌های آن شامل مسیر پیکربندی، تجزیه گزینه‌ها، دست‌دهی TLS و نصب مسیری است که کلاینت انجام می‌دهد.

واحد wg-quick به‌طور طراحی ساکت‌تر است. پیکربندی رابط در آغاز انجام می‌شود، دست‌دهی را هسته انجام می‌دهد و بازتولید کلیدهای معمول به‌طور پیش‌فرض ثبت نمی‌شود، بنابراین wg show اغلب از گزارش گویاتر است. این تفاوت وقتی مهم است که پروتکلی را که مذاکره را ثبت می‌کند با پروتکلی که ثبت نمی‌کند مقایسه کنید.

NetworkManager مالک پروفایل‌هایی است که ساخته و پیام‌هایش زیر NetworkManager.service زندگی می‌کنند، حتی وقتی افزونه زیرین یک کمک‌کننده VPN است. وقتی پروفایل به این شکل مدیریت می‌شود، هم از مدیر و هم از واحد کمک‌کننده بپرسید.

پرس‌وجو را به یک واحد و یک پنجره محدود کنید

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

journalctl -u [email protected] --since today
systemctl list-units --type=service | grep -i vpn
systemctl cat [email protected]

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

نخستین مرحله ناموفق را بخوانید

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

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

سرویس ناموفق را با کلاینت دستی مخلوط نکنید

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

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

گزیده‌ای به اشتراک بگذارید، نه یک خروجی کامل

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

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