Ubetjente VPN-serveroppdateringer krever en gjenopprettingsvei du har testet

Ubetjente oppdateringer er en rimelig policy for en server du når over dens egen VPN, og de er samtidig et enkelt punkt for selvpåført feil. Pakkeoperasjonen starter tjenesten på nytt, tunnelen faller, og den administrative veien du brukte forsvinner med den. Det finnes to gjenopprettingsmodeller, og valget mellom dem avhenger av én betingelse: om du har en inngangsvei som ikke går gjennom det som oppdateres.

To gjenopprettingsmodeller, én avgjørende betingelse

Den første modellen stoler på oppdateringen og forutsetter at du kan koble til igjen etterpå. Den virker når VPN er én av flere måter å nå verten på, og når svikten i tunnelen ikke fjerner muligheten din til å diagnostisere den. Den andre modellen plasserer på forhånd en uavhengig vei, vanligvis konsollen til hostingleverandøren, og behandler tunnelen som det vedlikehold mest sannsynlig ødelegger. Begge modellene er forsvarlige, og bare én av dem krever arbeid på forhånd.

Den avgjørende betingelsen er lett å si og lett å hoppe over. Hvis hver administrativ vei til maskinen går gjennom tjenesten som oppdateres, har du ingen gjenopprettingsmodell i det hele tatt, bare en forventning. Si det høyt i endringsgjennomgangen.

Å teste den betingelsen tar ti minutter og må skje før den første ubetjente oppdateringen, ikke under hendelsen. Åpne konsollen mens alt virker, bekreft at påloggingsinformasjonen er gyldig, og lukk den igjen. Bekreft at konsollen åpner på verten du tror. Bekreft deretter at påloggingen du faktisk ville brukt klokken 3 om natten fortsatt virker.

Den siste delen betyr mer enn den høres ut som. En konsollkonto der passordet ble rotert for seks måneder siden og aldri verifisert, er ikke en gjenopprettingsvei; det er et dokument som beskriver en.

Hva en sikkerhetskopi ikke gjenoppretter

Et konfigurasjonsarkiv er en registrering av filer, og en oppdatering endrer mer enn filer. Pakketilstand, kjernemoduler, aktiverte enhetslenker og brannmurregler brukt via et eget verktøy lever alle utenfor en konfigurasjonskatalog, og en gjenoppretting som ignorerer dem gir en maskin som ser konfigurert ut og ikke videresender.

Autorisasjon fortjener sin egen linje. En sikkerhetskopi tatt før en kompromittert enhet ble fjernet, vil gjerne gjenopprette den enhetens tilgang. Å rulle tilbake til den under en avbrudd er måten én hendelse blir to, og beslutningen om å gjenopprette bør tas om peers like eksplisitt som den tas om filer.

Selve tilbakerullingen betyr også noe. Å kopiere en eldre kjørbar fil over en pakkestyrt er ikke den støttede tilbakeføringen av en pakkeendring, og den lar pakkedatabasen beskrive en tilstand filsystemet ikke samsvarer med. Bruk pakkebehandlerens egen nedgraderingsvei eller øyeblikksbildet leverandøren tilbyr. En nedgradering som pakkedatabasen registrerer, er en du kan gjenta.

Ingenting av dette taler mot sikkerhetskopier. Det taler for å vite hvilket lag hvert artefakt dekker, fordi feilmodusen ved en delvis gjenoppretting er mer forvirrende enn den opprinnelige avbruddet. Skriv laget ved siden av hver sikkerhetskopi i runbooken.

Kontrollpunkt, oppdatering og deretter verifisering utenfra

Registrer tilstanden før endringen i en form du kan sammenligne senere: de installerte versjonene, tjenesteenhetene som er involvert, de lyttende socketene og den gjeldende peer-listen. Fire kommandoer dekker det meste av dette på en Linux-vert.

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

Den første viser hvilke enheter som finnes og om de kjører, den andre bekrefter at lytteren faktisk er bundet, og den tredje gir deg tjenestens egen redegjørelse for de siste minuttene. Ingen av dem beviser at en klient kan koble til, og derfor skjer neste steg utenfor verten. Ta vare på avlesningene som sammenligningsgrunnlaget ditt.

Verifiser fra et nettverk som ikke bruker tunnelen: autentiser én autorisert klient, slå opp et navn og nå én tiltenkt applikasjon. En lokal statuslinje som sier at grensesnittet er oppe, er en påstand om grensesnittet, ikke om ruting, nøkler eller policyen som slipper en peer inn.

Test deretter gjentilkoblingsveien med vilje. Start tjenesten på nytt én gang og bekreft at tunnelen kommer tilbake uten manuell inngripen, for en tjeneste som bare starter riktig ved oppstart, er en tjeneste som vil overraske deg på det verste øyeblikket.

Når det feiler, bruk veien du har testet

Gjenopprettingssekvensen er lite glamorøs og den virker: nå verten gjennom den uavhengige veien, les tjenestens egne logger, og gjenopprett det konkrete kontrollpunktet som svarer til feilen. Endre én ting per forsøk, slik at neste logglesing betyr noe.

Motstå trangen til å gjøre flere uregistrerte endringer for å få tilbake tilkoblingen. En maskin som er reparert med fem samtidige endringer, kan ikke forklares i ettertid, og neste oppdatering vil gjeninnføre den av dem som faktisk bar lasten.

Bestem deretter den permanente policyen med bevis. Hvis oppdateringen avdekket en avhengighet ingen dokumenterte, er rettelsen dokumentasjon og en test, ikke å slå av oppdateringer. Hvis den avdekket en tjeneste som ikke kan startes rent på nytt, er rettelsen i enheten, ikke i planen.

Sammenligningen faller rent på plass når betingelsen er navngitt. En uavhengig vei gjør ubetjente oppdateringer til en håndterbar risiko. Fraværet av den gjør samme policy til en planlagt avbrudd med ukjent gjenopprettingstid, og ingen mengde automatisering endrer den aritmetikken.