Valvomattomat VPN-palvelimen päivitykset tarvitsevat testatun palautuspolun

Valvomattomat päivitykset ovat järkevä käytäntö palvelimelle, jolle pääset sen oman VPN:n kautta, ja samalla ne ovat yksi itse aiheutettu vikapiste. Pakettitoimenpide käynnistää palvelun uudelleen, tunneli putoaa ja käyttämäsi hallintapolku katoaa sen mukana. Palautusmalleja on kaksi, ja valinta niiden välillä riippuu yhdestä ehdosta: onko sinulla pääsypolku, joka ei kulje päivitettävän asian kautta.

Kaksi palautusmallia, yksi ratkaiseva ehto

Ensimmäinen malli luottaa päivitykseen ja olettaa, että voit yhdistää uudelleen sen jälkeen. Se toimii, kun VPN on yksi useista tavoista päästä isäntään ja kun tunnelin vika ei poista kykyäsi diagnosoida sitä. Toinen malli sijoittaa etukäteen riippumattoman polun, tavallisesti hosting-palveluntarjoajan konsolin, ja kohtelee tunnelia asiana, jonka ylläpito todennäköisimmin rikkoo. Molemmat mallit ovat perusteltavissa, ja vain toinen niistä vaatii työtä etukäteen.

Ratkaiseva ehto on helppo sanoa ja helppo ohittaa. Jos jokainen hallintapolku koneelle kulkee päivitettävän palvelun kautta, sinulla ei ole lainkaan palautusmallia, vain odotus. Sano se ääneen muutoksen katselmoinnissa.

Ehdon testaaminen kestää kymmenen minuuttia ja sen on tapahduttava ennen ensimmäistä valvomatonta päivitystä, ei häiriön aikana. Avaa konsoli, kun kaikki toimii, vahvista että tunnistetiedot ovat voimassa ja sulje se taas. Vahvista, että konsoli avautuu isäntään, jota luulet. Vahvista sitten, että kirjautuminen, jota todella käyttäisit kello 3 yöllä, toimii edelleen.

Viimeinen osa on tärkeämpi kuin miltä se kuulostaa. Konsolitili, jonka salasana vaihdettiin kuusi kuukautta sitten eikä sitä koskaan vahvistettu, ei ole palautuspolku; se on asiakirja, joka kuvailee sellaisen.

Mitä varmuuskopio ei palauta

Konfiguraatioarkisto on tiedostojen kirjanpito, ja päivitys muuttaa enemmän kuin tiedostoja. Paketin tila, ytimen moduulit, käytössä olevat yksikkölinkit ja erillisellä työkalulla sovelletut palomuurisäännöt elävät kaikki konfiguraatiohakemiston ulkopuolella, ja palautus, joka jättää ne huomiotta, tuottaa koneen, joka näyttää konfiguroidulta eikä välitä.

Valtuutus ansaitsee oman rivinsä. Ennen kompromettoidun laitteen poistamista otettu varmuuskopio palauttaa mielellään kyseisen laitteen pääsyn. Siihen palaaminen keskeytyksen aikana on tapa, jolla yhdestä häiriöstä tulee kaksi, ja palautuspäätös pitäisi tehdä vertaisista yhtä eksplisiittisesti kuin tiedostoista.

Myös palautuksen mekanismi on tärkeä. Vanhemman suoritettavan tiedoston kopioiminen paketinhallitun päälle ei ole pakettimuutoksen tuettu peruuttaminen, ja se jättää pakettitietokannan kuvaamaan tilaa, jota tiedostojärjestelmä ei vastaa. Käytä paketinhallinnan omaa downgrade-polkua tai palveluntarjoajan tarjoamaa tilannekuvaa. Downgrade, jonka pakettitietokanta kirjaa, on sellainen, jonka voit toistaa.

Mikään tästä ei puhu varmuuskopioita vastaan. Se puhuu sen puolesta, että tietää, minkä kerroksen kukin artefakti kattaa, koska osittaisen palautuksen vikatila on sekavampi kuin alkuperäinen keskeytys. Kirjoita kerros runbookiin jokaisen varmuuskopion viereen.

Tarkistuspiste, päivitys ja sitten varmistus ulkopuolelta

Kirjaa tila ennen muutosta muotoon, jota voit verrata myöhemmin: asennetut versiot, asianosaiset palveluyksiköt, kuuntelevat socketit ja nykyinen vertaislista. Neljä komentoa kattaa suurimman osan siitä Linux-isännällä.

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

Ensimmäinen näyttää, mitkä yksiköt ovat olemassa ja ovatko ne käynnissä, toinen vahvistaa, että kuuntelija on todella sidottu, ja kolmas antaa palvelun oman kertomuksen viime minuuteista. Mikään niistä ei todista, että asiakas voi yhdistää, siksi seuraava vaihe tapahtuu isännän ulkopuolella. Pidä nuo lukemat vertailuperustanasi.

Varmista verkosta, joka ei käytä tunnelia: todentaa yksi valtuutettu asiakas, ratkaise nimi ja saavuta yksi aiottu sovellus. Paikallinen tilalarivi, joka sanoo että liitäntä on ylhäällä, on väite liitännästä, ei reitityksestä, avaimista tai käytännöstä, joka hyväksyy vertaisen.

Testaa sitten uudelleenyhdistämisen polku tarkoituksella. Käynnistä palvelu uudelleen kerran ja vahvista, että tunneli palaa ilman käsikäyttöistä toimenpidettä, koska palvelu, joka käynnistyy oikein vain käynnistyksen yhteydessä, on palvelu, joka yllättää sinut pahimmalla hetkellä.

Kun se epäonnistuu, käytä polkua, jonka testasit

Palautusjakso ei ole loistokas ja se toimii: saavuta isäntä riippumatonta polkua pitkin, lue palvelun omat lokit ja palauta se tietty tarkistuspiste, joka vastaa vikaa. Muuta yhtä asiaa kerrallaan, jotta seuraava lokin lukeminen merkitsee jotain.

Vastusta halua tehdä useita kirjaamattomia muutoksia yhteyden palauttamiseksi. Konetta, joka korjattiin viidellä samanaikaisella muutoksella, ei voi jälkeenpäin selittää, ja seuraava päivitys tuo takaisin sen, joka todella kantoi kuorman.

Päätä sitten pysyvä käytäntö todisteiden kanssa. Jos päivitys paljasti riippuvuuden, jota kukaan ei dokumentoinut, korjaus on dokumentaatio ja testi, ei päivitysten poistaminen käytöstä. Jos se paljasti palvelun, joka ei käynnisty puhtaasti uudelleen, korjaus on yksikössä, ei aikataulussa.

Vertailu ratkeaa puhtaasti, kun ehto on nimetty. Riippumaton polku tekee valvomattomista päivityksistä hallittavan riskin. Sen puuttuminen tekee samasta käytännöstä aikataulutetun keskeytyksen, jonka palautusaika on tuntematon, eikä mikään määrä automaatiota muuta sitä aritmetiikkaa.