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

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

سرویسی را که وجود دارد پیش از تغییرش ثبت کنید

واحد نصب‌شده را بخوانید، نه واحدی را که به یاد دارید نوشته‌اید: systemctl cat [email protected] واحد و هر drop-in را چاپ می‌کند، و systemctl show [email protected] -p ExecStart -p User -p WorkingDirectory نشان می‌دهد واقعاً چه چیزی و به نام چه کسی اجرا می‌شود. از باینری‌ای که آن واحد نام می‌برد بپرسید، چون openvpn --version از یک پوسته ممکن است به ساخت دیگری اشاره کند. مسیر پروفایل و هر فایلی که به آن ارجاع می‌دهد را ثبت کنید.

به سوکت‌های شنود هم توجه کنید: ss -lunp | grep 1194 می‌گوید امروز کدام نشانی و پروتکل در اختیار دیمن است. اگر پاسخ آن چیزی نیست که پروفایل پیشنهاد می‌دهد، یک drop-in یا فایل محیطی آن را نادیده می‌گیرد و به‌روزرسانی همان غافلگیری را به ارث می‌برد.

مجموعه بازیابی‌ای بسازید که شخص دیگری هم بتواند استفاده کند

مجموعه بازیابی باید ساعت 03:00 بدون زمینه ذهنی شما برای همکاری قابل استفاده باشد. پیکربندی مؤثر را با هر فایل ارجاع‌شده، مواد اعتماد و ابطال تحت کنترل مالک PKI، تخصیص‌ها و قلاب‌های هر کلاینت، و نسخه‌های دقیق بسته‌های نصب‌شده امروز را بگنجانید. کپی از یک نام فایل پیکربندی نیست. آن را جایی نگه دارید که اپراتور کشیک بدون VPN به آن دسترسی داشته باشد.

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

روی یک شنونده آزمایشی با کلاینت واقعی تمرین کنید

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

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

یک بار تغییر دهید، از مسیری بیرون تونل

پنجره را از کنسول یا شبکه‌ای مدیریتی شروع کنید که از سرویس عبور نمی‌کند. تأیید کنید کاربران آگاه شده‌اند و اپراتور دوم می‌داند چطور بازگردانی کند. تغییر آماده‌شده را از طریق مالکش اعمال کنید، سپس با sudo systemctl restart [email protected] راه‌اندازی مجدد کنید و ژورنال را با journalctl -u openvpn-server@office -b -f دنبال کنید. وقتی فقط تعریف‌های واحد تغییر کرده، بارگذاری مجدد کافی است؛ پروفایل تغییرکرده به راه‌اندازی مجدد فرایند نیاز دارد.

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

بپذیرید یا بازگردانید، سپس به کاربران بگویید چه چیزی تغییر کرد

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

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

مقالات مرتبط