Hvordan rulle tilbake en VPN-serverkonfigurasjon på en trygg måte

Å rulle tilbake en server er en beslutning om hvilket lag som sviktet, ikke en øvelse i å kopiere filer. Konfigurasjon, legitimasjon og pakkeversjoner beveger seg på hver sin klokke, og å gjenopprette én mens de andre holdes oppdaterte gir en vert som ser sunn ut og oppfører seg inkonsekvent. Rekkefølgen nedenfor forutsetter at en endring allerede har gått galt, og ber deg gjenopprette den minste sammenhengende tilstanden. Gå gjennom den i rekkefølge, og behandle tilgangskontrollen utenfor båndet som trinnet ingen bør hoppe over.

Lag et kontrollpunkt du faktisk kan gjenopprette

Noter konfigurasjonen tjenesten leser ved oppstart, sammen med versjonen som sist tolket den. En fil som lastet rent under en eldre utgave, kan bli avvist eller stille ignorert etter en oppgradering, så versjonen hører hjemme i samme notat. Ta med materialet konfigurasjonen peker på: private nøkler, sertifikatstier, lyttedefinisjoner og DNS- og brannmurpostene som gjør tjenesten tilgjengelig. Hvis en gjenoppretting ville trenge en fil du ikke lagret, er kontrollpunktet ufullstendig.

Navngi eieren av hver innstilling mens systemet ennå er sunt. En rute som installeres av leverandørpanelet, en som legges til av vertens brannmur og en som skyves ut til klientene, er tre forskjellige objekter, og gjenoppretter man den feil, blir de to andre stående. En kort tabell med innstilling, eier og filsti er nok.

Hold tilbakekallinger atskilt fra konfigurasjonen

En gammel konfigurasjon kan stille koble til en enhet du bevisst har fjernet, noe som gjør en gjenoppretting til en sikkerhetsregresjon. Bevar gjeldende tilbakekallingsliste og de deaktiverte kontoene mens du gjenoppretter nettverkspolicyen, og bruk dem på nytt før tjenesten godtar klienter.

Behandle identitetstilstand som sin egen tilbakerulling med sine egne bevis. Filer for sertifikattilbakekalling, deaktivering av kontoer og MFA-påmelding bor sjelden samme sted som daemonkonfigurasjonen, og en konfigurasjonsgjenoppretting vil ikke røre dem. Kontroller gjeldende tilstand først så du vet hva som må overleve. Etter gjenopprettingen, bekreft at den fjernede identiteten fortsatt ikke kan koble til.

Nå verten når tunnelen svikter

Åpne en vei til maskinen som ikke avhenger av komponenten som endres. En hypervisorkonsoll, en administrasjonsadresse på et eget grensesnitt eller en seriekonsoll kvalifiserer alle; en SSH-økt båret gjennom tunnelen gjør det ikke. Hvis den eneste veien inn er VPN-en du er i ferd med å starte på nytt, fjerner en dårlig rute eller brannmurregel muligheten din til å rette den. Test den alternative veien før endringen, ikke etter. Logg på gjennom den én gang, bekreft at sudo virker, og noter den nøyaktige adressen du brukte.

Testen er enkel: ta tunnelen ned mens du er tilkoblet over den alternative veien, og se om økten overlever. Hvis den faller, har du funnet feilen før den kan strande deg.

Bruk én revisjon og vit når den trer i kraft

Bruk tjenestens dokumentasjon for reload eller restart, og finn ut hvilke direktiver som leses når. Noen verdier gjelder ved reload, andre først når en ny økt eller prosess starter, så å redigere en fil beviser ingenting om tilstanden som kjører. Gjenopprett én revisjon i stedet for å blande en ny fil med gammel kjøretidstilstand. I tvil er en full omstart av tjenesten lettere å resonnere om enn en delvis reload.

Kontroller enhetsdefinisjonen før du velger: systemctl show -p ExecReload openvpn@server forteller deg om det i det hele tatt finnes en reload-krok. Bruk deretter revisjonen og les journalen for de første nye feilene før du endrer noe annet.

Bekreft, noter og undersøk etterpå

Koble til én autorisert klient og prøv det tjenesten er til for: navneoppslag, en gjenoppkobling og applikasjonen som sviktet. Bekreft at den tilbakekalte identiteten fortsatt avvises. Noter revisjonen du gjenopprettet, tidspunktet og årsaken, fordi neste operatør trenger alle tre. En tilbakerulling ingen har dokumentert, blir en gåte neste gang tjenesten oppfører seg dårlig.

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

Når tjenesten er stabil, gjenskap den mislykkede endringen på en vert eller et øyeblikksbilde du kan kaste. Det skiller en dårlig konfigurasjon fra en dårlig pakke eller et utløpt sertifikat. Hold den gjenopprettede konfigurasjonen under versjonskontroll slik at neste kontrollpunkt starter fra en kjent commit. Poenget med øvelsen er et dokumentert endepunkt, ikke en permanent nedgradering.