Kapag ang isang laptop ay nasa mesa ng pag-aayos nang isang linggo, ang karaniwang reaksiyon ay alisin ang sertipiko nito mula sa CA. Ang rekord na iyon ay ledger ng issuer, hindi pansamantalang switch ng access. May mekanismo na ang OpenVPN para sa bawat client upang tanggihan ang koneksyon, at ang paggamit nito ay nagpapanatili sa kasaysayan ng CA. Magkaibang tanong ang sinasagot ng dalawang kontrol, at ang pagsasama nila ay lumilikha ng trabaho kapag bumalik ang aparato.

Dalawang rekord, dalawang magkaibang gawain

Itinatala ng database ng CA kung ano ang pinirmahan ng issuer at kung ano ang binawi nito mamaya. Tinatanong ito ng mga daloy ng pagbawi at ng lahat ng bumabasa ng CRL o ng sarili nitong kopya ng ledger. Ang tuntunin ng access ay nabubuhay sa server at nalalapat sa mga koneksyong tinatanggap ng server na iyon.

Ang pagbura ng rekord ng paglabas ay hindi mapagkakatiwalaang nagbabawi ng sertipiko, at sinisira nito ang kasaysayang nakasalalay sa susunod na pagbawi o audit. Ang kontrol sa panig ng server ay mas makitid at mababalik. Isulat ang pagkakaiba sa tala ng pagbabago upang hindi maghanap ang susunod na tao ng pagbawing hindi nangyari.

Ilagay ang disable directive sa tamang file

Para sa isang community server na gumagamit ng partikular na configuration ng client, tinatanggihan ng dokumentadong disable directive ang isang napiling client. Nabibilang ito sa file ng client na iyon sa ilalim ng aktibong client-config-dir, hindi sa pangunahing configuration ng server. Tiyakin ang direktoryo na aktwal na ginagamit ng tumatakbong daemon, pagkatapos tiyakin ang pagkakakilanlang pumipili ng file. Ang file na pinangalanan sa maling common name ay mukhang tama at hindi kailanman binabasa.

disable

Mahalaga ang mga pagpipilian sa mapping dito. Binabago ng mga opsyon tulad ng username-as-common-name kung aling pagkakakilanlan ang ginagamit ng paghahanap, kaya ang file na pinangalanan sa subject ng sertipiko ay maaaring hindi ang inilalapat. Basahin ang sanggunian ng OpenVPN para sa naka-install na bersyon sa halip na ipagpalagay na wasto ang isang directive sa lahat ng konteksto.

Ihiwalay ang bagong pagtanggap sa mga aktibong sesyon

Ang pagtanggi sa susunod na handshake ay hindi nagtatapos sa isang tunnel na nakatayo na. Kung kailangang idiskonekta ang aparato ngayon, gamitin din ang awtorisadong landas ng pamamahala ng sesyon ng server para sa partikular na sesyong iyon. Kung hindi, maaaring magpatuloy ang client hanggang sa kusang muling kumonekta, at ang pagsara ng takip ng laptop o paglabas sa client ay aksyon sa panig ng client na walang sinasabi tungkol sa server.

Tiyakin ang dalawang resulta: humihinto ang aktibong sesyon kapag gusto mo, at tinatanggihan ang bagong handshake. Ang saradong window ng client ay walang pinapatunayan tungkol sa patakaran ng server.

Kung walang sinusuportahang paraan ang deployment upang tapusin ang aktibong sesyon, itala ang puwang na iyon sa halip na mag-imbento ng isa. Ang naka-block na port sa client ay hindi katulad ng patakaran sa panig ng server.

Ang paghinto at kompromiso ay magkaibang pangyayari

Ang nawala o nanakaw na susi ay pangyayari ng pagbawi, at ang lokal na paghinto ng access ay hindi kapalit nito. Ang ibang server na nagtitiwala sa parehong CA ay hindi magbabahagi ng partikular na tuntuning ito ng client. Sundin ang proseso ng pagbawi at pagpapalit ng issuer at panatilihin ang database ng CA bilang awtoritatibong rekord. Ang pansamantalang paghinto, sa kabilang banda, ay nangangailangan ng dokumentadong dahilan at hakbang sa pagpapanumbalik.

Kapag naibalik ang access, alisin ang paghihigpit sa pamamagitan ng component na nagmamay-ari nito at tiyaking matagumpay ang bagong koneksyon. Itala rin ang landas ng linya ng disable, dahil maaaring tahimik itong ibalik ng susunod na pag-sync ng configuration. Itago ang paghinto, ang may-ari nito at ang petsa sa mga tala ng deployment, upang hindi makakita ang susunod na administrador ng walang paliwanag na linyang disable pagkalipas ng mga buwan.

Kaugnay na mga artikulo