A felügyelet nélküli VPN-kiszolgáló-frissítések tesztelt helyreállítási útvonalat igényelnek

A felügyelet nélküli frissítések ésszerű szabályzat egy olyan kiszolgálóhoz, amelyet a saját VPN-jén keresztül ér el, és egyben egyetlen, saját maga okozta meghibásodási pont. A csomagművelet újraindítja a szolgáltatást, az alagút leesik, és az Ön által használt adminisztratív útvonal eltűnik vele együtt. Két helyreállítási modell létezik, és a köztük való választás egyetlen feltételtől függ: van-e olyan bejárati útvonala, amely nem a frissített dolgon keresztül vezet.

Két helyreállítási modell, egy döntő feltétel

Az első modell megbízik a frissítésben, és feltételezi, hogy utána újra csatlakozhat. Akkor működik, ha a VPN a gazdagép elérésének több módja közül az egyik, és ha az alagút meghibásodása nem veszi el a diagnosztizálás képességét. A második modell előre elhelyez egy független útvonalat, rendszerint a tárhelyszolgáltató konzolját, és az alagutat olyan dologként kezeli, amelyet a karbantartás a legvalószínűbben elront. Mindkét modell védhető, és csak az egyikük igényel előzetes munkát.

A döntő feltételt könnyű kimondani és könnyű kihagyni. Ha a géphez vezető minden adminisztratív útvonal a frissített szolgáltatáson keresztül halad, egyáltalán nincs helyreállítási modellje, csak egy várakozás. Mondja ezt ki hangosan a változás áttekintésén.

A feltétel tesztelése tíz percet vesz igénybe, és az első felügyelet nélküli frissítés előtt kell megtörténnie, nem az incidens alatt. Nyissa meg a konzolt, amíg minden működik, ellenőrizze, hogy a hitelesítő adatok érvényesek, majd zárja be újra. Ellenőrizze, hogy a konzol a gondolt gazdagépre nyílik-e. Ezután ellenőrizze, hogy a bejelentkezés, amelyet valóban használna hajnali 3-kor, még mindig működik.

Az utolsó rész fontosabb, mint amilyennek hangzik. Egy konzolfiók, amelynek jelszavát hat hónapja cserélték, és soha nem ellenőrizték, nem helyreállítási útvonal; ez egy dokumentum, amely leír egyet.

Mit nem állít vissza egy biztonsági mentés

A konfigurációs archívum fájlok nyilvántartása, és a frissítés többet változtat, mint fájlokat. A csomagállapot, a kernelmodulok, az engedélyezett unit-hivatkozások és a külön eszközzel alkalmazott tűzfalszabályok mind a konfigurációs könyvtáron kívül élnek, és az ezeket figyelmen kívül hagyó visszaállítás olyan gépet eredményez, amely konfiguráltnak látszik, és nem továbbít.

Az engedélyezés saját sort érdemel. Egy kompromittált eszköz eltávolítása előtt készült biztonsági mentés szívesen visszaállítja annak az eszköznek a hozzáférését. Egy kimaradás alatt visszatérni hozzá az az út, ahogy egy incidensből kettő lesz, és a visszaállításról szóló döntést a társakról ugyanolyan kifejezetten kell meghozni, mint a fájlokról.

A visszagörgetés mechanizmusa is számít. Egy régebbi futtatható fájl rámásolása egy csomag által kezelt fájlra nem a csomagváltozás támogatott visszafordítása, és a csomagadatbázist olyan állapot leírására hagyja, amelynek a fájlrendszer nem felel meg. Használja a csomagkezelő saját lefokozási útvonalát vagy a szolgáltató által kínált pillanatképet. Az a lefokozás, amelyet a csomagadatbázis rögzít, az, amelyet meg tud ismételni.

Mindezt nem a biztonsági mentések ellen mondjuk. Amellett szól, hogy tudja, melyik réteget fedi az egyes artefaktum, mert a részleges visszaállítás meghibásodási módja zavaróbb az eredeti kimaradásnál. Írja a réteget minden mentés mellé a runbookba.

Ellenőrzőpont, frissítés, majd ellenőrzés kívülről

Rögzítse a változás előtti állapotot olyan formában, amelyet később össze tud hasonlítani: a telepített verziókat, az érintett szolgáltatásegységeket, a figyelő socketeket és az aktuális társlistát. Négy parancs lefedi ennek nagy részét egy Linux-gazdagépen.

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

Az első megmutatja, mely egységek léteznek és futnak-e, a második megerősíti, hogy a figyelő valóban kötve van, a harmadik pedig a szolgáltatás saját beszámolóját adja az elmúlt percekről. Egyik sem bizonyítja, hogy egy ügyfél csatlakozni tud, ezért a következő lépés a gazdagépen kívül történik. Őrizze meg ezeket az értékeket összehasonlítási alapként.

Ellenőrizze egy olyan hálózatból, amely nem használja az alagutat: hitelesítsen egy engedélyezett ügyfelet, oldjon fel egy nevet, és érjen el egy tervezett alkalmazást. Egy helyi állapotsor, amely szerint a felület fel van, a felületről szóló állítás, nem az útvonalválasztásról, a kulcsokról vagy a társat beengedő szabályzatról.

Ezután szándékosan tesztelje az újracsatlakozás útvonalát. Indítsa újra a szolgáltatást egyszer, és ellenőrizze, hogy az alagút kézi beavatkozás nélkül visszatér, mert egy szolgáltatás, amely csak rendszerindításkor indul el helyesen, olyan szolgáltatás, amely a legrosszabb pillanatban lepi meg.

Ha meghiúsul, használja a tesztelt útvonalat

A helyreállítási sorrend nem látványos, és működik: érje el a gazdagépet a független útvonalon, olvassa el a szolgáltatás saját naplóit, és állítsa vissza azt a konkrét ellenőrzőpontot, amely megfelel a hibának. Kísérletenként egy dolgot változtasson, hogy a következő naplóolvasás jelentsen valamit.

Ellenálljon a késztetésnek, hogy több nem rögzített változtatással hozza vissza a kapcsolatot. Egy öt egyidejű szerkesztéssel megjavított gépet utólag nem lehet megmagyarázni, és a következő frissítés visszahozza azt, amely valóban tartotta a terhelést.

Ezután döntse el a végleges szabályzatot bizonyítékokkal. Ha a frissítés olyan függőséget tárt fel, amelyet senki nem dokumentált, a javítás a dokumentáció és egy teszt, nem a frissítések kikapcsolása. Ha olyan szolgáltatást tárt fel, amely nem tud tisztán újraindulni, a javítás az egységben van, nem az ütemezésben.

Az összehasonlítás tisztán feloldódik, amint a feltétel nevet kap. Egy független útvonal kezelhető kockázattá teszi a felügyelet nélküli frissítéseket. Ennek hiánya ugyanazt a szabályzatot ismeretlen helyreállítási idejű tervezett kimaradássá teszi, és semmilyen mennyiségű automatizálás nem változtat ezen a számításon.