Автоматичните обновления на VPN сървър изискват изпитан път за възстановяване

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

Два модела за възстановяване, едно решаващо условие

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

Решаващото условие е лесно да се назове и лесно да се пропусне. Ако всеки административен път до машината минава през услугата, която се обновява, нямате никакъв модел за възстановяване, а само очакване. Кажете го на глас при прегледа на промяната.

Проверката на това условие отнема десет минути и трябва да се случи преди първото автоматично обновление, а не по време на инцидента. Отворете конзолата, докато всичко работи, потвърдете, че идентификационните данни са актуални, и я затворете отново. Потвърдете, че конзолата се отваря на хоста, който мислите. След това потвърдете, че входът, който реално бихте използвали в 3 часа през нощта, все още работи.

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

Какво не възстановява резервното копие

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

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

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

Нищо от това не е аргумент срещу резервните копия. То е аргумент да знаете кой слой покрива всеки артефакт, защото режимът на отказ при частично възстановяване е по-объркващ от първоначалното прекъсване. Запишете слоя до всяко резервно копие в runbook.

Контролна точка, обновяване, после проверка отвън

Запишете състоянието преди промяната във форма, която можете да сравните после: инсталираните версии, участващите unit-и на услуги, слушащите сокети и текущия списък с партньори. Четири команди покриват по-голямата част от това на Linux хост.

systemctl list-units --type=service | grep -E 'openvpn|wg-quick'
ss -lunp | grep -E ':51820|:1194'
journalctl -u wg-quick@wg0 --since '-10 min'

Първата показва кои unit-и съществуват и дали работят, втората потвърждава, че слушателят наистина е обвързан, а третата ви дава собствения разказ на услугата за последните няколко минути. Нито една от тях не доказва, че клиент може да се свърже, затова следващата стъпка се случва извън хоста. Запазете тези показания като ваша база за сравнение.

Проверете от мрежа, която не използва тунела: удостоверете един оторизиран клиент, разрешете име и достигнете до едно нужно приложение. Локалният ред за състояние, който казва, че интерфейсът е вдигнат, е твърдение за интерфейса, а не за маршрутизацията, ключовете или политиката, която допуска партньор.

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

Когато се провали, използвайте изпитания път

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

Устоявайте на желанието да направите няколко незаписани промени, за да върнете свързаността. Машина, поправена с пет едновременни редакции, не може да бъде обяснена после, и следващото обновление ще върне тази от тях, която всъщност е носела натоварването.

След това решете постоянната политика с доказателства. Ако обновлението разкри зависимост, която никой не е документирал, поправката е документация и тест, а не изключване на обновленията. Ако разкри услуга, която не може да се рестартира чисто, поправката е в unit-а, а не в графика.

Сравнението се решава чисто, щом условието бъде назовано. Независимият път прави автоматичните обновления управляем риск. Липсата му прави същата политика планирано прекъсване с неизвестно време за възстановяване и никакво количество автоматизация не променя тази аритметика.