Rakenna Raspberry Pi VPN -laite uudelleen kopioimatta sen avainta

Kertaalleen kuvasta käynnistäminen ei tee Pistä uudelleenrakennettavaa laitetta. Tarvitset pienen joukon syötteitä, jotka voit soveltaa uudelleen: ylläpidetty perusta, julistettu kokoonpano, sovelluksen pysyvät tiedot ja laiteidentiteetti, joka kuuluu vain kyseiselle levylle. Jos ohitat viimeisen, jokaisesta korvaajasta tulee tunnistetietojen klooni.

Alla olevat vaiheet ovat työjärjestys, eivät työkalusuositus. Mikä tahansa kokoonpanojärjestelmä, joka pystyy ilmaisemaan ne, kelpaa.

Listaa ensin neljä syötetyyppiä

Peruskuva ja sen paketit määrittelevät käyttöjärjestelmän, arkkitehtuurin ja sen, mistä päivitykset tulevat, ja kuvien rakentaja auttaa vain, jos sen nimeämä työkalu on edelleen ylläpidetty julkaisullesi. Julistettu kokoonpano on osa, jonka ihminen tarkistaa: verkon roolit, palveluiden asetukset ja elinkaaritoimet, joita kukin palvelu tarvitsee. Sovelluksen pysyvät tiedot ovat kaikki, mitä palvelu ei voi tuottaa uudelleen, ja niiden sijainti ja varmistusmenetelmä kuuluvat kyseiselle sovellukselle, eivät kuvalle. Laiteidentiteetit ja salaisuudet ovat neljäs syöte, ja juuri ne ihmiset unohtavat kloonatessaan toimivaa korttia.

Kirjoita neljä listaa ennen kuin rakennat mitään uudelleen. Lista, jossa on tyhjä rivi, on päätös, jota et ole vielä tehnyt.

Pidä salaisuudet poissa repositoriosta ja kerro, missä ne asuvat

Repositorio on hyvä koti tarkastetuille malleille ja ei-salaiselle kokoonpanolle sekä huono koti VPN:n yksityisavaimille, uudelleenkäytettäville ylläpitäjätunnuksille ja diagnostiikka-arkistoille. Jos salaisuuden on oltava laitteessa, kirjaa, mistä se tulee, kuka voi lukea sen ja miten se kierrätetään. Avain, joka elää vain yhdellä SD-kortilla, on yksittäinen vikapiste, kun taas jokaiselle levylle kopioitu avain on koko laivaston tunnistetieto ilman omistajaa. Kumpikaan ei ole palautussuunnitelma.

Testi on yksinkertainen: jos repositorio vuotaisi huomenna, mitä hyökkääjä voittaisi? Mallit ja topologiamuistiinpanot säilyvät. Toimiva identiteetti ei.

Anna automaation omistaa se, minkä se voi ajaa uudelleen

Ansiblen malli pitää hallittujen solmujen luettelon erillään näytelmistä, tehtävistä, rooleista ja käsittelijöistä, jotka laukeavat, kun tehtävä ilmoittaa muutoksesta. Käytä tätä rakennetta antaaksesi jokaiselle palvelulle yhden kokoonpanon omistajan sen sijaan, että toistaisit komentotulkin historian. Suosi toimintoja, jotka on turvallista ajaa kahdesti, ja päätä tietoisesti, miten muutettu tiedosto saavuttaa käynnissä olevan prosessin. Tehtävä, joka varmistaa palvelun käynnistyneen, ei välttämättä saa sitä lataamaan uudelleen kokoonpanoa, jonka juuri kirjoitit uudelleen.

Erota myös hallinnan vaiheet. Käynnistyksen yhteys, rutiinikokoonpano ja VPN:stä riippuva hallinta ovat kolme eri ikkunaa, ja kolmas voi poistaa oman pääsysi, jos uudelleenrakennus nollaa sen alla olevan verkon. Pidä itsenäinen reitti sisään.

Palauta tiedot ja identiteetti tarkoituksella

Konttien taltiot säilyvät kontin elinkaaresta riippumatta, mutta kontin sisäinen kirjoitettava kerros ei, minkä vuoksi kontin luominen uudelleen sen kuvasta ei palauta tilaa, jota sovellus käytti, kuten taltioiden dokumentaatio kuvaa. Kirjaa taltiot, liitospisteet ja ulkoiset palvelut, joista laite riippuu, ja käytä sovelluksen omaa varmistus- ja palautusprosessia. Kontti, joka käynnistyy ilman virhettä, ei ole todiste siitä, että sen tietokanta ja tiedostot ovat sopusoinnussa.

Identiteetin osalta päätä, palautatko saman laitteen vai rekisteröitkö korvaajan, koska ne ovat eri toimintoja erilaisella siivouksella.

Sovita vanhan vertaiskumppanin pääsy ennen kuin aktivoit identiteetin muualla, ja vasta sitten testaa uudelleenrakennettua laitetta eristetyssä tai palautusympäristössä. Tarkista tarvittavat tiedot, oikea identiteetti, omistajallinen päivityspolku ja aiottu verkkokäytäntö.

Käynnistettävä kuva on yksi neljästä syötteestä, ja se on helpoin toistaa.