آیا آن اصلاح امنیتی OpenVPN حتی به نصب شما مربوط است؟
وصله کردن و پیکربندی دو ادعای متفاوت‌اند. فایل اجرایی، بستهٔ پشت آن و بررسی‌هایی را که نمایه واقعاً انجام می‌دهد مشخص کنید.
توصیه به وصله کردن کلاینت تا گواهی‌ها را اعتبارسنجی کند، برای اقدام کردن بیش از حد مبهم است. ممکن است نقص نرم‌افزاری رفع‌شده، یک ساخت قدیمی از یک ارائه‌دهنده، یا نمایه‌ای را توصیف کند که هرگز آن بررسی را نخواسته است. این‌ها سه تغییر متفاوت با سه مالک متفاوت‌اند. عمل کردن به این جمله بدون دانستن اینکه با کدام‌یک روبه‌رو هستید، همان روشی است که یک کلاینت سالم بی‌دلیل تغییر داده می‌شود.
سه ادعا را جدا کنید
نقص نرم‌افزاری یک اطلاعیه، نسخه‌های متأثر و یک انتشار اصلاح‌شده دارد. ساخت ارائه‌دهنده کانال توزیع خودش و آهنگ به‌روزرسانی خودش را دارد. حذف در نمایه هیچ‌یک از این دو را ندارد، چون فایل اجرایی سالم است و پیکربندی کمتر از آنچه فرض کرده بودید می‌خواهد. تا زمانی که ادعا یکی از این سه را نام نبرد، چیزی برای آزمودن نیست.
پیش از جست‌وجو، ادعا را در یک جمله بنویسید. اگر جمله نتواند بگوید چه چیزی خراب است، جست‌وجو هدفی ندارد و هر نتیجه‌ای مرتبط به نظر می‌رسد.
| Claim | Evidence that settles it | Who owns the change |
|---|---|---|
| Software defect | Advisory naming affected versions | Package or product maintainer |
| Provider build | Release notes for that client | The provider |
| Profile omission | The configuration actually loaded | Whoever owns the profile |
فایل اجرایی‌ای را پیدا کنید که واقعاً اجرا می‌شود
پیش از نگاه کردن به هر نسخه‌ای، مشخص کنید چه چیزی اتصال را آغاز می‌کند. یک سرویس توزیع، یک افزونهٔ رومیزی و یک برنامهٔ ارائه‌دهنده می‌توانند هر یک فایل اجرایی یا موتور متفاوتی به کار ببرند. نسخه‌ای که هر باینری‌ای که تصادفاً در مسیر جست‌وجوی پوسته باشد چاپ می‌کند، فهرست موجودی ماشین نیست. واحدی یا فرایندی را بخوانید که واقعاً اتصال را انجام داده است.
systemctl cat openvpn-client@*.service
ps -o pid,cmd -C openvpn
apt-cache policy openvpn network-manager-openvpnپرس‌وجوی بسته گزارش می‌دهد که فرادادهٔ محلی چه چیزی را نصب‌شده و در دسترس می‌داند، و آن حافظهٔ نهان می‌تواند کهنه باشد، پس نخست آن را تازه کنید. همچنین چیزی دربارهٔ اینکه آیا سرویس در حال اجرا باینری‌ای را بارگذاری کرده که پنج دقیقه پیش نصب شده است نمی‌گوید. سابقهٔ بسته را با فرایندی که واقعاً متصل است مقایسه کنید.
شواهد بسته به‌جای برداشت‌های نسخه
نگهداری امنیتی توزیع‌ها اغلب اصلاح‌ها را به عقب منتقل می‌کند، بنابراین نسخه‌ای از بالادست که قدیمی‌تر به نظر می‌رسد می‌تواند هنوز آن وصله را داشته باشد. عکس آن نیز درست است: بسته‌ای از مخزنی ناآشنا ادعای خودکار نگهداری کنونی ندارد. وضعیت پشتیبانی انتشار را بخوانید، نه شمارهٔ نسخه را.
این تمایز، تفاوت میان یک شکاف واقعی و شماره‌ای است که فقط قدیمی به نظر می‌رسد. مخزنی را که بسته از آن آمده ثبت کنید، چون همان رشتهٔ نسخه می‌تواند از کانال‌های بسیار متفاوت با پشتیبانی بسیار متفاوت برسد.
پیکربندی نیمهٔ دیگر است
فایل اجرایی نگهداری‌شده هنوز به نمایه‌ای نیاز دارد که بررسی‌هایی را بخواهد که فکر می‌کنید برقرارند. لنگرهای اعتماد، نقش موردنظر همتا و نام سرور مورد انتظار تصمیم‌هایی مرتبط اما جدا هستند. بررسی نقش، بررسی نام نیست و هیچ‌کدام جایگزین دیگری نمی‌شود. اگر هشدار دربارهٔ پیکربندی است، اصلاح متعلق به کسی است که نمایه را دارد.
برای جبران یک نمایهٔ تأییدنشده وصلهٔ دلبخواهی نصب نکنید، و برای ترمیم یک نقص واقعی پیاده‌سازی دستوری نیفزایید. هر دو اشتباه پیشرفت به نظر می‌رسند، و به همین دلیل هر دو ادامه دارند.
با شواهد موجود در سابقه تصمیم بگیرید
تصمیم از آنچه مشخص کرده‌اید برمی‌آید. بستهٔ متأثر مستند، به‌روزرسانی پشتیبانی‌شدهٔ خود را می‌طلبد، سکوی پشتیبانی‌نشده به مسیر مهاجرت نیاز دارد، و کلاینت ارائه‌دهنده به راهنمایی همان ارائه‌دهنده نیاز دارد. دستور مبهم پیش از آنکه هر یک از این‌ها اعمال شود به یک اطلاعیه و یک مؤلفهٔ متأثر نیاز دارد.
کلاینت فعال، نسخهٔ کامل، اطلاعیه و مالک نمایه را با هم در سابقهٔ تغییر نگه دارید. این از ارجاع به یک آموزش قوی‌تر است و همان چیزی است که نفر بعدی واقعاً به آن نیاز خواهد داشت.