Pinagsasaluhang CA, magkakahiwalay na pinto: isang serbisyo kada file ng pagtanggap

Ang sertipikong bina-validate laban sa pinagsasaluhang awtoridad ay pumasa sa pagsubok ng tiwala, hindi sa pagsubok ng pagiging miyembro. Kadalasang pinagsasama ang dalawang desisyong ito dahil pareho silang nangyayari sa oras ng koneksyon, at nananatiling di-nakikita ang pagkasama hanggang may taong hindi dapat naroon sa isang serbisyo ang tanggapin dito. Ang lunas ay hindi pangalawang awtoridad; ito ay pangalawang desisyon, ginawa kada serbisyo at naitala kung saan ito binabasa ng daemon. Paghiwalayin ang dalawa at mawawala ang karamihan ng kalituhan sa larangang ito.

Walang sinasabi ang pinagkakatiwalaang chain tungkol sa pagiging miyembro sa serbisyo

Maaaring tanggapin ng dalawang serbisyo ang parehong hierarchy ng naglalabas at magkaroon pa rin ng magkaibang populasyon. Isang laptop ang kabilang sa una at hindi dapat makarating sa pangalawa, habang ang ibang kliyente ng parehong hierarchy ay talagang kabilang doon. Ang pag-alis ng awtoridad sa serbisyong iyon ay magsasara sa lahat ng lehitimong gumagamit nito, kaya ang gawain ay pagtanggap, hindi tiwala.

Nakakatulong ang pag-isip ng dalawang kandado sa isang pinto. Binubuksan ng sertipiko ang panlabas na kandado, at binubuksan ng desisyon kada serbisyo ang panloob; wala sa dalawa ang pumapalit sa isa. Ang serbisyong may panlabas na kandado lamang ay hindi nagpapatupad ng pagiging miyembro, nagpapatunay lamang ito ng pagkakakilanlan. Isulat ang dalawang desisyon bago baguhin ang anuman, dahil ang patakarang umiiral lamang sa anyo ng gumaganang koneksyon ay hindi maaaring i-audit. Ang sumusunod ay tungkol sa panloob na kandado.

Gawing pintuan ng pagtanggap ang mga opsyonal na pag-override

Ang direktoryo ng konfigurasyon ng kliyente ay karaniwang kaginhawahan: pinapalitan ng mga file dito ang mga setting ng kliyenteng pinapangalanan nila, at ang kliyenteng walang file ay tumatakbo lamang sa mga default ng server. Isang direktiba ang nagpapalit ng kaginhawahang iyon sa pintuan, kaya ang nawawalang file ay nangangahulugang tinatanggihan ang koneksyon.

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

Ang edisyon ng komunidad ng OpenVPN 2.6 ccd-exclusive ay nagdodokumento sa pahina ng manwal nito ng eksaktong kundisyong ito, at ang paghahanap ng pinangalanang file ay nakasalalay sa epektibong pagkakakilanlan ng kliyente. Maaaring iba ang ibang build at server na pinamamahalaan ng produkto, kaya tiyakin ang naka-install na bersyon bago umasa sa parehong semantika sa ibang lugar.

Ituring na halimbawa ang landas sa itaas at suriin ang aktwal na naka-deploy na layout sa halip na gumawa ng direktoryong inimbento ng isang gabay. Iwanan ang mga umiiral na pagsusuri ng sertipiko, pagsusuri ng pagkakakilanlan ng server at pagpapatunay ng account kung ano sila dati, dahil nagdadagdag ang fragment ng kundisyon at wala itong tinatanggal. Ihanda ang pagbabago bago ang produksyon, dahil ang pagtangging itinaas sa maling punto ay mukhang pagkabigo ng sertipiko at nagpapadala ng imbestigasyon sa awtoridad. Pagkatapos ay tiyakin na ang linya ng log para sa tinanggihang kliyente ay nagpapangalan ng nawawalang file ng konfigurasyon at hindi ang chain.

Isang direktoryo kada serbisyo, hindi isang pinagsasaluhang listahan

