Ubemandede VPN-serveropdateringer kræver en genopretningsvej, du har testet

Ubemandede opdateringer er en rimelig politik for en server, du når over dens egen VPN, og de er samtidig et enkelt punkt af selvpåført fejl. Pakkeoperationen genstarter tjenesten, tunnelen falder, og den administrative vej, du brugte, forsvinder med den. Der findes to genopretningsmodeller, og valget mellem dem afhænger af én betingelse: om du har en indgangsvej, der ikke går gennem det, der opdateres.

To genopretningsmodeller, én afgørende betingelse

Den første model stoler på opdateringen og forudsætter, at du kan genoprette forbindelsen bagefter. Den virker, når VPN er en af flere måder at nå værten på, og når tunnelens fejl ikke fjerner din mulighed for at diagnosticere den. Den anden model placerer på forhånd en uafhængig vej, normalt hostingudbyderens konsol, og behandler tunnelen som det, vedligeholdelse mest sandsynligt ødelægger. Begge modeller er forsvarlige, og kun én af dem kræver arbejde på forhånd.

Den afgørende betingelse er let at sige og let at springe over. Hvis enhver administrativ vej til maskinen går gennem den tjeneste, der opdateres, har du slet ingen genopretningsmodel, kun en forventning. Sig det højt i ændringsgennemgangen.

At teste den betingelse tager ti minutter og skal ske før den første ubemandede opdatering, ikke under hændelsen. Åbn konsollen, mens alt virker, bekræft at legitimationsoplysningerne er gyldige, og luk den igen. Bekræft, at konsollen åbner på den vært, du tror. Bekræft derefter, at det login, du faktisk ville bruge klokken 3 om natten, stadig virker.

Den sidste del betyder mere, end den lyder. En konsolkonto, hvis adgangskode blev roteret for seks måneder siden og aldrig verificeret, er ikke en genopretningsvej; det er et dokument, der beskriver en.

Hvad en sikkerhedskopi ikke gendanner

Et konfigurationsarkiv er en registrering af filer, og en opdatering ændrer mere end filer. Pakketilstand, kernemoduler, aktiverede unit-links og firewallregler anvendt gennem et separat værktøj lever alle uden for en konfigurationsmappe, og en gendannelse, der ignorerer dem, giver en maskine, der ser konfigureret ud og ikke videresender.

Autorisation fortjener sin egen linje. En sikkerhedskopi taget før en kompromitteret enhed blev fjernet, gendanner med glæde den enheds adgang. At rulle tilbage til den under en afbrydelse er måden, hvorpå én hændelse bliver to, og beslutningen om at gendanne bør træffes om peers lige så eksplicit, som den træffes om filer.

Selve tilbagerulningen betyder også noget. At kopiere en ældre eksekverbar fil over en pakkestyret er ikke den understøttede tilbageførsel af en pakkeændring, og den efterlader pakkedatabasen med at beskrive en tilstand, filsystemet ikke matcher. Brug pakkehåndteringsprogrammets egen nedgraderingsvej eller det snapshot, udbyderen tilbyder. En nedgradering, som pakkedatabasen registrerer, er en, du kan gentage.

Intet af dette taler imod sikkerhedskopier. Det taler for at vide, hvilket lag hvert artefakt dækker, fordi fejlmåden ved en delvis gendannelse er mere forvirrende end den oprindelige afbrydelse. Skriv laget ved siden af hver sikkerhedskopi i runbooken.

Kontrolpunkt, opdatering og derefter verifikation udefra

Registrér tilstanden før ændringen i en form, du kan sammenligne bagefter: de installerede versioner, de involverede tjeneste-units, de lyttende sockets og den aktuelle peer-liste. Fire kommandoer dækker det meste på en Linux-vært.

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 units der findes, og om de kører, den anden bekræfter, at lytteren faktisk er bundet, og den tredje giver dig tjenestens egen redegørelse for de sidste par minutter. Ingen af dem beviser, at en klient kan forbinde, og derfor sker næste skridt uden for værten. Gem de aflæsninger som din sammenligningsbasislinje.

Verificér fra et netværk, der ikke bruger tunnelen: godkend én autoriseret klient, slå et navn op, og nå én tilsigtet applikation. En lokal statuslinje, der siger, at interfacet er oppe, er en udtalelse om interfacet, ikke om routing, nøgler eller den politik, der optager en peer.

Test derefter genoprettelsesvejen med vilje. Genstart tjenesten én gang og bekræft, at tunnelen kommer tilbage uden manuel indgriben, for en tjeneste, der kun starter korrekt ved boot, er en tjeneste, der overrasker dig på det værst tænkelige tidspunkt.

Når det fejler, brug den vej, du har testet

Genopretningssekvensen er uglamourøs og den virker: nå værten gennem den uafhængige vej, læs tjenestens egne logfiler, og gendan det specifikke kontrolpunkt, der svarer til fejlen. Ændr én ting ad gangen, så den næste loglæsning betyder noget.

Modstå trangen til at foretage flere uregistrerede ændringer for at få forbindelsen tilbage. En maskine, der er rettet med fem samtidige ændringer, kan ikke forklares bagefter, og den næste opdatering vil genindføre den af dem, der faktisk bar byrden.

Beslut derefter den permanente politik med beviser. Hvis opdateringen afslørede en afhængighed, ingen dokumenterede, er rettelsen dokumentation og en test, ikke at slå opdateringer fra. Hvis den afslørede en tjeneste, der ikke kan genstarte rent, er rettelsen i uniten, ikke i tidsplanen.

Sammenligningen falder rent på plads, når betingelsen er navngivet. En uafhængig vej gør ubemandede opdateringer til en håndterbar risiko. Deres fravær gør den samme politik til en planlagt afbrydelse med ukendt genopretningstid, og ingen mængde automatisering ændrer den aritmetik.