Genopbyg et Raspberry Pi VPN-apparat uden at kopiere dets nøgle

At starte én gang fra et image gør ikke en Pi til et apparat, der kan genopbygges. Det, du har brug for, er et lille sæt input, du kan anvende igen: en vedligeholdt base, en erklæret konfiguration, applikationens vedvarende data og en enhedsidentitet, der kun tilhører det board. Springer du det sidste over, bliver enhver udskiftning en klon af en legitimationsoplysning.

Trinnene nedenfor er en arbejdsrækkefølge frem for en værktøjsanbefaling. Ethvert konfigurationssystem, der kan udtrykke dem, duer.

List de fire slags input først

Basisimaget og dets pakker definerer styresystemet, arkitekturen og hvor opdateringer kommer fra, og en imagebygger hjælper kun, hvis det værktøj, den navngiver, stadig vedligeholdes til din udgivelse. Den erklærede konfiguration er den del, et menneske gennemgår: netværksroller, serviceindstillinger og de livscyklushandlinger, hver service har brug for. Vedvarende applikationsdata er alt, hvad servicen ikke kan genskabe, og deres placering og backupmetode tilhører applikationen frem for imaget. Enhedsidentiteter og hemmeligheder er det fjerde input, og dem glemmer folk, når de kloner et fungerende kort.

Skriv de fire lister, før du genopbygger noget. En liste med en tom række er en beslutning, du endnu ikke har taget.

Hold hemmeligheder ude af repositoriet, og sig hvor de bor

Et repository er et godt hjem for gennemgåede skabeloner og ikke-hemmelig konfiguration og et dårligt hjem for private VPN-nøgler, genbrugelige administratorlegitimationsoplysninger og diagnostiske arkiver. Hvis en hemmelighed skal findes på enheden, så notér, hvor den kommer fra, hvem der kan læse den, og hvordan den roteres. En nøgle, der kun lever på ét SD-kort, er et enkelt fejlpunkt, mens en nøgle kopieret til hvert board er en flådeomspændende legitimationsoplysning uden ejer. Ingen af dem er en gendannelsesplan.

Testen er enkel: hvis repositoriet lækkede i morgen, hvad ville en angriber så vinde? Skabeloner og topologinoter kan overleve. En fungerende identitet kan ikke.

Lad automatisering eje det, den kan køre igen

Ansibles model holder et inventar af administrerede noder adskilt fra plays, tasks, roller og handlere, der udløses, når en task rapporterer en ændring. Brug den struktur til at give hver service én konfigurationsejer i stedet for at genafspille en shell-historik. Foretræk operationer, der er sikre at køre to gange, og beslut bevidst, hvordan en ændret fil når den kørende proces. En task, der sikrer, at en service er startet, får den ikke nødvendigvis til at genindlæse en konfiguration, du lige har skrevet om.

Adskil også administrationsfaserne. Opstartsforbindelse, rutinekonfiguration og VPN-afhængig styring er tre forskellige vinduer, og det tredje kan fjerne din egen adgang, hvis genopbygningen nulstiller netværket under det. Behold en uafhængig vej ind.

Gendan data og identitet med vilje

Containervoluminer består uafhængigt af containerens livscyklus, mens det skrivbare lag inde i en container ikke gør, og derfor genskaber en container fra sit image ikke den tilstand, applikationen brugte, som volumendokumentationen beskriver. Notér de volumener, bind-monteringer og eksterne tjenester, apparatet afhænger af, og brug applikationens egen backup- og gendannelsesproces. En container, der starter uden fejl, er ikke bevis for, at dens database og dens filer passer sammen.

For identitet skal du beslutte, om du gendanner den samme enhed eller tilmelder en erstatning, for det er forskellige operationer med forskellig oprydning.

Afstem den gamle peers adgang, før du aktiverer en identitet andre steder, og test først derefter det genopbyggede apparat i et isoleret miljø eller gendannelsesmiljø. Kontrollér de nødvendige data, den korrekte identitet, en opdateringsvej med en ejer og den tilsigtede netværkspolitik.

Et bootbart image er ét input blandt fire, og det er det nemmeste at genskabe.