Binawi na kliyente ay nakakonekta pa rin: hindi kailanman dumating ang listahan
Ang pagbawi ay input sa pagpapatunay ng sertipiko, hindi utos na nagtatapos ng sesyon. Ihambing kung paano nakikita ng bagong koneksyon at tumatakbong tunnel ang listahan.
Ang pagbawi ay hindi kailanman pumapasok sa tumatakbong tunnel upang tanggalin ang sesyon. Ang listahan ay input sa pagpapatunay ng sertipiko at binabasa sa pagpapalitan ng control channel na nagbubukas ng sesyong TLS. Ang nag-iisang katotohanang ito ay nagpapaliwanag sa dalawang sorpresa: nakakonekta muli ang binawing kliyente dahil hindi kailanman nakarating ang listahan sa tagapagpatunay, at nabubuhay ang umiiral na sesyon dahil walang sinumang muling nagpatunay ng anuman.
Ang listahan ay input, hindi aksyon
Sa pagtatatag ng sesyon, pinapatunayan ng server ang sertipiko ng kliyente laban sa mga angkla ng pagtitiwala nito, at idinadagdag ng direktiba ng pagbawi ang paghahanap sa listahan sa desisyong iyon. Nagaganap ang pagsusuri sa server, kaya hindi makikita ng kliyente na binawi ang sertipiko nito at patuloy na nag-aalok ng pareho. Kaya ang profile na nakakonekta pa rin ay nagpapatunay lamang na tinanggap ng isang tagapagpatunay ang kadena, hindi na nabigo ang pagbawi.
Ang listahan mismo ay isang nilagdaang bagay na may petsa ng paglabas at petsa ng susunod na pag-update. Ang walang kaugnayang listahan, ang nilagdaan ng ibang awtoridad o ang lampas na ang susunod na pag-update ay hindi kapalit ng kasalukuyan, at kung tinatanggihan o tahimik na tinatanggap ang lumang listahan ay depende sa deployment.
Bagong koneksyon laban sa tumatakbong sesyon
Sinusuri ang pagbawi kapag itinatag o muling nakipag-usap ang sesyon, hindi laban sa data channel sa bawat packet. Ang kliyenteng nakakonekta na ay may mga susi ng trapiko, kaya nagpapatuloy itong nagpapadala ng packet matapos lumitaw ang sertipiko nito sa listahan. Ang default na pagitan ng muling pakikipag-usap ay sinusukat sa oras, kaya ang na-update na listahan ay maaaring magkabisa para sa mga bago habang nananatili ang tumatakbong tunnel.
| Situation | What the list does | When it applies |
|---|---|---|
| Fresh connection | Blocks the handshake | At verification, immediately |
| Renegotiation | Blocks the new exchange | At the next renegotiation interval |
| Established data channel | Nothing | Until the session ends |
Ang agarang pagpapatupad ay nangangailangan ng sinadyang aksyon at hindi lamang ang listahan. Ang pag-restart ng serbisyo ay pinipilit ang bawat kliyente na kumonekta muli, habang ang pagtatapos ng isang sesyon sa management interface ay iniiwan ang iba na hindi nagalaw. Pumili ng isa bawat insidente at itala kung alin ang ginamit. Magkaiba ang saklaw ng epekto ng dalawang opsyon, at iyon ang tunay na desisyon.
Ihatid ang file na talagang binabasa ng tagapagpatunay
Ang listahan ay dapat buuin mula sa talaan ng awtoridad at pagkatapos ay kopyahin sa bawat makina na nagpapatunay ng sertipiko. Ang pagbuo nito sa CA host at hindi kailanman pag-install sa server ang pinakakaraniwang pagkabigo, at mukha itong eksaktong sirang feature ng pagbawi.
ca ca.crt
cert server.crt
key server.key
crl-verify /etc/openvpn/crl.pem
Dalawang detalye ang nagtatakda kung talagang binabasa ang file. Ang relatibong landas ay nireresolba laban sa configuration directory, kaya ang kopyang naiwan sa home ng operator ay maaaring hinding-hindi mahanap. At ang daemon ay karaniwang bumibitaw ng mga pribilehiyo pagkatapos magsimula, kaya ang runtime account ay nangangailangan ng pahintulot sa paghahanap sa bawat parent directory at pahintulot sa pagbasa sa file. Suriin ang dalawa gamit ang runtime account at hindi root, kung hindi ay pinatutunayan ng pagsubok ang maling bagay.
Sa mga systemd host, ang hardened unit ay maaari ring magtago ng landas, sa read-only na view o protektadong system directory. Mula sa loob ng serbisyo ay hindi ito makikilala sa nawawalang file, kaya suriin ang mga paghihigpit ng unit bago maghanap ng error sa pahintulot. Basahin ang unit file bago sisihin ang mode ng file.
Kumpirmahin sa server, hindi sa kliyente
Pinapangalanan ng log ng server ang nangyari: pagbubukas ng listahan, pag-load nito o nabigong pagpapatunay kasama ang binawing serial number. Ang kliyente ay nag-uulat lamang ng pangkalahatang pagkabigo sa handshake, kaya ang mga log ng kliyente ay masamang lugar upang hanapin ang desisyon sa pagbawi.
Patunayan gamit ang bagong pagtatangka mula sa binawing profile at pagkatapos ay huminto. Ang matagumpay na koneksyon mula sa profile na iyon ang senyales upang suriin ang landas ng file at runtime account, hindi upang ipagpalagay na mali ang listahan. Itago ang matagumpay na pagtatangkang iyon bilang acceptance test, at huwag bilangin ang muling pagkonekta na hindi mo naobserbahan.
Ano ang walang binabawi
Ang pagtanggal ng profile mula sa laptop, pag-alis ng sertipiko mula sa kliyente o pagsabi sa gumagamit na huminto sa pagkonekta ay walang binabago sa server. Nananatiling wasto ang sertipiko hanggang maitala ng awtoridad ang pagbawi at mabasa ng tagapagpatunay ang resultang listahan.
Kaya sulit isulat ang kadena: itala ang pagbawi, buuin at lagdaan ang listahan, ipamahagi ang eksaktong file na iyon, at kumpirmahin na mababasa ito ng service account. Bawat kawing ay maikli, at ang anumang kulang ay nag-iiwan sa binawing kliyente na masayang nakakonekta. Ang checklist na may apat na linya ay higit sa palagay na walang kahit isa.