OpenVPN nang walang sertipiko ng kliyente: patakaran ng server, hindi profile

Binubura mo ang mga linyang sertipiko at susi, ibinibigay ang profile, at nabibigo pa rin ang koneksyon na may error sa sertipiko. Ang profile ay hindi kailanman ang bagay na nagpapatupad ng pangangailangang iyon. Ang server ang nagpapasya kung sapilitan ang sertipiko ng kliyente, at walang pagbabago sa panig ng kliyente ang nakikipag-usap upang alisin iyon. Kaya ang lunas ay pagbabago sa patakaran ng server, na ginawa nang sadya, kasama ang lahat ng umaasa rito na na-update sa parehong pagdaan.

Ang profile ay hindi ang patakaran

Ang Community OpenVPN 2.6 ay may kasamang sapilitang mga sertipiko ng kliyente, dahil ang verify-client-cert ay default na require. Ang pagtatakda nito sa none ang pumipigil sa paghingi ng sertipiko at nagpapasa ng pagpapatunay ng kliyente sa alinmang kaayusan ng username at password na pinapatakbo na ng server. Ang mas lumang mga gabay ay umaabot sa client-cert-not-required, ang lumang baybay ng parehong ideya, kaya gamitin ang direktiba na dokumentado ng naka-install na bersyon mo. Sa alinmang paraan, ang pagbabago ay nangyayari sa server, at walang profile ng kliyente ang makagawa nito.

Ang bahagi sa ibaba ay ang buong pagbabago sa panig ng server, at sa sarili nito ay hindi gumaganang konfigurasyon ng pagpapatunay. Tinatanggal ng verify-client-cert none ang pangangailangan sa sertipiko, habang ginagawang identity ng username-as-common-name ang pangalan ng account na nakikita ng mga susunod na callback at ng mga file bawat kliyente. Wala sa mga linya ang nagsusuri ng password, kaya kailangan pa ring may verifier.

verify-client-cert none
username-as-common-name

Ang verifier na iyon ay isang plugin o script na pinapatakbo ng auth-user-pass-verify, at kailangan nitong naroon bago maging makabuluhan ang alinman sa mga linyang nasa itaas. Ang pagbaliktad ng pagkakasunod-sunod ay nagbibigay sa iyo ng window kung saan hindi humihingi ng sertipiko ang server at hindi nagsusuri ng account.

Ano ang patuloy na nagpapatunay sa server

Ang pagtatapon ng sertipiko ng kliyente ay hindi pagtatapon ng TLS. Pinapanatili ng server ang sertipiko at susi nito, at pinapanatili ng kliyente ang tiwala sa CA at mga pagsusuri sa hostname na pumipigil dito sa pakikipag-usap sa isang manloloko. Ang pag-alis ng remote-cert-tls server o ng bundle ng CA dahil wala nang sertipiko ang kliyente ay isang karaniwan at malubhang maling pagbasa, at ang sanggunian sa 2.6 ay malinaw na independiyente ang dalawang direksyon. Ang isa ay nagpapatunay ng server sa kliyente; ang isa ay nagpapatunay ng kliyente sa server.

Ang isang profile ay maaari ring magdala ng bloke na tls-auth o tls-crypt. Iyon ay isang pinagsasaluhang susi ng control channel na may sariling siklo ng pamamahagi at pag-ikot, kaya ang isang file na walang linyang sertipiko o susi ay hindi awtomatikong ligtas na ilathala. Ituring itong lihim hanggang mabasa mo ito.

Ang isang file ng sertipiko na kinopya mula sa gumaganang profile ay walang pinatutunayan sa sarili nito; ang pagmamay-ari ay nangangahulugang hawak ang pribadong susi na tumutugma rito, na sinusuri ng isang deployment na pinatotohanan ng sertipiko. Ang isang file na naglalaman ng sertipiko ay hindi file na maaaring gamitin sa pagpapatunay.

Ano ang dapat gawin ng verifier

Kapag tinanggal ang pangangailangan sa sertipiko, nakasalalay ang lahat sa verifier: isang plugin, o isang script na pinapatakbo ng auth-user-pass-verify. Dapat nitong tanggihan ang mga di-wastong kredensyal, tanggihan ang mga naka-disable o hindi karapat-dapat na account, at mabigo nang sarado kapag hindi nito maabot ang backend nito. Ang username-as-common-name ay madalas na pinagana sa tabi nito, at binabago nito ang identity na nakikita ng mga susunod na callback at ng mga file ng konfigurasyon bawat kliyente. Hindi nito binibigyang-katibayan ang isang password, at hindi nito ginagawang karapat-dapat ang isang hindi karapat-dapat na account. Magkahiwalay ang mga gawaing iyon, at ang paghaluin ang mga ito ang paraan ng isang migrasyon na pumasa sa pagsubok ng masayang landas at mabigo sa unang tunay na insidente nito.

Subukan ang mga negatibong kaso nang kasing-ingat ng positibong kaso. Ang isang profile na nagpapakita ng prompt ng password ay nagpapatunay lamang na kayang gumuhit ng prompt ng kliyente, samantalang ang isang server na tumatanggap ng maling password ay nagpapatunay ng mas malubhang bagay. Magdagdag ng naka-disable na account at nag-expire na kredensyal sa test set, hindi lamang masamang password.

Palitan ang patakaran, profile at mapping nang sabay

Ugnayin ang tatlong bagay: ang direktiba ng server, ang profile ng kliyente, at ang mapping ng identity bawat kliyente. Palitan sila nang hiwalay at nabibigo ang mga kliyente bago ang pagpapatunay, o kumokonekta sa ilalim ng pangalang hindi inaasahan ng administrator, na mas masama dahil mukhang tagumpay ito. Ang isang koneksyong nagtagumpay sa ilalim ng maling identity ay mas mahirap mapansin kaysa sa isang nabibigo.

Panatilihin ang dalawang test account para sa landas na ito, isang wasto at isang kilalang masama, at gamitin ang pareho pagkatapos ng anumang pagbabago sa verifier. Ang wastong account ay nagpapatunay ng masayang landas at ng mapping ng identity; ang masama ay nagpapatunay na gumagana pa rin ang pagtanggi. Wala sa mga pagsubok ang nagsasabi sa iyo ng anuman tungkol sa mga tuntunin ng pagiging karapat-dapat, kaya magdagdag ng account na dapat tanggihan dahil sa mga dahilang pampatakaran kung mayroon ang deployment. Patakbuhin ang tatlo pagkatapos ng bawat pagbabago, dahil ang isang verifier na nagsisimulang tumanggap ng lahat ay kamukhang-kamukha ng isang gumaganang pag-login.

Itala kung aling mga paraan ng pagpapatunay ang aktuwal na tinatanggap ng server, hindi ang iminumungkahi ng profile. Sinasagot ng talaang iyon ang tanong na paulit-ulit itinatanong ng mga tao, kung sino ang maaaring kumonekta sa serbisyong ito. Nabubuhay din ito nang mas matagal kaysa sa susunod na administrator, na kung hindi ay muling matutuklasan ito mula sa isang packet capture.