Konfiguracija VPN preživi ponovno ustvarjanje vsebnika le, če jo pripnete

Urejate konfiguracijo WireGuarda znotraj delujočega vsebnika, deluje, naslednja posodobitev image pa jo izbriše. Nič ni bilo napačno nastavljeno. Datoteka je živela v zapisljivi plasti vsebnika, ki obstaja samo za to pojavitev vsebnika. Pomembna primerjava ni, katero orodje uporabiti, ampak katere vhode deklarira vaša namestitev. Vse, kar ste uredili ročno, je vhod, za katerega namestitev ne ve.

Dve vrsti stanja, eno je za zavreči

Vsebnik ima zapisljivo plast za spremembe med izvajanjem, in ta plast se zavrže, ko se vsebnik zamenja. To ni shramba konfiguracije in ni varnostna kopija. Image skupaj z deklariranimi vhodi je celotna definicija tega, kar se izvaja.

Vprašajte se, katere vaše datoteke VPN so deklarirani vhodi in katere so naključja:

docker diff wg-vpn
docker inspect --format '{{json .Mounts}}' wg-vpn

Diff navaja, kaj se je spremenilo v zapisljivi plasti, in to je natanko množica stvari, ki bodo izginile. Seznam priklopov kaže, kaj preživi. Primerjava obojega odgovori na vprašanje, preden kaj izgubite.

Bind mount, imenovana shramba ali skrivnost: kaj vsak ščiti

Vsi trije lahko hranijo profil VPN in se razlikujejo po tem, kdo ga lahko bere in kaj se zgodi ob zamenjavi.

Bind mount preslika pot gostitelja, zato je datoteka zaščitena toliko, kolikor je zaščitena ta pot, in vidna toliko, kolikor to dovoljujejo dovoljenja gostitelja. Imenovana shramba je upravljana z runtime in preživi odstranitev vsebnika, zaradi česar je varnejša privzeta izbira za stanje, ki ga ima namestitev. Mehanizem skrivnosti je za gradivo, ki ga ne želite v image ali v spremenljivki okolja.

Vsake spremenljivke okolja in vsake datoteke gostitelja ne obravnavajte kot enakovredne zaščite, ker nista.

Urejanje znotraj vsebnika je past

Past ni orodje, ampak smer urejanja. Sprememba, narejena znotraj delujočega vsebnika, je za namestitev nevidna, zato jo naslednje ponovno ustvarjanje tiho razveljavi in simptom izgleda kot regresija v image. Če morate tam kaj spremeniti zaradi diagnostike, takoj to kopirajte ven in vstavite v deklarirani vhod. Nato znova ustvarite, da dokažete, da namestitev to reproducira.

Profil lahko nosi zasebne ključe in gradivo računa, zato je varnostna kopija te datoteke naloga ravnanja s skrivnostmi, ne kopiranje datoteke. Lastništvo in bralni dostop omejite na dejanski proces vsebnika, namesto da razširite imenik gostitelja, da bi napaka dovoljenj izginila.

Prav ta razširitev spremeni udobje v vsebniku v izpostavljenost gostitelja.

Namerno znova ustvarite, nato preverite štiri stvari

Zapišite različico image, potrebno napravo in zmogljivosti, omrežno povezavo in trajne vhode. Seznam naprav in zmogljivosti je še posebej pomemben za vsebnik VPN, ker tunel potrebuje omrežno napravo in pravico, da jo nastavi.

Potrdite, katero ustvarjeno stanje izvajanja je treba znova zgraditi in ne shraniti. Ključi, ki jih je tunel ustvaril ob prvem zagonu, so stanje, in odločitev, ali jih obdržati ali znova ustvariti, ima posledice za vsakega peera, ki pozna stari javni ključ.

Po nadzorovanem ponovnem ustvarjanju preverite identiteto, usmerjanje, DNS in zahtevano blokado ob napaki. Proces, ki se zažene brez napak, ne dokaže nobene od teh štirih stvari. Preverite to, medtem ko tunel deluje, in znova po tem, ko ga ustavite, ker se blokada ob napaki pokaže šele, ko tunel izgine.

Hranite kopijo za obnovitev zunaj vsebnika

Hranite kopijo za obnovitev, ki živi neodvisno od vsebnika, in preizkusite njeno obnovitev po dokumentiranem postopku. Nepreizkušena varnostna kopija profila VPN je upanje, zlasti ko pot obnovitve vključuje dovoljenja, ki jih proces vsebnika potrebuje.

Če se vsebnik, ki ima VPN, zamenja, uskladite aplikacije, ki si delijo njegov omrežni sklad, v podprtem življenjskem ciklu runtime.

Ta uskladitev je razlika med ponovnim zagonom in prekinitvijo. Namestitev bi morala opisati, od kod prihaja konfiguracija, in dokumentacija shramb je mesto, kjer preverite, kaj runtime resnično ohrani.