OpenVPN 3 Linux: پیش از بازگرداندن نسخه، خطای D-Bus را بخوانید
پنج سرویس، یک فرانت‌اند. خطای D-Bus را به مؤلفه‌ای که رد کرده است نسبت دهید، بررسی کنید جلسه‌ای وجود دارد یا نه، سپس در همان مرز اصلاح کنید.
خرابی‌های OpenVPN 3 Linux به شکل خطای متد D-Bus با نامی ناآشنا می‌رسند، و وسوسه آن است که بسته را به نسخهٔ پایین‌تر برگردانید و امیدوار باشید. کارخواست یک برنامه نیست: یک فرانت‌اند خط فرمان از طریق گذرگاه با سرویس‌هایی گفتگو میکند که صاحب پروفایل‌ها، جلسه‌ها، موتور VPN و تغییرات شبکه‌ای ممتاز هستند. تصمیم‌گیری دربارهٔ اینکه کدام‌یک از این پنج صاحب فراخوانی ناموفق است بیشترِ عیب‌یابی است و به‌جای بازگرداندن نسخه، تنها یک فرمان هزینه دارد. آنچه می‌آید همان تصمیم است، به ترتیبی که خرابی‌ها معمولاً ظاهر می‌شوند.
پنج صاحب پشت یک فرمان
پنج فرایند اهمیت دارند و هر یک نام گذرگاه خودش را دارد: فرانت‌اندی که فرمان شما را می‌پذیرد، مدیر پیکربندی که پروفایل‌ها و سیاست دسترسی آن‌ها را نگه می‌دارد، مدیر جلسه‌ها که صاحب طول عمر جلسه است، بخش پشتی که اتصال را از طریق OpenVPN 3 Core Engine اجرا میکند، و سرویس پیکربندی شبکه که رابط، مسیرها و تنظیمات DNS را نصب میکند. پس خطایی که یک شیء پیکربندی را نام می‌برد خطای بخش پشتی نیست، و بخش پشتی‌ای که شروع نمی‌شود شکست احراز هویت نیست. دسته‌بندی پیام در یکی از آن سطرها باید پیش از تغییر هر چیزی رخ دهد، چون هر گام بعدی به این بستگی دارد که کدام سطر درست است. حدس زدن سطر همان راهی است که یک اصلاح کوتاه به یک بعدازظهر کار روی بسته‌ها تبدیل می‌شود.
پیش از پرسیدن هر چیز دیگری از گذرگاه سیستم بپرسید چه سرویس‌هایی حاضرند، سپس تأیید کنید که قطعه‌های نصب‌شده بر یک نسخه توافق دارند. OpenVPN 3 Linux آن سرویس‌ها را به‌عنوان واحدهای سیستم ثبت میکند، پس گذرگاهی که باید پرسیده شود گذرگاه سیستم است، پرسش نسخه به اختیار مدیریتی نیاز دارد، و فهرستی که با --user ساخته می‌شود نشست ورود شما را می‌خواند، جایی که واحدها هرگز ظاهر نمی‌شوند. سرویس‌ها بر حسب تقاضا فعال می‌شوند و برخی هنگام بی‌کاری پایان می‌یابند، پس سرویسی که پیش از نخستین درخواست شما غایب است به‌سادگی هنوز دربارهٔ هیچ چیز پرسیده نشده است. سه فرمان زیر دربارهٔ حضور، نسخه و وضعیت واحد پاسخ می‌دهند بدون آنکه نشست VPN باز کنند.
sudo busctl list | grep -i openvpn
sudo openvpn3-admin version --services
systemctl list-units 'openvpn3*'هر فهرست در واقع چه چیزی را اثبات میکند
دیدگاه‌های خود کارخواست ارزان‌ترین شاهد در دسترس‌اند و هر یک از آن‌ها کمتر از آنچه به نظر می‌رسد اثبات میکند. پروفایلی در فهرست پیکربندی نشان می‌دهد که پروفایلی وارد شده است و هیچ چیز دربارهٔ اینکه کسی اجازهٔ اتصال با آن را دارد. جلسه‌ای در فهرست جلسه‌ها نشان می‌دهد که شیء جلسه وجود دارد و هیچ چیز دربارهٔ اینکه احراز هویت از راه دور تمام شده است یا نه.
openvpn3 configs-list
openvpn3 sessions-listمسیرهای شیء در آن خروجی‌ها به اشیای مدیریت‌شده روی گذرگاه اشاره می‌کنند نه فایل‌ها، پس قابل ویرایش نیستند، و مسیری که قبلاً ثبت شده با لحظه‌ای که آن جلسه قطع می‌شود کهنه می‌شود. استفادهٔ دوباره از یکی از یادداشت‌هایتان خطاهای "no such object" تولید میکند که هیچ ارتباطی با VPN ندارند. جدول مرحله‌های زیر آنچه هر گام اتصال برپا میکند را از آنچه باز می‌گذارد جدا میکند، و تصمیم بازگرداندن نسخه دقیقاً بر همین تفاوت استوار است. سطری را بخوانید که با شاهد شما می‌خواند، سپس متن خطا را دوباره بخوانید.
| Stage | What exists | What proves it | What it does not prove |
|---|---|---|---|
| Profile imported | A configuration object held by the configuration manager | The profile is listed by the client | That the profile owner permits a connection |
| Session requested | A session object held by the session manager | The session appears in the session list | That the remote side accepted the credentials |
| Connect dispatched | An asynchronous attempt on the VPN backend | Status changes arrive for that session | That an interface was configured |
| Tunnel configured | An interface, routes and DNS settings | The network service reports success and routes appear | That traffic reaches the peer |
فراخوانی اتصال پیش از وجود تونل بازمی‌گردد
فراخوانی اتصال به شما جلسه‌ای برای پیگیری می‌دهد و بازمی‌گردد، از این رو فراخوانی به‌ظاهر موفق که سکوت به دنبال دارد یک وضعیت میانی طبیعی است نه تناقض. فرانت‌اند همچنان باید تغییرات وضعیت را دنبال کند و به هر درخواست تعامل پاسخ دهد. پروفایلی که به یک اعتبارنامه نیاز دارد و پاسخی نمی‌گیرد در وضعیتی منتظر می‌ماند که درست مانند یک بخش پشتی معلق به نظر می‌رسد. آن وضعیت انتظار شایستهٔ شناخته‌شدن است، چون مردم را به مؤلفهٔ نادرست می‌فرستد.
در حالی که تلاشی در جریان است، فهرست جلسه‌ها و گزارش خود فرانت‌اند را برای آن پروفایل زیر نظر بگیرید. جلسه‌ای که هرگز وضعیت آغازینش را ترک نمی‌کند مؤلفه‌ای را نام می‌برد که متوقف شده، و گزارش معمولاً آن را در نخستین سطرها نام می‌برد. نام پروفایل را در دسترس نگه دارید، چون فرمان گزارش یک پروفایل می‌گیرد نه مسیر جلسه، که دلیل دیگری است برای خواندن دوبارهٔ فهرست به‌جای استفادهٔ دوباره از یک مسیر.
openvpn3 sessions-list
openvpn3 log --config <profile> --level 6خواندن گزارش یک مؤلفه بدون گشودن جلسه
وقتی فرانت‌اند چیز سودمندی گزارش نمی‌کند، به مؤلفه‌ای که خرابی را در گزارش ثبت کرده است بروید به‌جای آنکه اتصال تازه‌ای آغاز کنید. با یک ثبت‌کنندهٔ پیکربندی‌شدهٔ systemd-journald، نمای محدود گزارش مدیر رویدادهای یک مؤلفه را می‌خواند بدون دست زدن به سیاست گذرگاه و بدون گشودن جلسه، و این مهم است چون عیب‌یابی‌ای که سامانهٔ اندازه‌گیری‌شده را تغییر می‌دهد بسیار کم اثبات میکند. بر حسب واحد پالایش کنید نه بر حسب برچسب syslog: واحدهای خدمت منفرد شناسهٔ مشترکی را تضمین نمی‌کنند، پس پرسش بر حسب برچسب می‌تواند صفحه‌ای خالی برگرداند در حالی که خود واحد خرابی را ثبت کرده است.
پیش از کمک خواستن از کسی چهار میدان را ثبت کنید: نام کامل خطا، سرویس و شیء درگیر، مهر زمانی و نسخه‌های بسته‌های نصب‌شده. این‌ها همان چیزی است که نگه‌دارنده لازم دارد، و هیچ‌یک از آن‌ها لازم نمی‌کند پروفایل یا اعتبارنامه‌ای را در تیکت بچسبانید. گستردن سیاست دسترسی گذرگاه برای خاموش کردن خطا عیب‌یابی نیست، مرزی را پاک میکند که مؤلفه را به‌جای شما نام می‌برد. محتوای خصوصی پروفایل‌ها بیرون از گزارش‌های مشترک می‌ماند به همان دلیلی که اعتبارنامه‌ها بیرون می‌مانند.
journalctl -u 'openvpn3-service-*' -n 50 --no-pager
openvpn3-admin journal --service <name>اصلاح مرزی که رد کرد
هر سطر از نقشه اصلاح خودش را دارد و سطرها جای یکدیگر را نمی‌گیرند. عملیات ردشده روی یک پروفایل پرسشی دربارهٔ سیاست و مالکیت است، در حالی که بخش پشتی‌ای که فعال نمی‌شود پرسشی دربارهٔ سرویس‌ها و بسته‌بندی است. سروری که احراز هویت را رد میکند هیچ‌یک از این دو نیست، پس تغییرهای مکرر گذرواژه نمی‌تواند مشکلی محلی در فعال‌سازی را درست کند. انتخاب اصلاح نادرست همان راهی است که یک مشکل سیاست به نصب دوباره تبدیل می‌شود.
پس از تغییر بسته‌ها، نصب همخوان و پشتیبانی‌شده را بررسی کنید به‌جای آنکه یک فایل دودویی کهنه را در جای خود کپی کنید. بازگرداندن کنترل‌شدهٔ نسخه پاسخ مشروعی به یک پس‌رفت تأییدشده است، به شرط آنکه بسته‌ها سازگار بمانند و راهی برای بازگشت به نگهداری پشتیبانی‌شده وجود داشته باشد. آن راه را پیش از آنکه سرویس از راه‌اندازی بازماند برقرار کنید، نه بعد از آن.
سکوی دیگری می‌تواند همان کتابخانهٔ هستهٔ VPN را شریک باشد بدون آنکه سرویس‌های گذرگاه لینوکس را شریک شود، پس خرابی مشابه در ویندوز هیچ چیزی دربارهٔ این یکی نمی‌گوید. نمای کلی D-Bus مسیرهای شیء را که برای پیکربندی‌ها و جلسه‌ها عرضه می‌شوند مستند میکند، و همین بخش از معماری است که این عیب‌یابی بر آن استوار است. یک بار بخوانیدش، و خطای بعدی با مؤلفه‌ای که از پیش به آن پیوسته است خواهد آمد.