به‌روزرسانی‌های بدون‌نظارت سرور VPN به مسیر بازیابی آزموده‌شده نیاز دارند
یک به‌روزرسانی می‌تواند همان سرویسی را راه‌اندازی مجدد کند که با آن به سرور می‌رسید. پیش از خودکارسازی، کنسول خارج از باند را با طرح بازیابی فقط از طریق تونل مقایسه کنید.
به‌روزرسانی‌های بدون‌نظارت سیاستی معقول برای سروری است که از طریق VPN خودش به آن می‌رسید، و در همان حال یک نقطه شکست واحد است که خودتان ایجاد می‌کنید. عملیات بسته سرویس را دوباره راه‌اندازی می‌کند، تونل می‌افتد و مسیر مدیریتی که استفاده می‌کردید همراه آن ناپدید می‌شود. دو مدل بازیابی وجود دارد و انتخاب میان آن‌ها به یک شرط بستگی دارد: آیا مسیر ورودی دارید که از چیزی که به‌روزرسانی می‌شود عبور نمی‌کند.
دو مدل بازیابی، یک شرط تعیین‌کننده
مدل نخست به به‌روزرسانی اعتماد می‌کند و فرض می‌گیرد که پس از آن می‌توانید دوباره متصل شوید. این مدل وقتی کار می‌کند که VPN یکی از چند راه رسیدن به میزبان باشد و شکست تونل توانایی شما برای عیب‌یابی آن را از بین نبرد. مدل دوم از پیش یک مسیر مستقل، معمولاً کنسول ارائه‌دهنده میزبانی، را قرار می‌دهد و تونل را چیزی می‌داند که نگهداری بیشترین احتمال شکستنش را دارد. هر دو مدل قابل دفاع‌اند و تنها یکی از آن‌ها کار پیشاپیش می‌خواهد.
شرط تعیین‌کننده را آسان می‌توان گفت و آسان می‌توان نادیده گرفت. اگر هر مسیر مدیریتی به دستگاه از سرویس در حال به‌روزرسانی بگذرد، هیچ مدل بازیابی ندارید، فقط یک انتظار. این را در بازبینی تغییر با صدای بلند بگویید.
آزمودن آن شرط ده دقیقه طول می‌کشد و باید پیش از نخستین به‌روزرسانی بدون‌نظارت رخ دهد، نه هنگام حادثه. کنسول را زمانی که همه چیز کار می‌کند باز کنید، تأیید کنید که اعتبارنامه‌ها به‌روزند و دوباره ببندید. تأیید کنید که کنسول روی همان میزبانی باز می‌شود که فکر می‌کنید. سپس تأیید کنید که ورودی‌ای که واقعاً ساعت 3 بامداد استفاده می‌کردید هنوز کار می‌کند.
آن بخش آخر مهم‌تر از آن است که به نظر می‌رسد. حسابی از کنسول که گذرواژه‌اش شش ماه پیش چرخانده شده و هرگز بررسی نشده، مسیر بازیابی نیست؛ سندی است که چنین مسیری را توصیف می‌کند.
چیزی که نسخه پشتیبان بازیابی نمی‌کند
بایگانی پیکربندی سندی از فایل‌هاست و به‌روزرسانی بیش از فایل‌ها را تغییر می‌دهد. وضعیت بسته‌ها، ماژول‌های هسته، پیوندهای واحدهای فعال‌شده و قواعد دیوار آتش که با ابزاری جداگانه اعمال شده‌اند همه بیرون از پوشه پیکربندی زندگی می‌کنند، و بازیابی‌ای که آن‌ها را نادیده بگیرد ماشینی می‌سازد که پیکربندی‌شده به نظر می‌رسد و عبور نمی‌دهد.
| What changed | Restored by a configuration backup | Needs its own action |
|---|---|---|
| Service unit or startup ordering | Partly, if the unit file was included | Package state and enabled links |
| Kernel module or interface support | No | Kernel or module rollback, or a boot-time decision |
| Peer or device authorization | Only if the backup predates the revocation | A deliberate decision about which peers return |
| Firewall rules applied outside the config | Only if they were captured | Replaying and verifying each rule |
مجوزدهی سطر خودش را می‌خواهد. نسخه پشتیبانی که پیش از حذف دستگاهی آلوده گرفته شده باشد با خوشحالی دسترسی آن دستگاه را بازمی‌گرداند. بازگشت به آن در میانه قطعی همان راهی است که یک حادثه به دو حادثه تبدیل شود، و تصمیم بازیابی باید درباره همتاها همان‌قدر صریح گرفته شود که درباره فایل‌ها گرفته می‌شود.
سازوکار بازگشت هم مهم است. کپی کردن یک فایل اجرایی قدیمی‌تر روی فایلی که بسته مدیریتش می‌کند، بازگردانی پشتیبانی‌شده یک تغییر بسته نیست و پایگاه داده بسته‌ها را وادار می‌کند وضعیتی را توصیف کند که فایل‌سیستم با آن نمی‌خواند. از مسیر تنزل خود مدیر بسته یا عکسی که ارائه‌دهنده پیشنهاد می‌کند استفاده کنید. تنزلی که پایگاه داده بسته‌ها ثبت کند، تنزلی است که می‌توانید تکرار کنید.
هیچ‌یک از این‌ها علیه نسخه‌های پشتیبان نیست. به سود دانستن این است که هر مصنوع کدام لایه را می‌پوشاند، زیرا حالت شکست یک بازیابی جزئی گیج‌کننده‌تر از قطعی اولیه است. لایه را کنار هر نسخه پشتیبان در ران‌بوک بنویسید.
نقطه بازرسی، به‌روزرسانی و سپس تأیید از بیرون
وضعیت پیش از تغییر را به شکلی ثبت کنید که بعداً بتوانید مقایسه کنید: نسخه‌های نصب‌شده، واحدهای سرویس درگیر، سوکت‌های شنونده و فهرست کنونی همتاها. چهار فرمان بیشتر این را روی میزبان لینوکس پوشش می‌دهد.
systemctl list-units --type=service | grep -E 'openvpn|wg-quick'
ss -lunp | grep -E ':51820|:1194'
journalctl -u wg-quick@wg0 --since '-10 min'نخستین نشان می‌دهد چه واحدهایی وجود دارند و آیا در حال اجرا هستند، دومی تأیید می‌کند که شنونده واقعاً متصل است، و سومی روایت خود سرویس از چند دقیقه گذشته را به شما می‌دهد. هیچ‌یک اثبات نمی‌کند که کارخواهی می‌تواند متصل شود، به همین دلیل گام بعدی بیرون از میزبان رخ می‌دهد. آن خوانده‌ها را خط پایه مقایسه خود نگه دارید.
از شبکه‌ای که از تونل استفاده نمی‌کند تأیید کنید: یک کارخواه مجاز را احراز هویت کنید، نامی را تفکیک کنید و به یک برنامه موردنظر برسید. سطر وضعیت محلی که می‌گوید واسط بالاست، ادعایی درباره واسط است، نه درباره مسیریابی، کلیدها یا سیاستی که همتایی را می‌پذیرد.
سپس مسیر اتصال دوباره را آگاهانه بیازمایید. سرویس را یک بار دوباره راه‌اندازی کنید و تأیید کنید که تونل بدون دخالت دستی برمی‌گردد، زیرا سرویسی که فقط هنگام راه‌اندازی درست شروع می‌شود سرویسی است که در بدترین لحظه غافلگیرتان می‌کند.
وقتی شکست خورد، از مسیری که آزموده‌اید استفاده کنید
دنباله بازیابی چشمگیر نیست و کار می‌کند: از مسیر مستقل به میزبان برسید، گزارش‌های خود سرویس را بخوانید و همان نقطه بازرسی مشخصی را که با شکست می‌خواند بازیابی کنید. در هر تلاش یک چیز را تغییر دهید تا خواندن بعدی گزارش معنایی داشته باشد.
در برابر وسوسه انجام چند تغییر ثبت‌نشده برای بازگرداندن اتصال مقاومت کنید. ماشینی که با پنج ویرایش همزمان درست شده باشد بعداً قابل توضیح نیست، و به‌روزرسانی بعدی هرکدام از آن‌ها را که واقعاً بار را حمل می‌کرد دوباره برمی‌گرداند.
سپس سیاست دائمی را با شواهد تصمیم بگیرید. اگر به‌روزرسانی وابستگی‌ای را آشکار کرد که کسی مستندش نکرده بود، اصلاح آن مستندسازی و یک آزمون است، نه خاموش کردن به‌روزرسانی‌ها. اگر سرویسی را آشکار کرد که نمی‌تواند پاک راه‌اندازی مجدد شود، اصلاح در واحد است، نه در زمان‌بندی.
مقایسه به‌محض نام‌گذاری شرط پاک حل می‌شود. مسیر مستقل به‌روزرسانی‌های بدون‌نظارت را ریسکی قابل مدیریت می‌کند. نبودش همان سیاست را به قطعی زمان‌بندی‌شده‌ای با زمان بازیابی ناشناخته تبدیل می‌کند، و هیچ مقدار خودکارسازی آن حساب را تغییر نمی‌دهد.