Si të kthehet me siguri konfigurimi i një serveri VPN
Një kthim pas rikthen një politikë rrjeti të njohur si e mirë, jo skedarin më të vjetër që gjeni. Mbani shfuqizimet aktuale dhe një rrugë administrimi jashtë tunelit.
Kthimi i një serveri pas është një vendim për atë se cila shtresë dështoi, jo një ushtrim kopjimi skedarësh. Konfigurimi, kredencialet dhe versionet e paketave lëvizin me ora të ndryshme, dhe rikthimi i njërës ndërsa të tjerat mbeten aktuale prodhon një host që duket i shëndetshëm dhe sillet në mënyrë jokonsistente. Sekuenca më poshtë supozon se një ndryshim ka shkuar tashmë keq dhe ju kërkon të riktheni gjendjen më të vogël koherente. Kalojeni me radhë dhe trajtojeni kontrollin e aksesit jashtë brezit si hapin që askush nuk duhet ta anashkalojë.
Bëni një pikë kontrolli që vërtet mund ta riktheni
Regjistroni konfigurimin që shërbimi lexon në nisje, së bashku me versionin që e analizoi për herë të fundit. Një skedar që ngarkohej pastër në një version më të vjetër mund të refuzohet ose të injorohet në heshtje pas një përditësimi, prandaj versioni i takon të njëjtës shënim. Përfshini materialin të cilin konfigurimi e tregon: çelësat privatë, shtigjet e certifikatave, përcaktimet e dëgjuesve dhe zërat e DNS dhe të murit të zjarrit që e bëjnë shërbimin të arritshëm. Nëse një rikthim do të kërkonte një skedar që nuk e ruajtët, pika e kontrollit është e paplotë.
Emërtoni pronarin e çdo cilësimi ndërsa sistemi është ende i shëndetshëm. Një rrugë e instaluar nga paneli i ofruesit, një e shtuar nga muri i zjarrit i hostit dhe një e shtyrë drejt klientëve janë tre objekte të ndryshme, dhe rikthimi i të gabuarës i lë dy të tjerat në vend. Një tabelë e shkurtër me cilësim, pronar dhe shteg skedari mjafton.
Mbani shfuqizimet të ndara nga konfigurimi
Një konfigurim i vjetër mund të rilidhë në heshtje një pajisje që e hoqët me qëllim, gjë që e kthen një rikuperim në një regres sigurie. Ruani listën aktuale të shfuqizimeve dhe llogaritë e çaktivizuara ndërsa riktheni politikën e rrjetit, pastaj rizbatojini ato para se shërbimi të pranojë klientë.
Trajtojeni gjendjen e identitetit si një kthim pas më vete me provat e veta. Skedarët e shfuqizimit të certifikatave, çaktivizimi i llogarive dhe regjistrimi në MFA rrallë jetojnë në të njëjtin vend si konfigurimi i demonit, dhe një rikthim konfigurimi nuk do t'i prekë ato. Kontrolloni fillimisht gjendjen aktuale që të dini çfarë duhet të mbijetojë. Pas rikthimit, konfirmoni se identiteti i hequr ende nuk arrin të lidhet.
Arritni hostin kur tuneli dështon
Hapni një rrugë drejt makinës që nuk varet nga komponenti që po ndryshohet. Një konsolë hipervizori, një adresë administrimi në një ndërfaqe të veçantë ose një konsolë serike kualifikohen të gjitha; një sesion SSH i transportuar përmes tunelit jo. Nëse e vetmja rrugë hyrëse është VPN-ja që po nisni për ta rindezur, një rrugë ose rregull i gabuar i murit të zjarrit ju heq aftësinë për ta korrigjuar. Testoni rrugën alternative para ndryshimit, jo pas tij. Hyni një herë përmes saj, konfirmoni që sudo funksionon dhe shënoni adresën e saktë që përdorët.
Testi është i thjeshtë: ulni tunelin ndërsa jeni i lidhur përmes rrugës alternative dhe shihni nëse sesioni mbijeton. Nëse bie, e keni gjetur defektin para se të mund t'ju bllokojë.
Zbatoni një rishikim të vetëm dhe dijeni kur hyn në fuqi
Përdorni dokumentacionin e shërbimit për reload ose restart dhe zbuloni cilat direktiva lexohen në cilin moment. Disa vlera zbatohen në reload, të tjerat vetëm kur nis një sesion ose proces i ri, prandaj redaktimi i një skedari nuk provon asgjë për gjendjen që po punon. Riktheni një rishikim të vetëm në vend që të përzieni një skedar të ri me gjendje të vjetër ekzekutimi. Në dyshim, një rindezje e plotë e shërbimit është më e lehtë për t'u arsyetuar sesa një reload i pjesshëm.
Kontrolloni përcaktimin e njësisë para se të zgjidhni: systemctl show -p ExecReload openvpn@server ju tregon nëse ekziston fare një grep reload. Pastaj zbatoni rishikimin dhe lexoni në ditar gabimet e para të reja para se të ndryshoni çdo gjë tjetër.
Verifikoni, regjistroni dhe hetoni më pas
Lidhni një klient të autorizuar dhe ushtrohuni për çfarë është shërbimi: zgjidhje emrash, një rilidhje dhe aplikacioni që dështoi. Konfirmoni se identiteti i shfuqizuar ende refuzohet. Regjistroni rishikimin që rikthyet, orën dhe arsyen, sepse operatori tjetër do t'i ketë të treja. Një kthim pas që askush nuk e dokumentoi bëhet mister herën tjetër kur shërbimi sillet keq.
systemctl status openvpn@server --no-pager
journalctl -u openvpn@server -n 50 --no-pager
Pasi shërbimi të jetë i qëndrueshëm, riprodhoni ndryshimin e dështuar në një host ose snop që mund ta hidhni. Kjo ndan një konfigurim të keq nga një paketë e keqe ose certifikatë e skaduar. Mbani konfigurimin e rikthyer nën kontroll versionesh që pika e ardhshme e kontrollit të nisë nga një commit i njohur. Qëllimi i ushtrimit është një pikë përfundimtare e dokumentuar, jo një downgrade i përhershëm.