I-pause ang isang OpenVPN client: bakit maling pingga ang pagbawi

Ang pag-pause sa access ng isang kliyente at ang tuluyang pag-alis nito ay mukhang isang gawain hanggang subukan mong ibalik ang isa sa kanila. Ang pagbawi sa sertipiko ay nagsusulat ng talaan na itinuturing ng server na pangwakas, at ang pagbaliktad nito ay nangangahulugang manu-manong pag-edit sa database ng naglabas. Ang pagbagsak sa buhay na tunel ay isang utos sa pamamahala na walang binabago sa tiwala. Piliin ang pingga sa pamamagitan ng pagtatanong kung mapagkakatiwalaan pa ang susi, hindi sa pagtatanong kung gaano kadesperado ang kahilingan.

Ang paniniwala: ang binawi at nasuspinde ay pareho

Isang kontraktor ang ipinag-pause ng isang linggo at ang reaksiyon ay pagbawi, dahil ang pagbawi ay tunog ng pagpatay ng isang bagay. Mukhang maayos, tumatagal ng sampung segundo, at nag-iiwan ng pag-edit sa database bilang tanging daan pabalik. Ang reaksiyon ay nauunawaan at mas malapit ito sa pagsunog ng pasaporte kaysa sa pagsara ng pinto. Ang naka-pause na aparato at ang nakompromisong susi ay kailangan ng magkaibang pagtrato, at isa lamang sa kanila ang mura upang ibalik.

Ang pagkakaiba ay nasa kredensyal at hindi sa tao. Ang susi na nasa tamang mga kamay pa ay maaaring i-pause at ipagpatuloy nang walang anumang pagkawala ng tiwala. Ang susi na maaaring nakopya ay hindi dapat ibalik kailanman, dahil ang pagbalik ay nagsasabing wala ang kopya.

Isulat ang sagot bago hawakan ang alinman sa dalawang sistema. Kung hindi mo masasabi kung nakalantad ang susi, ang konserbatibong sagot ay pagpapalit.

Ibagsak ang buhay na sesyon gamit ang interface ng pamamahala

OpenVPN ay nagbibigay ng interface ng pamamahala na maaaring maglista ng mga sesyon at pumatay ng isa sa kanila sa pamamagitan ng karaniwang pangalan. I-enable ito sa localhost, ilayo sa pampublikong interface, at ipadala ang utos ng pagpatay kapag ang isang sesyon ay dapat mawala ngayon. Ang utos ay nagsasara lamang ng tunel na iyon, at ang bawat ibang kliyente ay patuloy na gumagana.

Ito ay tugon sa isang aktibong problema, hindi patakaran ng pagsuspinde. Ang parehong profile ay maaaring muling kumonekta sa loob ng isang minuto, dahil walang nagbago sa kredensyal nito. Gamitin ito kapag kailangang umalis ng sesyon at ang pangmatagalang desisyon ay ginagawa pa lamang.

Tiyakin na ang sesyon ay konektado bago mo ito patayin, upang hindi ka maghabol sa kliyenteng hindi kailanman kumonekta. Ang utos ng estado sa ibaba ay naglilimbag ng kung ano ang konektado ngayon.

printf 'status 2\nquit\n' | nc 127.0.0.1 7506
printf 'kill kiosk-14\nquit\n' | nc 127.0.0.1 7506

Kung ang pagpatay ay nag-uulat na walang ganoong kliyente, ang karaniwang pangalan sa sertipiko ay hindi ang string na iyong tinype. Basahin ang output ng estado sa halip na ang pangalan ng file ng profile.

Ano ang tunay na kinokontrol ng CRL

Hindi tumitingin ang server sa flag ng pagbawi na nakaimbak sa sertipiko. Binabasa nito ang listahan ng pagbawi ng mga sertipiko na pinangalanan sa crl-verify sa bawat bagong koneksyon, at tinatanggihan ang sertipikong ang serial number ay nasa listahang iyon. May dalawang kahihinatnan, at pareho silang mahalaga sa operasyon. Ang file ay dapat mabasa ng account na binabaan ng server ng mga pribilehiyo nito, at ang kliyenteng nakakonekta na ay patuloy na tumatakbo hanggang muling kumonekta.

Ang ikalawang kahihinatnan ay nagulat sa mga tao sa panahon ng insidente. Ang pagbawi sa sertipiko ay hindi nagsasara sa tunel na gumagamit nito ngayon. Ipares ang pagbawi sa pagpatay sa pamamahala kung ang sesyon ay dapat magwakas agad, at ituring ang dalawang aksyon bilang magkahiwalay na hakbang sa manwal.

