Nienadzorowane aktualizacje serwera VPN wymagają przetestowanej ścieżki odzyskiwania

Nienadzorowane aktualizacje to rozsądna polityka dla serwera, do którego docierasz przez jego własny VPN, a jednocześnie jeden punkt samoistnej awarii. Operacja pakietu restartuje usługę, tunel pada, a ścieżka administracyjna, której używałeś, znika razem z nim. Istnieją dwa modele odzyskiwania, a wybór między nimi zależy od jednego warunku: czy masz ścieżkę dostępu, która nie przechodzi przez to, co jest aktualizowane.

Dwa modele odzyskiwania, jeden decydujący warunek

Pierwszy model ufa aktualizacji i zakłada, że potem połączysz się ponownie. Działa, gdy VPN jest jednym z kilku sposobów dotarcia do hosta i gdy awaria tunelu nie odbiera ci możliwości zdiagnozowania go. Drugi model z góry umieszcza niezależną ścieżkę, zwykle konsolę dostawcy hostingu, i traktuje tunel jako to, co konserwacja najprawdopodobniej zepsuje. Oba modele są do obrony, a tylko jeden z nich wymaga pracy z wyprzedzeniem.

Decydujący warunek łatwo wypowiedzieć i łatwo pominąć. Jeśli każda ścieżka administracyjna do maszyny przechodzi przez aktualizowaną usługę, nie masz żadnego modelu odzyskiwania, tylko oczekiwanie. Powiedz to głośno na przeglądzie zmiany.

Sprawdzenie tego warunku zajmuje dziesięć minut i musi nastąpić przed pierwszą nienadzorowaną aktualizacją, a nie w trakcie incydentu. Otwórz konsolę, gdy wszystko działa, potwierdź, że dane logowania są aktualne, i zamknij ją ponownie. Potwierdź, że konsola otwiera się na hoście, którego się spodziewasz. Następnie potwierdź, że logowanie, którego naprawdę użyłbyś o 3 w nocy, nadal działa.

Ta ostatnia część ma większe znaczenie, niż brzmi. Konto konsoli, którego hasło zmieniono sześć miesięcy temu i nigdy nie zweryfikowano, nie jest ścieżką odzyskiwania; to dokument, który taką ścieżkę opisuje.

Czego kopia zapasowa nie przywraca

Archiwum konfiguracji to zapis plików, a aktualizacja zmienia więcej niż pliki. Stan pakietów, moduły jądra, włączone dowiązania jednostek i reguły zapory stosowane osobnym narzędziem żyją poza katalogiem konfiguracji, a przywrócenie, które je pomija, daje maszynę, która wygląda na skonfigurowaną i nie przekazuje ruchu.

Autoryzacja zasługuje na osobną linię. Kopia wykonana przed usunięciem przejętego urządzenia chętnie przywróci dostęp tego urządzenia. Powrót do niej w trakcie awarii to sposób, w jaki jeden incydent staje się dwoma, a decyzję o przywróceniu należy podjąć w sprawie peerów tak samo wyraźnie, jak w sprawie plików.

Sam mechanizm wycofania też ma znaczenie. Skopiowanie starszego pliku wykonywalnego na zarządzany przez pakiet nie jest obsługiwanym cofnięciem zmiany pakietu i pozostawia bazę pakietów opisującą stan, z którym system plików się nie zgadza. Użyj własnej ścieżki obniżenia wersji menedżera pakietów albo migawki oferowanej przez dostawcę. Obniżenie wersji, które zapisuje baza pakietów, jest tym, które możesz powtórzyć.

Nic z tego nie przemawia przeciw kopiom zapasowym. Przemawia za tym, by wiedzieć, którą warstwę pokrywa każdy artefakt, bo sposób zawodu częściowego przywrócenia jest bardziej mylący niż pierwotna awaria. Zapisz warstwę obok każdej kopii w runbooku.

Punkt kontrolny, aktualizacja, potem weryfikacja z zewnątrz

Zapisz stan przed zmianą w formie, którą później porównasz: zainstalowane wersje, zaangażowane jednostki usług, nasłuchujące gniazda i bieżącą listę peerów. Cztery polecenia pokrywają większość tego na hoście z Linuksem.

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

Pierwsze pokazuje, które jednostki istnieją i czy działają, drugie potwierdza, że nasłuch jest rzeczywiście związany, a trzecie daje ci własną relację usługi z ostatnich minut. Żadne z nich nie dowodzi, że klient może się połączyć, dlatego następny krok odbywa się poza hostem. Zachowaj te odczyty jako podstawę porównania.

Zweryfikuj z sieci, która nie korzysta z tunelu: uwierzytelnij jednego uprawnionego klienta, rozwiąż nazwę i dotrzyj do jednej zamierzonej aplikacji. Lokalna linia statusu mówiąca, że interfejs jest podniesiony, jest stwierdzeniem o interfejsie, a nie o trasowaniu, kluczach czy polityce dopuszczającej peera.

Potem świadomie przetestuj ścieżkę ponownego połączenia. Zrestartuj usługę raz i potwierdź, że tunel wraca bez ręcznej interwencji, bo usługa, która startuje poprawnie tylko przy rozruchu, to usługa, która zaskoczy cię w najgorszym momencie.

Gdy to zawiedzie, użyj ścieżki, którą przetestowałeś

Sekwencja odzyskiwania nie jest efektowna i działa: dotrzyj do hosta niezależną ścieżką, przeczytaj własne logi usługi i przywróć konkretny punkt kontrolny odpowiadający awarii. Zmieniaj jedną rzecz na próbę, żeby następne czytanie logów coś znaczyło.

Oprzyj się pokusie wprowadzenia kilku niezapisanych zmian, by odzyskać łączność. Maszyny naprawionej pięcioma równoczesnymi edycjami nie da się potem wyjaśnić, a następna aktualizacja ponownie wprowadzi tę, która naprawdę dźwigała obciążenie.

Potem zdecyduj o stałej polityce na podstawie dowodów. Jeśli aktualizacja ujawniła zależność, której nikt nie udokumentował, poprawką jest dokumentacja i test, a nie wyłączanie aktualizacji. Jeśli ujawniła usługę, której nie da się czysto zrestartować, poprawka jest w jednostce, a nie w harmonogramie.

Porównanie rozwiązuje się czysto, gdy tylko warunek zostanie nazwany. Niezależna ścieżka czyni nienadzorowane aktualizacje ryzykiem, którym można zarządzać. Jej brak czyni tę samą politykę zaplanowaną awarią o nieznanym czasie odzyskiwania, a żadna ilość automatyzacji nie zmienia tej arytmetyki.