Ang pagiging miyembro ay pag-aari ng serbisyong nagpapatupad nito, kaya ang bawat serbisyo ay may sariling direktoryo at sariling mga file. Ang pagturo ng dalawang serbisyo sa isang listahan ay nagpapabahagi sa kanila ng pagiging miyembro sinasadya man ito ng sinuman o hindi, at mahirap i-trace pabalik ang resulta sa isang desisyon. Ang pinagsasaluhang awtoridad ay maaaring manatiling pinagsasaluha; ang mga file ng pagtanggap ay hindi maaari. Ang paghihiwalay sa kanila ay nangangahulugan din na ang pagkakamali sa isang serbisyo ay hindi makakapagpalawak ng iba nang tahimik.

Ang entry na DEFAULT ang kaso na nakakalito sa mga tao. Nagbibigay ito ng fallback na setting kapag walang nahanap na pinangalanang file, ngunit hindi ito ang pinangalanang file na hinihingi ng pintuan, kaya hindi nito matatanggap ang isang kliyente nang mag-isa. Subukan ang kliyenteng wala talagang entry at tiyakin ang pagtanggi; kung natanggap ang kliyenteng iyon, ginagamit ang fallback at ccd-exclusive ay walang bisa sa pagkakataong iyon.

Ang epektibong pagkakakilanlan ang nagpapasya kung aling file ang babasahin

Ginagamit ng paghahanap ang pagkakakilanlang aktwal na pinatunayan ng kliyente, na karaniwang ang common name ng sertipiko. Kapag sinusuri rin ng server ang username at password at ini-map ang pangalang iyon sa common name, dapat tumugma ang file sa pinatunayang username sa halip. Ang hindi pagtutugma ay nag-iiwan ng direktoryong puno ng kapani-paniwalang pangalan ng file na hindi kailanman pinipili.

Ang pagbasa ang kabilang kalahati. Karaniwang binibitawan ng daemon ang mga pribilehiyo pagkatapos ng pagsisimula, kaya kailangan ng pinababang account ang access sa pagbasa sa direktoryo at bawat entry dito. Hindi dapat magawang gumawa ng sariling entry ang mga kliyente sa anumang landas na maisusulat, dahil sinisira ng self-service na pagtanggap ang buong mekanismo. Suriin ang mga pahintulot sa mount at share at hindi lamang ang mode ng file, dahil ang direktoryong mukhang sarado sa isang account ay maaaring bukas sa iba. Pagkatapos ay tiyakin kung aling account ang aktwal na ginagamit ng tumatakbong proseso, hindi kung aling account ang binabanggit ng unit file. Pareho lamang ang dalawa kapag wala nang ibang nagbago sa kanila.

Obserbahan nang hiwalay ang pagtanggi, pagtanggap at pagbawi

Subukan ang pagkakakilanlang kabilang sa serbisyo at tiyaking kumokonekta ito. Subukan ang valid na sertipikong walang entry at tiyaking tinatanggihan ito. Subukan ang pagkakakilanlang tinanggap sa ibang serbisyo at tiyaking hindi ito tinatanggap dito. Itala ang instance ng serbisyo at ang epektibong pagkakakilanlan sa tabi ng bawat resulta, dahil ang resultang walang kontekstong iyon ay walang ibang makakagawa muli.

Ang pag-alis ay hiwalay na operasyon sa pagbawi. Ang pag-edit ng file ng pagtanggap ay nag-aalis ng isang karapatan sa serbisyo habang nananatiling valid ang pagkakakilanlan sa lahat ng iba pang lugar, samantalang ang kompromisadong susi ay nangangailangan ng tugon ng pagbawi ng organisasyon. Magpasya nang maaga kung ano ang mangyayari sa mga sesyong nakatayo na, dahil ni ang pag-edit ng direktoryo ni ang listahan ng pagbawi ay hindi ang nagtatapos sa kanila nang mag-isa.

Ang pagtanggap ay unang pintuan lamang. Ang pagsali sa isang serbisyo ay walang sinasabi tungkol sa mga subnet, database o management interface sa likod nito, at ang patakarang iyon sa resource ay dapat isulat at subukan nang hiwalay.