Ang dalawang customer sa isang host ay parang isa pang server block at pangalawang port. Nagiging ibang proyekto ito kapag inilista mo ang lahat ng aktwal na pag-aari ng customer: isang listener, isang tunnel pool, isang identity, mga trust file, mga ruta at isang iskedyul ng pagpapawalang-bisa. Laktawan ang isa sa mga ito at tahimik na namamana ng pangalawang customer ang isang bahagi ng una. Gumawa ng card para sa bawat customer at punan ito bago kumonekta ang unang client.

Maglaan ng kumpletong resource card para sa bawat customer

Ireserba ang buong set nang sabay: pampublikong port, tunnel subnet, path ng configuration, destinasyon ng log, pangalan ng service instance at device. Ang pagbibigay ng pangalan sa kanila bilang isang grupo ang pumipigil sa klasikong kopya ng gumaganang file na naglalaman pa rin ng pool o interface ng unang customer. Ang mga halaga ay halimbawa, hindi nakareserbang port, kaya tingnan kung ano ang ginagamit na ng host. Ang serbisyong nagsisimula ay hindi katulad ng customer na kumpleto.

Itago ang card sa tabi ng configuration at i-update ito sa tuwing may magbabago ng halaga. Ang dokumentasyong lumalayo sa katotohanan ay mas masama kaysa wala.

Itago ang trust material sa loob ng bawat customer

Ang hiwalay na issuing authority sa bawat customer ay nagpapadali sa pag-unawa sa hangganan at naglalayo sa signing key mula sa host na nakaharap sa internet. Gumagana rin ang shared root, ngunit ang karaniwang anchor ay hindi ginagawang isang membership domain ang dalawang serbisyo. Magpasya kung aling chain ang tinatanggap ng bawat listener at aling client identity ang pinapayagan nito, pagkatapos isulat ang dalawa. Huwag tanggalin ang mga certificate mula sa chain sa pamamagitan ng trial and error hanggang may kumonekta.

Ang sariling private key ng server ay nabibilang sa protektadong file sa bawat customer, hindi sa template directory na kinokopya kasama ng configuration.

Ihiwalay ang mga network gayundin ang mga proseso

Dalawang proseso sa dalawang port ay nagbabahagi pa rin ng host at routing table maliban kung ihiwalay mo sila. Kumpirmahin kung ano ang nakikinig bago magtiwala sa disenyo.

ss -lunp | grep -E '1194|1195'
openssl verify -CAfile customer-a/ca.crt customer-a/client.pem

Ipinapakita ng pagsusuri ng listener kung aling proseso ang may-ari ng bawat pampublikong port, at ipinapakita ng verification kung ang certificate ng client ay nag-chain sa nilalayong anchor. Wala sa mga output ang nagpapatunay na hindi maabot ng client ng A ang subnet ng B, kaya tukuyin ang patakaran ng pinagmulan at destinasyon, mga return route at anumang sadyang ibinahaging serbisyo. Ang mga network namespace o container ay naghihiwalay ng routing context at nagpapababa ng aksidenteng paghahalo, ngunit ang mga ito ay hindi isang kumpletong tenant boundary nang mag-isa. Pumili ng mas malakas na isolation mechanism kapag kailangan ito ng threat model.

Ihatid ang pagpapawalang-bisa bago ang turnover

Ang deployment ng certificate ay hindi kumpleto hanggang ang pagpapawalang-bisa ay may delivery path. Suriin ang issuer at validity window ng CRL bilang bahagi ng onboarding.

openssl crl -in customer-a/crl.pem -noout -lastupdate -nextupdate
systemctl status openvpn@customer-a

Ang inspeksyon ng CRL ay nag-uulat kung kailan inilabas ang listahan at kailan ito mag-eexpire, at kinukumpirma ng status ng serbisyo na tumatakbo ang instance na nagbabasa nito. I-refresh ang listahan ayon sa iskedyul ng issuing policy kahit walang bagong na-revoke, dahil ang expired na CRL ay maaaring tumanggi sa bawat client. I-publish ang kumpletong file sa halip na hayaang makatagpo ang mga mambabasa ng partial write, at i-validate ang signature bago ang deployment. Itala kung sino ang may-ari ng issuance, operasyon ng endpoint at retirement, upang ang pagpatay sa customer A ay hindi makagambala sa B.

Pagkatapos, patakbuhin ang acceptance pair: naaabot ng pinapayagang client ang sarili nitong serbisyo, at ang credential ng A ay tinatanggihan ng listener ng B. Iyon ang hangganan na ipinahayag bilang test.

Kaugnay na mga artikulo