Siyasatin ang listahan upang makita kung ano ang tunay na ipapatupad ng server, sa halip na magtiwala sa timestamp ng huling file na kinopya mo. Ang bilang ng mga serial number ang bahaging mahalaga.

openssl crl -in /etc/openvpn/server/crl.pem -noout -text | sed -n '1,14p'
ls -l /etc/openvpn/server/crl.pem

Ang listahang walang entry at ang listahang may tamang entry ay magkamukha sa listahan ng direktoryo, kaya sulit na ilimbag ang bilang ng mga serial number. Ang linya ng mga pahintulot ay kasinghalaga, dahil ang file na hindi mabasa ng daemon ay nagdudulot ng pagkabigo na mukhang tinanggihang kliyente.

Ibalik ang isang talaan, nang maingat

Ang pagbalik sa isang sertipiko ay nangangahulugang baliktarin ang isang talaan sa database ng paglabas at maglathala ng bagong listahan. Ang easy-rsa 3 ay nagtatago ng database na iyon bilang index.txt sa ilalim ng direktoryo ng PKI, habang ang mas lumang mga layout ay gumamit ng ibang kaayusan. Ang isang hilera ay nagsisimula sa titik ng estado at petsa ng pag-expire. Ang binawing hilera ay naglalagay ng timestamp para sa pagbawi bago magpatuloy sa serial number, pangalan ng file ng sertipiko at natatanging pangalan. Ang pagbabalik ng hilera sa puwesto ay nangangahulugang burahin ang timestamp na iyon at baliktarin ang titik, habang hinahayaang payapa ang lahat ng iba.

Gumawa muna ng backup ng file, at gawin ang pag-edit bilang script sa halip na mag-type sa isang text editor. Ang typo na nagbabago kung ilang field ang dala ng isang hilera ay sumisira sa paglabas para sa bawat sertipikong idinagdag pagkatapos. Iyon ang dahilan upang i-automate ang pagbabago at kopyahin ang file bago ito hawakan.

Ang ikalawang pagbawi ng parehong pangalan ay madalas ding nabigo, dahil inilipat ng unang pagtakbo ang sertipikong iyon at ang susi nito palabas ng mga direktoryo kung saan inaasahan ng tool na makita ang mga ito. Hindi na mahahanap ng tool ang ipinag-utos na bawiin, at ang mensahe ng error ay hindi laging malinaw kung bakit.

cp /etc/easy-rsa/pki/index.txt /root/index.txt.$(date +%F-%H%M)
grep -c '^R' /etc/easy-rsa/pki/index.txt
easyrsa gen-crl

Ilathala ang bagong listahan, ayusin ang pagmamay-ari nito, at gawing basahin ito ng server. Ang muling pag-load ay sapat sa karamihan ng mga instalasyon, ngunit ang kumpirmasyon ay dapat magmula sa isang sariwang koneksyon, dahil ang umiiral na sesyon ay hindi na muling nag-verify ng anuman.

Suriin kung aling pingga ang nararapat sa kaso

Itanong ang nag-iisang tanong na nagpapasya sa buong manwal: ang pribadong susi ba ay nasa lugar pa rin kung saan ito dapat naroon. Kung oo, ang pagpatay sa sesyon at ang dokumentadong pag-pause ay sumasaklaw sa kaso at walang permanenteng talaan na naiiwan. Kung hindi, ang tanging ligtas na sagot ay isang bagong susi habang ang lumang sertipiko ay naiwang binawi.

Pagkatapos ay i-verify ang resulta sa pamamagitan ng pagtatangkang kumonekta at hindi sa pagkakaiba ng configuration. Sinasabi ng pagkakaiba kung ano ang nilayon mo, at sinasabi ng koneksyon kung ano ang ipinapatupad ng server.

openssl crl -in /etc/openvpn/server/crl.pem -noout -text | grep -c 'Serial Number'
printf 'status 2\nquit\n' | nc 127.0.0.1 7506

Kapag ang naibalik na kliyente ay kumonekta at lumitaw sa output ng estado, gumana ang pag-edit sa talaan. Kapag ang binawing kliyente ay tinanggihan at pinangalanan ng log ang CRL, gumana ang pagbawi. Anumang nasa pagitan ay problema sa pahintulot o muling pag-load, at sulit itong ayusin bago dumating ang susunod na kahilingan.