Onaangeraakte opdaterings van ’n VPN-bediener het ’n herstelroete nodig wat jy getoets het

Onaangeraakte opdaterings is ’n redelike beleid vir ’n bediener wat jy oor sy eie VPN bereik, en hulle is ’n enkele punt van selfveroorsaakte mislukking. Die pakketbewerking herbegin die diens, die tonnel val weg, en die administratiewe pad wat jy gebruik het, verdwyn saam daarmee. Daar bestaan twee herstelmodelle, en die keuse tussen hulle hang van een voorwaarde af: of jy ’n roete in het wat nie deur die ding loop wat opgedateer word nie.

Twee herstelmodelle, een beslissende voorwaarde

Die eerste model vertrou die opdatering en aanvaar dat jy daarna weer kan koppel. Dit werk wanneer die VPN een van verskeie maniere is om die gasheer te bereik en wanneer die mislukking van die tonnel nie jou vermoë om dit te diagnoseer wegneem nie. Die tweede model plaas vooraf ’n onafhanklike roete, gewoonlik die konsol van die diensverskaffer, en behandel die tonnel as die ding wat die waarskynlikste deur onderhoud gebreek word. Beide modelle is verdedigbaar, en net een van hulle vereis werk vooraf.

Die beslissende voorwaarde is maklik om te noem en maklik om oor te slaan. As elke administratiewe pad na die masjien deur die diens loop wat opgedateer word, het jy glad geen herstelmodel nie, net ’n verwagting. Sê dit hardop in die veranderingsoorsig.

Om daardie voorwaarde te toets neem tien minute en moet voor die eerste onaangeraakte opdatering gebeur, nie tydens die voorval nie. Maak die konsol oop terwyl alles werk, bevestig dat die geloofsbriewe geldig is, en maak dit weer toe. Bevestig dat die konsol na die gasheer oopmaak wat jy dink dit is. Bevestig dan dat die aanmelding wat jy om 3 in die oggend werklik sou gebruik, nog werk.

Daardie laaste deel maak meer saak as wat dit klink. ’n Konsolrekening wie se wagwoord ses maande gelede geroteer en nooit geverifieer is nie, is nie ’n herstelpad nie; dit is ’n dokument wat een beskryf.

Wat ’n rugsteun nie herstel nie

’n Konfigurasie-argief is ’n rekord van lêers, en ’n opdatering verander meer as lêers. Pakkettoestand, kernmodules, geaktiveerde eenheidskakels en vuurmuurreëls wat deur ’n aparte instrument toegepas is, leef almal buite ’n konfigurasiegids, en ’n herstel wat hulle ignoreer, lewer ’n masjien wat gekonfigureer lyk en nie deurstuur nie.

Magtiging verdien sy eie reël. ’n Rugsteun wat geneem is voordat ’n gekompromitteerde toestel verwyder is, sal daardie toestel se toegang met graagte herstel. Om tydens ’n onderbreking daarna terug te rol, is hoe een voorval twee voorvalle word, en die besluit om te herstel moet oor eweknieë net so uitdruklik geneem word as oor lêers.

Die meganisme van die terugrol maak ook saak. Om ’n ouer uitvoerbare lêer oor een te kopieer wat deur die pakketbestuurder bestuur word, is nie die ondersteunde terugdraaiing van ’n pakketverandering nie, en dit laat die pakketdatabasis ’n toestand beskryf wat nie by die lêerstelsel pas nie. Gebruik die pakketbestuurder se eie afgraderingspad of die momentopname wat die verskaffer bied. ’n Afgradering wat die pakketdatabasis aanteken, is een wat jy kan herhaal.

Niks hiervan argumenteer teen rugsteune nie. Dit argumenteer daarvoor om te weet watter laag elke artefak dek, want die mislukkingswyse van ’n gedeeltelike herstel is verwarrender as die oorspronklike onderbreking. Skryf die laag langs elke rugsteun in die runbook.

Kontrolepunt, opdateer, en verifieer dan van buite

Teken die toestand voor die verandering aan in ’n vorm wat jy later kan vergelyk: die geïnstalleerde weergawes, die betrokke dienseenhede, die luisterende sokkels en die huidige eweknie-lys. Vier opdragte dek die meeste daarvan op ’n Linux-gasheer.

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

Die eerste wys watter eenhede bestaan en of hulle loop, die tweede bevestig dat die luisteraar werklik gebind is, en die derde gee jou die diens se eie weergawe van die laaste paar minute. Nie een van hulle bewys dat ’n kliënt kan koppel nie, en daarom gebeur die volgende stap van buite die gasheer. Hou daardie lesings as jou vergelykingsbasislyn.

Verifieer vanaf ’n netwerk wat nie die tonnel gebruik nie: outentiseer een gemagtigde kliënt, los ’n naam op, en bereik een beoogde toepassing. ’n Plaaslike statuslyn wat sê die koppelvlak is op, is ’n stelling oor die koppelvlak, nie oor roetering, sleutels of die beleid wat ’n eweknie toelaat nie.

Toets dan die herkoppelingspad doelbewus. Herbegin die diens een keer en bevestig dat die tonnel sonder handmatige ingryping terugkom, want ’n diens wat net by die opstart korrek begin, is ’n diens wat jou op die slegste oomblik gaan verras.

Wanneer dit misluk, gebruik die pad wat jy getoets het

Die herstelreeks is onopsigtelik en dit werk: bereik die gasheer deur die onafhanklike roete, lees die diens se eie logs, en herstel die spesifieke kontrolepunt wat by die mislukking pas. Verander een ding per poging sodat die volgende lees van die log iets beteken.

Weerstaan die drang om verskeie onopgetekende veranderinge te maak om konnektiwiteit terug te kry. ’n Masjien wat deur vyf gelyktydige wysigings reggemaak is, kan daarna nie verduidelik word nie, en die volgende opdatering sal die een wat werklik draend was, weer invoer.

Besluit dan die permanente beleid met bewyse. As die opdatering ’n afhanklikheid ontbloot het wat niemand gedokumenteer het nie, is die oplossing dokumentasie en ’n toets, nie om opdaterings af te skakel nie. As dit ’n diens ontbloot het wat nie skoon kan herbegin nie, is die oplossing in die eenheid, nie in die skedule nie.

Die vergelyking val skoon op plek sodra die voorwaarde genoem is. ’n Onafhanklike roete maak onaangeraakte opdaterings ’n hanteerbare risiko. Die afwesigheid daarvan maak dieselfde beleid ’n geskeduleerde onderbreking met ’n onbekende hersteltyd, en geen hoeveelheid outomatisering verander daardie rekenkunde nie.