Onbeheerde VPN-serverupdates hebben een getest herstelpad nodig

Onbeheerde updates zijn een redelijk beleid voor een server die je via zijn eigen VPN bereikt, en tegelijk zijn ze één enkel punt van zelfveroorzaakt falen. De pakketbewerking herstart de dienst, de tunnel valt weg en het beheerpad dat je gebruikte verdwijnt ermee. Er bestaan twee herstelmodellen, en de keuze daartussen hangt af van één voorwaarde: of je een toegangsweg hebt die niet door het bijgewerkte onderdeel loopt.

Twee herstelmodellen, één beslissende voorwaarde

Het eerste model vertrouwt de update en gaat ervan uit dat je daarna opnieuw kunt verbinden. Het werkt wanneer de VPN een van meerdere manieren is om de host te bereiken en wanneer het falen van de tunnel je vermogen om die te diagnosticeren niet wegneemt. Het tweede model plaatst vooraf een onafhankelijke route, meestal de console van de hostingprovider, en behandelt de tunnel als het ding dat onderhoud het waarschijnlijkst breekt. Beide modellen zijn verdedigbaar, en slechts één ervan vereist vooraf werk.

De beslissende voorwaarde is makkelijk te benoemen en makkelijk over te slaan. Als elk beheerpad naar de machine via de bijgewerkte dienst loopt, heb je helemaal geen herstelmodel, alleen een verwachting. Zeg dat hardop in de wijzigingsreview.

Die voorwaarde testen kost tien minuten en moet gebeuren vóór de eerste onbeheerde update, niet tijdens het incident. Open de console terwijl alles werkt, bevestig dat de inloggegevens geldig zijn en sluit hem weer. Bevestig dat de console opent op de host die je denkt. Bevestig daarna dat de login die je om 3 uur ’s nachts echt zou gebruiken nog werkt.

Dat laatste deel is belangrijker dan het klinkt. Een consoleaccount waarvan het wachtwoord zes maanden geleden is geroteerd en nooit is geverifieerd, is geen herstelpad; het is een document dat er een beschrijft.

Wat een back-up niet herstelt

Een configuratiearchief is een registratie van bestanden, en een update verandert meer dan bestanden. Pakketstatus, kernelmodules, ingeschakelde unit-links en firewallregels die via een apart hulpmiddel zijn toegepast, leven allemaal buiten een configuratiemap, en een herstel dat ze negeert levert een machine op die geconfigureerd lijkt en niet doorstuurt.

Autorisatie verdient een eigen regel. Een back-up van voordat een gecompromitteerd apparaat werd verwijderd, herstelt met plezier de toegang van dat apparaat. Terugrollen daarheen tijdens een storing is hoe één incident er twee wordt, en de beslissing om te herstellen moet over peers net zo expliciet worden genomen als over bestanden.

Het mechanisme van de terugrol telt ook. Een ouder uitvoerbaar bestand over een door het pakket beheerd bestand kopiëren is niet de ondersteunde terugdraaiing van een pakketwijziging, en het laat de pakketdatabase een toestand beschrijven die het bestandssysteem niet volgt. Gebruik het eigen downgradepad van de pakketbeheerder of de momentopname die de provider biedt. Een downgrade die de pakketdatabase vastlegt, is er een die je kunt herhalen.

Niets hiervan pleit tegen back-ups. Het pleit voor weten welke laag elk artefact dekt, omdat de faalwijze van een gedeeltelijk herstel verwarrender is dan de oorspronkelijke storing. Schrijf de laag naast elke back-up in het runbook.

Controlepunt, update en dan verificatie van buitenaf

Leg de toestand vóór de wijziging vast in een vorm die je later kunt vergelijken: de geïnstalleerde versies, de betrokken service-units, de luisterende sockets en de huidige peerlijst. Vier opdrachten dekken het meeste daarvan op een Linux-host.

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

De eerste laat zien welke units bestaan en of ze draaien, de tweede bevestigt dat de luisteraar echt gebonden is, en de derde geeft je het eigen verhaal van de dienst over de laatste minuten. Geen ervan bewijst dat een client kan verbinden, daarom gebeurt de volgende stap buiten de host. Bewaar die metingen als je vergelijkingsbasis.

Verifieer vanaf een netwerk dat de tunnel niet gebruikt: authenticeer één geautoriseerde client, los een naam op en bereik één bedoelde toepassing. Een lokale statusregel die zegt dat de interface omhoog is, is een uitspraak over de interface, niet over routering, sleutels of het beleid dat een peer toelaat.

Test daarna bewust het herverbindingspad. Herstart de dienst één keer en bevestig dat de tunnel terugkomt zonder handmatige ingreep, want een dienst die alleen bij het opstarten correct start, is een dienst die je op het slechtste moment verrast.

Als het faalt, gebruik het pad dat je hebt getest

De herstelreeks is niet glamoureus en werkt: bereik de host via het onafhankelijke pad, lees de eigen logs van de dienst en herstel het specifieke controlepunt dat bij het falen hoort. Wijzig één ding per poging, zodat de volgende loglezing iets betekent.

Weerstaan de drang om meerdere niet-vastgelegde wijzigingen te doen om de verbinding terug te krijgen. Een machine die met vijf gelijktijdige aanpassingen is gerepareerd, valt achteraf niet uit te leggen, en de volgende update herintroduceert degene die werkelijk de last droeg.

Bepaal daarna het permanente beleid met bewijs. Als de update een afhankelijkheid blootlegde die niemand documenteerde, is de oplossing documentatie en een test, niet het uitschakelen van updates. Als het een dienst blootlegde die niet schoon kan herstarten, zit de oplossing in de unit, niet in het schema.

De vergelijking valt schoon op zijn plaats zodra de voorwaarde een naam heeft. Een onafhankelijke route maakt onbeheerde updates een beheersbaar risico. Het ontbreken ervan maakt hetzelfde beleid een geplande storing met onbekende hersteltijd, en geen enkele hoeveelheid automatisering verandert die rekensom.