Dield CA, aparte doarren: ien tsjinst per talittingsbestân

In sertifikaat dat tsjin in dield gesach falidearret, hat in test fan fertrouwen trochstien, gjin test fan lidmaatskip. Dy twa besluten wurde faak gearfoege om't se beide by ferbiningstild barre, en de gearfoeging bliuwt ûnsichtber oant immen dy't net op in tsjinst heart dêr talitten wurdt. De oplossing is gjin twadde gesach; it is in twadde beslút, naam per tsjinst en fêstlein dêr't de daemon it lêst. Hâld de twa apart en it measte fan 'e betizing yn dit fjild ferdwynt.

In fertroude keatling seit neat oer tsjinstlidmaatskip

Twa tsjinsten kinne deselde útjouwende hiërargy akseptearje en dochs ferskate populaasjes hawwe. Ien laptop heart by de earste en mei de twadde net berikke, wylst oare klanten fan deselde hiërargy dêr wol by hearre. It gesach út dy tsjinst weihelje soe elkenien útslute dy't it rjochtlik brûkt, dus it wurk is talitting, net fertrouwen.

It helpt om twa sloten op ien doar foar te stellen. It sertifikaat iepenet it bûtenste slot, en in beslút per tsjinst iepenet it binnenste; gjin fan beide ferfangt de oare. In tsjinst mei allinnich it bûtenste slot hanthavet hielendal gjin lidmaatskip, it autentisearret allinnich. Skriuw beide besluten op foardat jo wat feroarje, want in belied dat allinnich bestiet yn 'e foarm fan in wurkjende ferbining kin net auditearre wurde. Wat folget giet oer it binnenste slot.

Meitsje opsjonele oerskriuwings in talittingsdoar

In klantkonfiguraasjemap is normaal in geriif: bestannen deryn oerskriuwe ynstellingen foar de klanten dy't se neame, en in klant sûnder bestân draait gewoan mei de standertwearden fan 'e tsjinner. Ien rjochtline makket dat geriif in doar, sadat in ûntbrekkend bestân betsjut dat de ferbining wegere wurdt.

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

De mienskipsferzje fan OpenVPN 2.6 ccd-exclusive dokumintearret syn hânboek-side krekt dizze betingst, en it sykjen fan it neamde bestân hinget ôf fan 'e effektive klantidentiteit. Oare builds en troch produkten beheardene tsjinners kinne ôfwike, dat befêstigje de ynstallearre ferzje foardat jo earne oars op deselde semantyk fertrouwe.

Besjoch it paad hjirboppe as foarbyld en kontrolearje de útrôle yndieling ynstee fan in map te meitsjen dy't in hânlieding betocht hat. Lit de besteande sertifikaatkontrôles, tsjinneridentiteitskontrôles en akkountautentikaasje krekt sa't se wiene, want it fragmint foeget in betingst ta en hellet neat wei. Tariede de feroaring foar produksje, om't in wegering op it ferkearde punt derút sjocht as in sertifikaatflater en it ûndersyk nei it gesach stjoert. Befêstigje dêrnei dat de logrigel foar in wegere klant it ûntbrekkende konfiguraasjebestân neamt en net de keatling.

Ien map per tsjinst, net ien dielde list

Lidmaatskip heart by de tsjinst dy't it hanthavet, dus elke tsjinst hâldt syn eigen map en syn eigen bestannen. Twa tsjinsten nei ien list wize lit se lidmaatskip diele oft immen dat no woe of net, en de resultearjende feroaring is dreech werom te folgjen nei in beslút. It dielde gesach kin dield bliuwe; de talittingsbestannen kinne dat net. Se apart hâlde betsjut ek dat in flater yn ien tsjinst in oare net stil ferbreidzje kin.

In DEFAULT-ynfier is it gefal dat minsken misliedet. It leveret fallback-ynstellingen as gjin neamd bestân fûn wurdt, mar it is net it neamde bestân dat de doar ferget, dus it kin in klant net allinnich talitte. Test in klant dy't hielendal gjin ynfier hat en befêstigje de wegering; as dy klant talitten wurdt, wurdt de fallback tapast en ccd-exclusive is net fan krêft yn dat eksimplaar.

De effektive identiteit beslút hokker bestân lêzen wurdt

It sykjen brûkt de identiteit dêr't de klant him wier mei autentisearre hat, normaal de mienskiplike namme fan it sertifikaat. Wêr't de tsjinner ek in brûkersnamme en wachtwurd ferifiearret en dy namme yn 'e mienskiplike namme mappet, moat it bestân ynstee oerienkomme mei de autentisearre brûkersnamme. In mismatch lit in map fol leauwensweardige bestânnammen efter dy't nea keazen wurde.

Lêzen is de oare helte. De daemon lit meastal foarrjochten falle nei it starten, dus it fermindere akkount hat lêstagonk ta de map en elke ynfier deryn nedich. Klanten meie har eigen ynfier net oanmeitsje kinne fia hokker skriuwber paad dan ek, want selsbetjinningstalitting docht it meganisme hielendal te non. Kontrolearje de mount- en dielrjochten en net allinnich de bestânsmodus, om't in map dy't foar ien akkount sletten liket foar in oare iepen wêze kin. Befêstigje dan hokker akkount it draaiende proses wier brûkt, ynstee fan hokker akkount it unit-bestân neamt. Dy twa binne itselde allinnich as neat oars se feroare hat.

Observearje wegering, talitting en weromlûken apart

Probearje in identiteit dy't by de tsjinst heart en befêstigje dat it ferbynt. Probearje in jildich sertifikaat sûnder ynfier en befêstigje dat it wegere wurdt. Probearje in identiteit dy't ta de oare tsjinst talitten is en befêstigje dat it hjir net talitten wurdt. Skriuw de tsjinsteksimplaar en de effektive identiteit njonken elk resultaat, want in resultaat sûnder dy kontekst kin nimmen oars werommeitsje.

Weromlûken is in aparte operaasje fan werropping. It bewurkjen fan in talittingsbestân hellet ien tsjinstrjocht fuort wylst de identiteit oeral oars jildich bliuwt, wylst in kompromittearre kaai de werroppingsreaksje fan 'e organisaasje ferget. Beslút foarôf wat der bart mei sesjes dy't al iepen binne, want noch in mapbewurking noch in werroppingslist einiget se op himsels.

Talitting is ek mar de earste doar. By in tsjinst komme seit neat oer de subnetten, databanken of behearinterfaces dêrefter, en dat boarnenbelied moat apart skreaun en test wurde.