Sådan rulles en VPN-serverkonfiguration sikkert tilbage

At rulle en server tilbage er en beslutning om, hvilket lag der svigtede, ikke en øvelse i at kopiere filer. Konfiguration, legitimationsoplysninger og pakkeversioner bevæger sig på hver sit ur, og hvis man gendanner én, mens de andre forbliver aktuelle, får man en vært, der ser sund ud og opfører sig inkonsekvent. Sekvensen nedenfor forudsætter, at en ændring allerede er gået galt, og beder dig gendanne den mindste sammenhængende tilstand. Gå igennem den i rækkefølge, og behandl adgangskontrollen uden for båndet som det trin, ingen bør springe over.

Lav et kontrolpunkt, du faktisk kan gendanne

Notér den konfiguration, som tjenesten læser ved opstart, sammen med den version, der sidst fortolkede den. En fil, der blev indlæst rent under en ældre udgivelse, kan blive afvist eller stiltiende ignoreret efter en opgradering, så versionen hører til i samme note. Tag det materiale med, som konfigurationen peger på: private nøgler, certifikatstier, lytterdefinitioner og de DNS- og firewallposter, der gør tjenesten tilgængelig. Hvis en gendannelse ville kræve en fil, du ikke gemte, er kontrolpunktet ufuldstændigt.

Navngiv ejeren af hver indstilling, mens systemet stadig er sundt. En rute, der installeres af udbyderpanelet, en der tilføjes af værtens firewall og en der skubbes til klienter, er tre forskellige objekter, og gendanner man den forkerte, bliver de to andre på plads. En kort tabel med indstilling, ejer og filsti er nok.

Hold tilbagekaldelser adskilt fra konfigurationen

En gammel konfiguration kan stille genoprette forbindelsen til en enhed, du bevidst har fjernet, hvilket gør en gendannelse til en sikkerhedsregression. Bevar den aktuelle tilbagekaldelsesliste og de deaktiverede konti, mens du gendanner netværkspolitikken, og anvend dem derefter igen, før tjenesten accepterer klienter.

Behandl identitetstilstand som sin egen tilbagerulning med sine egne beviser. Filer til certifikattilbagekaldelse, deaktivering af konti og MFA-tilmelding bor sjældent samme sted som dæmonkonfigurationen, og en konfigurationsgendannelse rører dem ikke. Kontroller den aktuelle tilstand først, så du ved, hvad der skal overleve. Bekræft efter gendannelsen, at den fjernede identitet stadig ikke kan oprette forbindelse.

Nå værten, når tunnelen svigter

Åbn en vej til maskinen, der ikke afhænger af den komponent, der ændres. En hypervisorkonsol, en administrationsadresse på en separat grænseflade eller en seriel konsol kvalificerer alle; en SSH-session båret gennem tunnelen gør ikke. Hvis den eneste vej ind er den VPN, du er ved at genstarte, fjerner en dårlig rute eller firewallregel din mulighed for at rette den. Test den alternative vej før ændringen, ikke efter. Log ind gennem den én gang, bekræft at sudo virker, og notér den præcise adresse, du brugte.

Testen er enkel: tag tunnelen ned, mens du er forbundet over den alternative vej, og se, om sessionen overlever. Hvis den falder, har du fundet fejlen, før den kan strande dig.

Anvend én revision og vid, hvornår den træder i kraft

Brug tjenestens dokumentation for reload eller restart, og find ud af, hvilke direktiver der læses hvornår. Nogle værdier gælder ved reload, andre først når en ny session eller proces starter, så redigering af en fil beviser intet om den kørende tilstand. Gendan én revision i stedet for at blande en ny fil med gammel runtime-tilstand. I tvivlstilfælde er en fuld genstart af tjenesten lettere at tænke igennem end en delvis reload.

Kontroller unit-definitionen, før du vælger: systemctl show -p ExecReload openvpn@server fortæller dig, om der overhovedet findes en reload-krog. Anvend derefter revisionen, og læs journalen for de første nye fejl, før du ændrer noget andet.

Bekræft, notér og undersøg bagefter

Forbind én autoriseret klient, og afprøv, hvad tjenesten er til: navneopløsning, en genopkobling og det program, der svigtede. Bekræft, at den tilbagekaldte identitet stadig afvises. Notér den revision, du gendannede, tidspunktet og årsagen, for den næste operatør får brug for alle tre. En tilbagerulning, som ingen har dokumenteret, bliver en gåde næste gang, tjenesten opfører sig dårligt.

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

Når tjenesten er stabil, gengiv den mislykkede ændring på en vært eller et snapshot, du kan smide væk. Det adskiller en dårlig konfiguration fra en dårlig pakke eller et udløbet certifikat. Hold den gendannede konfiguration under versionskontrol, så det næste kontrolpunkt starter fra et kendt commit. Pointen med øvelsen er et dokumenteret endepunkt, ikke en permanent nedgradering.