Відкат сервера — це рішення про те, який рівень відмовив, а не вправа з копіювання файлів. Конфігурація, облікові дані та версії пакетів рухаються за різними годинниками, і відновлення одного, коли інші лишаються актуальними, дає хост, що виглядає здоровим і поводиться непослідовно. Послідовність нижче припускає, що зміна вже пішла не так, і просить відновити найменший узгоджений стан. Пройдіть її по порядку і вважайте перевірку доступу поза основним каналом кроком, який ніхто не повинен пропускати.

Зробіть контрольну точку, яку справді зможете відновити

Запишіть конфігурацію, яку служба читає під час запуску, разом із версією, яка останньою її розібрала. Файл, що чисто завантажувався в попередньому випуску, після оновлення може бути відхилений або мовчки проігнорований, тому версія належить до тієї самої нотатки. Додайте матеріал, на який посилається конфігурація: закриті ключі, шляхи до сертифікатів, визначення слухачів і записи DNS та міжмережевого екрана, які роблять службу доступною. Якщо для відновлення знадобиться файл, який ви не зберегли, контрольна точка неповна.

Назвіть власника кожного налаштування, поки система ще здорова. Маршрут, встановлений панеллю провайдера, доданий міжмережевим екраном хоста і надісланий клієнтам, — три різні об'єкти, і відновлення не того залишає два інші на місці. Достатньо короткої таблиці з налаштуванням, власником і шляхом до файлу.

Тримайте відкликання окремо від конфігурації

Стара конфігурація може тихо знову під'єднати пристрій, який ви навмисно видалили, і це перетворює відновлення на регрес безпеки. Збережіть поточний список відкликання і вимкнені облікові записи, поки відновлюєте мережеву політику, а потім застосуйте їх знову, перш ніж служба почне приймати клієнтів.

Ставтеся до стану ідентичності як до окремого відкату з власними доказами. Файли відкликання сертифікатів, вимкнення облікових записів і реєстрація MFA рідко лежать там само, де конфігурація демона, і відновлення конфігурації їх не зачепить. Спершу перевірте поточний стан, щоб знати, що має вижити. Після відновлення переконайтеся, що видалена ідентичність досі не може підключитися.

Дістаньтеся хоста, коли тунель відмовляє

Відкрийте шлях до машини, що не залежить від змінюваного компонента. Консоль гіпервізора, адреса керування на окремому інтерфейсі або послідовна консоль підходять усі; сеанс SSH, перенесений через тунель, — ні. Якщо єдиний вхід — це VPN, який ви збираєтеся перезапустити, неправильний маршрут або правило міжмережевого екрана позбавляє вас можливості це виправити. Перевірте альтернативний шлях до зміни, а не після. Увійдіть через нього один раз, переконайтеся, що sudo працює, і запишіть точну адресу, яку використали.

Перевірка проста: опустіть тунель, залишаючись підключеним через альтернативний шлях, і подивіться, чи виживе сеанс. Якщо він обірветься, ви знайшли відмову раніше, ніж вона змогла вас замкнути.

Застосуйте одну ревізію і знайте, коли вона набуває чинності

Використайте документацію служби щодо reload або restart і з'ясуйте, які директиви читаються в який момент. Деякі значення діють під час reload, інші лише коли починається новий сеанс або процес, тому редагування файлу нічого не доводить про робочий стан. Відновіть одну ревізію замість змішування нового файлу зі старим станом виконання. За сумніву повний перезапуск служби легше обґрунтувати, ніж частковий reload.

Перевірте визначення юніта перед вибором: systemctl show -p ExecReload openvpn@server повідомляє, чи існує взагалі хук reload. Потім застосуйте ревізію і прочитайте в журналі перші нові помилки, перш ніж міняти будь-що інше.

Перевірте, запишіть і дослідіть після

Підключіть одного авторизованого клієнта і перевірте, для чого потрібна служба: розв'язання імен, повторне підключення і застосунок, що відмовив. Переконайтеся, що відкликану ідентичність досі відхиляють. Запишіть відновлену ревізію, час і причину, бо наступному оператору знадобляться всі три. Відкат, який ніхто не задокументував, стає загадкою наступного разу, коли служба поводиться погано.

systemctl status openvpn@server --no-pager
journalctl -u openvpn@server -n 50 --no-pager

Коли служба стане стабільною, відтворіть невдалу зміну на хості або знімку, який можна викинути. Це відділяє погану конфігурацію від поганого пакета або простроченого сертифіката. Тримайте відновлену конфігурацію під контролем версій, щоб наступна контрольна точка починалася з відомого коміту. Сенс вправи — задокументована кінцева точка, а не постійне зниження версії.

Схожі статті