Korleis rulle tilbake ein VPN-serverkonfigurasjon på ein trygg måte

Å rulle tilbake ein server er eit avgjerdsle om kva lag som svikta, ikkje ei øving i å kopiere filer. Konfigurasjon, legitimasjon og pakkeversjonar flyttar seg på kvar si klokke, og å gjenopprette éin medan dei andre blir haldne oppdaterte gir ein vert som ser sunn ut og oppfører seg inkonsekvent. Rekkjefølgja nedanfor føreset at ei endring alt har gått gale, og ber deg gjenopprette den minste samanhengande tilstanden. Gå gjennom henne i rekkjefølgje, og handsame tilgangskontrollen utanfor bandet som trinnet ingen bør hoppe over.

Lag eit kontrollpunkt du faktisk kan gjenopprette

Noter konfigurasjonen tenesta les ved oppstart, saman med versjonen som sist tolka han. Ei fil som lasta reint under ein eldre versjon, kan bli avvist eller stille ignorert etter ei oppgradering, så versjonen høyrer heime i same notatet. Ta med materialet konfigurasjonen peikar på: private nøklar, sertifikatstigar, lyttedefinisjonar og DNS- og brannmurpostane som gjer tenesta tilgjengeleg. Viss ei gjenoppretting ville trengje ei fil du ikkje lagra, er kontrollpunktet ufullstendig.

Namngje eigaren av kvar innstilling medan systemet enno er sunt. Ei rute som installerast av leverandørpanelet, ei som blir lagd til av brannmuren til verten og ei som blir skyvd ut til klientane, er tre ulike objekt, og gjenopprettar ein den feile, blir dei to andre ståande. Ein kort tabell med innstilling, eigar og filsti er nok.

Hald tilbakekallingar skilde frå konfigurasjonen

Ein gammal konfigurasjon kan stille kople til ei eining du med vilje har fjerna, noko som gjer ei gjenoppretting til ein tryggleiksregresjon. Bevar gjeldande tilbakekallingsliste og dei deaktiverte kontoane medan du gjenopprettar nettverkspolicyen, og bruk dei på nytt før tenesta godtek klientar.

Handsame identitetstilstand som si eiga tilbakerulling med sine eigne bevis. Filer for sertifikattilbakekalling, deaktivering av kontoar og MFA-påmelding bur sjeldan på same stad som daemonkonfigurasjonen, og ei konfigurasjonsgjenoppretting vil ikkje røre dei. Kontroller gjeldande tilstand først så du veit kva som må overleve. Etter gjenopprettinga, stadfest at den fjerna identiteten framleis ikkje kan kople til.

Nå verten når tunnelen sviktar

Opne ein veg til maskina som ikkje er avhengig av komponenten som blir endra. Ein hypervisorkonsoll, ein administrasjonsadresse på eit eige grensesnitt eller ein seriekonsoll kvalifiserer alle; ei SSH-økt boren gjennom tunnelen gjer det ikkje. Viss den einaste vegen inn er VPN-en du er i ferd med å starte på nytt, fjernar ei dårleg rute eller brannmurregel moglegheita di til å rette han. Test den alternative vegen før endringa, ikkje etter. Logg på gjennom han éin gong, stadfest at sudo verkar, og noter den nøyaktige adressa du brukte.

Testen er enkel: ta tunnelen ned medan du er tilkopla over den alternative vegen, og sjå om økta overlever. Viss ho fell, har du funne feilen før han kan strande deg.

Bruk éin revisjon og vit når han trer i kraft

Bruk dokumentasjonen til tenesta for reload eller restart, og finn ut kva direktiv som blir lesne når. Nokre verdiar gjeld ved reload, andre først når ei ny økt eller prosess startar, så å redigere ei fil beviser ingenting om tilstanden som køyrer. Gjenopprett éin revisjon i staden for å blande ei ny fil med gammal køyretidstilstand. I tvil er ein full omstart av tenesta lettare å resonnere om enn ein delvis reload.

Kontroller einingsdefinisjonen før du vel: systemctl show -p ExecReload openvpn@server fortel deg om det i det heile finst ein reload-krok. Bruk deretter revisjonen og les journalen for dei første nye feila før du endrar noko anna.

Stadfest, noter og undersøk etterpå

Kople til éin autorisert klient og prøv det tenesta er til for: namneoppslag, ei gjenoppkopling og applikasjonen som svikta. Stadfest at den tilbakekalla identiteten framleis blir avvist. Noter revisjonen du gjenoppretta, tidspunktet og årsaka, fordi neste operatør treng alle tre. Ei tilbakerulling ingen har dokumentert, blir ei gåte neste gong tenesta oppfører seg dårleg.

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

Når tenesta er stabil, gjenskap den mislukka endringa på ein vert eller eit augneblinksbilete du kan kaste. Det skil ein dårleg konfigurasjon frå ein dårleg pakke eller eit utløpt sertifikat. Hald den gjenoppretta konfigurasjonen under versjonskontroll slik at neste kontrollpunkt startar frå ein kjend commit. Poenget med øvinga er eit dokumentert endepunkt, ikkje ein permanent nedgradering.