Tenu la subskriban ŝlosilon de la OpenVPN-CA ekster /etc/openvpn
La laborspaco de la CA eldonas identecojn; la servo nur konsumas deplojitan materialon. Donu al ĉiu rolo propran konton, dosierujon kaj sekurkopion, kaj kontrolu ambaŭ.
Du dosierujoj, kiuj en lernilo aspektas similaj, plenumas tute malsamajn taskojn. Unu enhavas la atestan aŭtoritaton: ĝian privatan ŝlosilon, ĝian serinumeran kalkulilon kaj la registron de ĉio, kion ĝi subskribis. La alia enhavas tion, kion la demono bezonas por starti kaj servi klientojn. Meti ambaŭ sur la saman gastigan maŝinon sub la sama konto estas oportuna por unu posttagmezo kaj multekosta por la resto de la vivo de la deplojo, ĉar la demono tiam funkcias apud la sola ŝlosilo, kiu povas krei ajnan identecon, kiun ĝi volas.
Kion enhavas la laborspaco de la CA
PKI-dosierujo estas stato de la eldonanto, ne agordo. Ĝi enhavas la privatan ŝlosilon kaj atestilon de la CA, serinumeran dosieron, indekson de eldonitaj atestiloj kaj la materialon por ĉiu identeco produktitan el ili.
Subskribi peton ŝanĝas tiun staton, tial la laborspaco apartenas al konto kontrolata de administranto sur gastiga maŝino, kie la VPN-servo ne funkcias. Ĉiu, kiu povas legi la privatan ŝlosilon de la CA, povas eldoni atestilon, kiun la servilo fidos, do la protekto de la ŝlosilo estas la tuta fida modelo en unu dosiero. Kopii ĝin al dua loko por ŝpari paŝon kreas duan aferon por protekti kaj duan aferon por forgesi. Ĉiu subskribo ankaŭ pliigas la serinumeron kaj aldonas eron al la indekso, tial la laborspaco estas unu kopio de stato, ne dosierujo da dosieroj.
La publika atestilo de la CA estas malsama. Ĝi estas destinita por disvastigo, kaj ĝin uzas klientoj kaj serviloj por kontroli unu la alian.
Kion la demono legas ĉe starto
Funkcianta servilo konsumas malgrandan aron: sian propran atestilon, sian propran privatan ŝlosilon, la atestilon de la CA por kontroli la partnerojn kaj ajnan ŝlosilan materialon, kiun postulas ĝia elektita reĝimo. Ĝi legas tiujn vojojn ĉe starto kaj denove ĉe reŝargo.
Posedo devas esti taksata laŭ la unuo, kiu efektive startas, ne laŭ interaga radika ŝelo. Deklarita sabloludilo povas igi parton de la dosiersistemo nurlegebla aŭ nevidebla eĉ kiam mana testo kiel radiko sukcesas.
systemctl show -p User -p Group -p ReadOnlyPaths [email protected]
stat -c '%a %U:%G' /etc/openvpn/server/server.key
runuser -u openvpn -- test -r /etc/openvpn/server/server.key; echo $?La tria linio estas tiu, kiun homoj preterlasas. Ĝi demandas la propran konton de la demono, ĉu ĝi povas legi la ŝlosilon, kaj tio estas la sola versio de la demando, kiu gravas post kiam privilegioj estas forlasitaj. Nula eliro kiel radiko diras nenion pri tio, kio okazas post la forlaso.
Indas apartigi la du erarvojojn antaŭ ol ŝanĝi ajnan permeson. Subskriba eraro montras al la PKI-dosierujo, la serĉpermeso en ĝiaj patraj dosierujoj kaj la konto, kiu funkciigas la eldonanton. Starta eraro montras al la unuo, ĝia labordosierujo kaj la vojoj nomitaj en la servila agordo. Igi la tutan arbon legebla por ĉiuj riparas nek unu nek la alian kaj forigas la limon, de kiu ambaŭ dependas.
Kial kopii la CA-ŝlosilon al la servilo malsukcesas poste
La kopio kutime komenciĝas kiel sencimiga movo: iu volas renovigi klienton sur la VPN-gastiganto, do la CA-ŝlosilo finiĝas en /etc/openvpn kaj la renovigo funkcias. La tuja tasko sukcesas, kaj la limo malaperis.
Poste la servilo estas sekurkopiita, kaj la subskriba aŭtoritato aliĝas al la kopioj. Momentfoto, subtena pako aŭ kopio de la agorda dosierujo nun portas la kapablon eldoni fidatajn identecojn dum la CA validas. Kiu ajn posedas tiun kopion, povas krei atestilon por ajna nomo, kiun la servilo akceptas, inkluzive de nomoj, kiuj neniam estis eldonitaj. La sola registro pri tiu eldono estas tiu, kiun ili elektas konservi.
Rekuperiĝi de tiu stato ne temas pri forigo de dosiero. Vi devas decidi, ĉu la ŝlosilo estis elmontrita, rotacii la CA se jes, kaj redistribui fidon al ĉiu partnero. Aparta laborspaco evitas la tutan konversacion.
Kontoj, dosierujoj, sekurkopioj
Donu al la eldonanto propran konton kaj hejman dosierujon, tenatajn for de la VPN-gastiganto, kie tio praktikeblas. Donu al la demono alian konton, kun legrajto al la deplojita materialo kaj skribrajto al nenio, kio eldonas atestilojn. Deploju kopiante publikajn atestilojn eksteren kaj neniam tirante privatan staton de la eldonanto enen. Sekurkopiu la du rolojn aparte, ĉar ilia sentemo kaj iliaj restaŭraj rakontoj malsamas.
Post revoko, ĝisdatigu la CRL-dosieron, kiun nomas la servila agordo, poste reŝargu la servon, por ke novaj konektoj legu ĝin. La dokumentaro de Easy-RSA kovras la aranĝon de la laborspaco kaj la subskriban fluon; la posedreguloj ĉirkaŭ ĝi restas decido pri via gastiganto. Konfirmu, kion la servo ŝargis per openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate anstataŭ supozi, ke la reŝargo prenis ĝin.
Testo, kiu pruvas la apartigon
Kontrolu la negativan kazon, ne nur la funkciantan. Subskribu atestilon el la konto de la eldonanto laŭ la plano, poste konfirmu, ke la sama konto ne povas starti la servon nek legi la privatan ŝlosilon de la servilo. Poste konfirmu, ke la konto de la demono ne povas legi la privatan ŝlosilon de la CA.
Tiuj tri kontroloj daŭras kelkajn minutojn kaj postvivas personarajn ŝanĝojn, ĉar ili estas asertoj pri permesoj, ne pri kutimo. Skribu la rezulton kun la vojoj kaj kontoj, kiujn ĝi kovris, plus la dato, kiam vi rulis ilin. La sekva persono, kiu heredos ĉi tiun deplojon, alie denove derivos la limon el lernilo, kiu neniam havis unu. Datita registro ankaŭ estas tio, kio igas la sekvan revizion daŭri minutojn anstataŭ posttagmezon.