Komuna CA, apartaj pordoj: unu servo por akcepta dosiero

Atestilo, kiu validiĝas kontraŭ komuna aŭtoritato, trapasis teston de fido, ne teston de membreco. Tiuj du decidoj ofte kunfandiĝas, ĉar ambaŭ okazas ĉe konekta tempo, kaj la kunfandiĝo restas nevidebla ĝis iu, kiu ne apartenu al servo, estas akceptata en ĝin. La solvo ne estas dua aŭtoritato; ĝi estas dua decido, farita por ĉiu servo kaj registrita tie, kie la demono legas ĝin. Tenu la du aparte kaj la plej granda parto de la konfuzo en ĉi tiu kampo malaperas.

Fidinda ĉeno diras nenion pri serva membreco

Du servoj povas akcepti la saman eldonan hierarkion kaj tamen havi malsamajn populaciojn. Unu tekkomputilo apartenas al la unua kaj ne rajtas atingi la duan, dum aliaj klientoj de la sama hierarkio ja apartenas tie. Forigi la aŭtoritaton el tiu servo ŝlosus ĉiujn, kiuj laŭleĝe uzas ĝin, do la laboro estas akcepto, ne fido.

Utile estas imagi du serurojn sur unu pordo. La atestilo malfermas la eksteran seruron, kaj decido por ĉiu servo malfermas la internan; neniu anstataŭas la alian. Servo kun nur la ekstera seruro tute ne plenumas membrecon, ĝi nur aŭtentikigas. Skribu ambaŭ decidojn antaŭ ol ŝanĝi ion, ĉar politiko, kiu ekzistas nur en la formo de funkcianta konekto, ne povas esti reviziita. La sekvanta temo estas la interna seruro.

Faru elekteblajn anstataŭigojn akcepta pordego

Klienta agorda dosierujo estas kutime oportunaĵo: dosieroj en ĝi anstataŭigas agordojn por la klientoj, kiujn ili nomas, kaj kliento sen dosiero simple funkcias kun la defaŭltoj de la servilo. Unu direktivo transformas tiun oportunaĵon en pordegon, tiel ke mankanta dosiero signifas, ke la konekto estas rifuzata.

client-config-dir /etc/openvpn/service-a/clients
ccd-exclusive

La komunuma eldono de OpenVPN 2.6 ccd-exclusive en sia manlibra paĝo dokumentas ĝuste tiun kondiĉon, kaj la serĉo de la nomita dosiero dependas de la efektiva identeco de la kliento. Aliaj konstruoj kaj produkto-administrataj serviloj povas diferenci, do konfirmu la instalitan version antaŭ ol fidi la saman semantikon aliloke.

Traktu la supran vojon kiel ekzemplon kaj kontrolu la efektive starigitan aranĝon anstataŭ krei dosierujon, kiun elpensis gvidilo. Lasu la ekzistantajn atestilkontrolojn, servilidentecojn kaj kontaŭtentikigon ekzakte kiel ili estis, ĉar la fragmento aldonas kondiĉon kaj forigas nenion. Preparu la ŝanĝon antaŭ produkta uzo, ĉar rifuzo levita en la malĝusta punkto aspektas kiel atestila fiasko kaj sendas la esploradon al la aŭtoritato. Poste konfirmu, ke la protokollinio por rifuzita kliento nomas la mankantan agordan dosieron, ne la ĉenon.

Unu dosierujo por servo, ne unu komuna listo

Membreco apartenas al la servo, kiu ĝin plenumas, do ĉiu servo tenas sian propran dosierujon kaj siajn proprajn dosierojn. Montri du servojn al unu listo igas ilin dividi membrecon ĉu iu intencis tion aŭ ne, kaj la rezulta ŝanĝo malfacile spuratas al decido. La komuna aŭtoritato povas resti komuna; la akceptaj dosieroj ne povas. Teni ilin aparte ankaŭ signifas, ke eraro en unu servo ne povas silente larĝigi alian.

DEFAULT-enskribo estas la kazo, kiu trompas homojn. Ĝi provizas rezervajn agordojn, kiam nomita dosiero ne troviĝas, sed ĝi ne estas la nomita dosiero, kiun la pordego postulas, do ĝi ne povas akcepti klienton per si mem. Testu klienton, kiu tute ne havas enskribon, kaj konfirmu la rifuzon; se tiu kliento estas akceptata, la rezervo aplikiĝas kaj ccd-exclusive ne validas en tiu okazo.

La efektiva identeco decidas, kiu dosiero estas legata

La serĉo uzas la identecon, per kiu la kliento efektive aŭtentikigis sin, kiu kutime estas la komuna nomo de la atestilo. Kiam la servilo ankaŭ kontrolas uzantnomon kaj pasvorton kaj mapas tiun nomon al la komuna nomo, la dosiero devas anstataŭe kongrui kun la aŭtentikigita uzantnomo. Miskongruo lasas dosierujon plenan de kredeblaj dosiernomoj, kiuj neniam estas elektitaj.

Legado estas la alia duono. La demono kutime forlasas privilegiojn post lanĉo, do la reduktita konto bezonas legan aliron al la dosierujo kaj al ĉiu enskribo en ĝi. Klientoj ne rajtas povi krei sian propran enskribon tra iu ajn skribebla vojo, ĉar memserva akcepto tute senvalidigas la mekanismon. Kontrolu la muntajn kaj dividajn permesojn kaj ne nur la dosiermodon, ĉar dosierujo, kiu aspektas fermita por unu konto, povas esti malfermita por alia. Poste konfirmu, kiun konton la kuranta procezo vere uzas, ne kiun konton mencias la unit-dosiero. Tiuj du samas nur kiam nenio alia ŝanĝis ilin.

Observu rifuzon, akcepton kaj revokon aparte

Provu identecon, kiu apartenas al la servo, kaj konfirmu, ke ĝi konektiĝas. Provu validan atestilon sen enskribo kaj konfirmu, ke ĝi estas rifuzata. Provu identecon akceptitan en la alia servo kaj konfirmu, ke ĝi ne estas akceptata ĉi tie. Notu la servan okazon kaj la efektivan identecon apud ĉiu rezulto, ĉar rezulton sen tiu kunteksto neniu alia povas reprodukti.

Retiriĝo estas aparta operacio de revoko. Redakti akceptan dosieron forigas unu servan rajtigon, dum la identeco restas valida ĉie alie, dum kompromitita ŝlosilo bezonas la revokan respondon de la organizo. Decidu anticipe, kio okazas al sesioj jam aktivaj, ĉar nek dosieruja redakto nek revoka listo finigas ilin per si mem.

Akcepto ankaŭ estas nur la unua pordego. Aliĝi al servo diras nenion pri la subretoj, datumbazoj aŭ administraj interfacoj malantaŭ ĝi, kaj tiu rimeda politiko devas esti skribita kaj testita aparte.