Връщането на сървър назад е решение за това кой слой е отказал, а не упражнение по копиране на файлове. Конфигурацията, идентификационните данни и версиите на пакетите се движат по различни часовници и възстановяването на едно, докато другите остават актуални, създава хост, който изглежда здрав и се държи непоследователно. Последователността по-долу предполага, че промяна вече се е объркала, и ви моли да възстановите най-малкото съгласувано състояние. Минете я по ред и приемете проверката на достъпа извън обхвата като стъпка, която никой не бива да пропуска.

Направете контролна точка, която наистина можете да възстановите

Запишете конфигурацията, която услугата чете при стартиране, заедно с версията, която я е анализирала последно. Файл, който се е зареждал чисто при по-старо издание, може да бъде отхвърлен или тихо игнориран след надграждане, затова версията принадлежи в същата бележка. Включете материала, към който сочи конфигурацията: частни ключове, пътища до сертификати, дефиниции на слушатели и записите за 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

След като услугата е стабилна, възпроизведете неуспешната промяна на хост или моментна снимка, които можете да изхвърлите. Това отделя лоша конфигурация от лош пакет или изтекъл сертификат. Дръжте възстановената конфигурация под контрол на версиите, за да започва следващата контролна точка от известен комит. Смисълът на упражнението е документирана крайна точка, а не постоянно понижаване.

Подобни статии