Egy kiszolgáló visszaállítása arról szóló döntés, melyik réteg hibázott, nem fájlmásolási gyakorlat. A konfiguráció, a hitelesítő adatok és a csomagverziók külön órákon mozognak, és ha az egyiket visszaállítjuk, míg a többi naprakész marad, olyan gazdagép jön létre, amely egészségesnek látszik, és következetlenül viselkedik. Az alábbi sorrend azt feltételezi, hogy egy változtatás már félresikerült, és a legkisebb koherens állapot visszaállítását kéri. Járja végig sorrendben, és tekintse a sávon kívüli hozzáférés ellenőrzését arra a lépésre, amelyet senkinek sem szabad kihagynia.

Készítsen olyan ellenőrzőpontot, amelyet valóban vissza tud állítani

Rögzítse a konfigurációt, amelyet a szolgáltatás indításkor olvas, együtt azzal a verzióval, amely utoljára feldolgozta. Egy régebbi kiadás alatt tisztán betöltődött fájlt a frissítés után elutasíthatnak vagy csendben figyelmen kívül hagyhatnak, ezért a verzió ugyanabba a feljegyzésbe tartozik. Vegye bele az anyagot, amelyre a konfiguráció hivatkozik: privát kulcsok, tanúsítványútvonalak, hallgatódefiníciók, valamint a DNS- és tűzfalbejegyzések, amelyek elérhetővé teszik a szolgáltatást. Ha a visszaállításhoz olyan fájl kellene, amelyet nem mentett el, az ellenőrzőpont hiányos.

Nevezze meg minden beállítás gazdáját, amíg a rendszer egészséges. A szolgáltatói panel által telepített útvonal, a gazdagép tűzfala által hozzáadott és az ügyfeleknek kiosztott útvonal három külön objektum, és a rossz visszaállítása a másik kettőt a helyén hagyja. Elég egy rövid táblázat a beállításról, a gazdáról és a fájlútvonalról.

Tartsa külön a visszavonásokat a konfigurációtól

Egy régi konfiguráció csendben újra csatlakoztathat egy eszközt, amelyet szándékosan eltávolított, ami a helyreállítást biztonsági visszalépéssé változtatja. Őrizze meg az aktuális visszavonási listát és a letiltott fiókokat, miközben visszaállítja a hálózati szabályzatot, majd alkalmazza őket újra, mielőtt a szolgáltatás ügyfeleket fogad.

Tekintse az identitás állapotát saját visszaállításnak, saját bizonyítékokkal. A tanúsítvány-visszavonási fájlok, a fiók letiltása és az MFA-regisztráció ritkán vannak ugyanazon a helyen, mint a démon konfigurációja, és egy konfiguráció-visszaállítás nem nyúl hozzájuk. Először ellenőrizze az aktuális állapotot, hogy tudja, minek kell túlélnie. A visszaállítás után erősítse meg, hogy az eltávolított identitás továbbra sem tud csatlakozni.

Érje el a gazdagépet, amikor az alagút meghibásodik

Nyisson utat a géphez, amely nem függ a változtatott összetevőtől. Egy hipervizor-konzol, egy külön interfészen lévő felügyeleti cím vagy egy soros konzol mind megfelel; az alagúton keresztül vitt SSH-munkamenet nem. Ha az egyetlen bejárat a VPN, amelyet újraindítani készül, egy rossz útvonal vagy tűzfalszabály megfosztja a javítás lehetőségétől. Tesztelje az alternatív utat a változtatás előtt, ne utána. Jelentkezzen be rajta egyszer, erősítse meg, hogy a sudo működik, és jegyezze fel a használt pontos címet.

A próba egyszerű: engedje le az alagutat, miközben az alternatív úton kapcsolódik, és nézze meg, túléli-e a munkamenet. Ha megszakad, megtalálta a hibát, mielőtt az elszigetelhetné.

Alkalmazzon egy revíziót, és tudja, mikor lép hatályba

Használja a szolgáltatás reload vagy restart dokumentációját, és derítse ki, mely direktívák melyik pillanatban olvasódnak. Egyes értékek reloadkor lépnek életbe, mások csak akkor, amikor új munkamenet vagy folyamat indul, ezért egy fájl szerkesztése semmit sem bizonyít a futó állapotról. Egyetlen revíziót állítson vissza, ahelyett hogy új fájlt keverne a régi futásidejű állapottal. Kétség esetén a szolgáltatás teljes újraindítása könnyebben átgondolható, mint egy részleges reload.

Választás előtt ellenőrizze az unit definícióját: systemctl show -p ExecReload openvpn@server megmondja, létezik-e egyáltalán reload-horog. Ezután alkalmazza a revíziót, és olvassa el a naplóban az első új hibákat, mielőtt bármi mást módosítana.

Ellenőrizze, rögzítse és vizsgálja ki utána

Csatlakoztasson egy jogosult ügyfelet, és próbálja ki, mire való a szolgáltatás: névfeloldásra, újracsatlakozásra és arra az alkalmazásra, amely hibázott. Erősítse meg, hogy a visszavont identitást továbbra is elutasítja. Rögzítse a visszaállított revíziót, az időpontot és az okot, mert a következő üzemeltetőnek mindháromra szüksége lesz. Egy dokumentálatlan visszaállítás rejtéllyé válik, amikor a szolgáltatás legközelebb rosszul viselkedik.

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

Amint a szolgáltatás stabil, reprodukálja a sikertelen változtatást egy eldobható gazdagépen vagy pillanatképen. Ez elválasztja a rossz konfigurációt a rossz csomagtól vagy a lejárt tanúsítványtól. Tartsa a visszaállított konfigurációt verziókezelés alatt, hogy a következő ellenőrzőpont egy ismert commitról induljon. A gyakorlat célja egy dokumentált végpont, nem tartós visszaminősítés.

Kapcsolódó cikkek