یک راه‌حل قدیمی فایل اجرایی OpenVPN را جای دیگری برد و یک پوشش‌دهندهٔ shell در مسیر اصلی باقی گذاشت. ماه‌ها بعد به‌روزرسانی می‌رسد و برگرداندن آن راه‌حل به بازی حدس زدن دربارهٔ اینکه کدام فایل واقعاً کلاینت است تبدیل می‌شود. نام فرمان، فایل اجرایی پیکربندی‌شده در سرویس و فهرست فایل‌های خود بسته می‌توانند همگی به اشیاء متفاوتی اشاره کنند، و تعمیر یکی بدون بقیه میزبان‌ی می‌سازد که درست به نظر می‌رسد و بدتر رفتار می‌کند.

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

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

از واحد بپرسید چه چیزی اجرا می‌کند، از جمله drop-inهایی که آن را تغییر می‌دهند، و خط ExecStart حاصل را بخوانید نه بخشی را که آن را معتبر می‌پندارید. سپس آن مسیر را از هر پیوند نمادین تا فایل نهایی دنبال کنید. پوشش‌دهنده‌ای که با exec به یک پوشهٔ پنهان ختم می‌شود، آرایش رایجی از این تعمیرهای قدیمی است.

پیش از تغییر هر چیزی، مسیر حل‌شده را یادداشت کنید.

systemctl cat [email protected] | grep -n 'ExecStart'
readlink -f "$(command -v openvpn)"

نام فرمان را با مسیر سرویس مقایسه کنید

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

آنچه مهم است دانستن این است که کدام مالک فرآیندی را راه‌اندازی می‌کند که ترافیک را سرویس می‌دهد. اگر واحد /usr/local/sbin/openvpn-wrapper را اجرا کند در حالی که shell شما /usr/sbin/openvpn را حل می‌کند، تعمیر فایل دوم هیچ چیز را در سرویس تغییر نمی‌دهد.

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

بگذارید پایگاه دادهٔ بسته دربارهٔ فایل‌های بسته حرف بزند

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

تأیید را اجرا کنید و خروجی را بخوانید، نه اینکه نتیجهٔ خالی را مدرکی برای چیزی بدانید.

dpkg -S /usr/sbin/openvpn
dpkg --verify openvpn

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

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

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

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

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

راه‌اندازی را تأیید کنید، سپس پوشش‌دهنده را بردارید

پس از تعمیر، سرویس را راه‌اندازی کنید و تأیید کنید که فرآیند مسیری را که در نظر داشتید اجرا می‌کند. پرس‌وجوی نسخه‌ای که دستی اجرا شود ثابت می‌کند فایل کار می‌کند؛ ثابت نمی‌کند که واحد از آن استفاده می‌کند.

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

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

مقالات مرتبط