Kwa nini cryptoapicert inashindwa katika OpenVPN 3 na Connect kwenye Windows

Unakili profaili ya OpenVPN 2 inayofanya kazi kwenye mteja mpya wa Windows, na cheti ambacho mteja wa zamani alijipatia mwenyewe hakitolewi tena. Mstari ulioifanya hiyo iwezekane ni kichaguo maalum cha Windows kinachomilikiwa na mteja wa Community 2, na programu mpya ni programu nyingine yenye njia tofauti ya vitambulisho. Profaili haijabadilika isipokuwa mstari huo mmoja, na ndiyo inayofanya tofauti kuwa ngumu kuona.

Tabaka tatu zinachanganywa katika ripoti hiyo: mteja wa Community, maktaba ya msingi na frontend ambayo mtu aliisakinisha. Ni moja tu kati yao iliyowahi kuelewa agizo hilo.

Chaguo hili linamaanisha nini pale linapokuwepo

Katika mteja wa Community OpenVPN 2 kwenye Windows, cryptoapicert inataja cheti ambacho mteja anapaswa kukipata katika hifadhi ya vyeti ya Windows badala ya faili. Ni urahisi maalum wa Windows, na inafanya kazi kwa sababu mteja huyo anajua jinsi ya kuorodhesha hifadhi na kukabidhi ufunguo unaotokana na hiyo kwa safu yake ya TLS. Kwa hivyo agizo ni sehemu ya lugha ya usanidi ya mteja huyo, si sifa ya itifaki ya OpenVPN. Hakuna kitu katika muundo wa uhamishaji kinacholibeba.

Nakili mstari huo huo kwenye programu nyingine na umenakili neno ambalo programu mpya inaweza kulichanganua, kulipuuza au kulikataa. Agizo si sifa ya itifaki, na hili hata si sifa ya kila mteja anayezungumza OpenVPN.

Maktaba ya msingi hutoa nini badala yake

OpenVPN 3 Core ni maktaba ambayo programu nyingine huiingiza, na inashughulikia vitambulisho vya nje kupitia API badala ya utafutaji wa hifadhi. Programu inayoiingiza hutoa mnyororo wa vyeti na baadaye humwomba maktaba kusaini kwa ufunguo wa nje, na maktaba huiita programu tena ili kufanya hivyo. Hii ni muundo wa jumla zaidi, na inamaanisha kuwa frontend huamua ni watoa huduma gani waliopo. Katika uchakataji wa chaguo wa maktaba yenyewe, cryptoapicert inaonekana miongoni mwa maagizo ambayo hayajatekelezwa, jambo ambalo linaendana na mgawanyo huo wa uwajibikaji.

Kuwepo kwa miito hiyo ya kurudi hakumaanishi kuwa programu fulani iliyofungashwa inaorodhesha hifadhi binafsi ya mtumiaji wa sasa, inaunga mkono mtoa ufunguo fulani au inaweza kukamilisha ombi la kadi mahiri. Hizo ni sifa za frontend, na kila moja lazima iandikwe na frontend.

Frontend ya Windows hufanya nini badala yake

OpenVPN Connect inachukua njia nyingine: mwendeshaji huagiza faili ya PKCS#12 inayojumuisha cheti na ufunguo wake binafsi kwenye OpenVPN Certificate Store iliyoundwa kwa ajili hiyo, kisha humpa cheti cha nje profaili. Hii ni hatua ya uagizaji ya kukusudia, si ugunduzi wa kiotomatiki wa kile kinachotokea kuwa katika hifadhi binafsi. Tofauti hii ni muhimu wakati mtu anadhani kuwa cheti kilichosakinishwa kwa madhumuni mengine kitaonekana tu kwenye orodha ya mteja.

Uagizaji pia una matokeo kwa sera ya funguo, kwa sababu kuhamisha ufunguo kwenye faili ya P12 ndilo hasa ambalo ufunguo usioweza kuhamishwa umeundwa kuzuia. Hili ni swali la sera na si la usanidi, na linastahili jibu kabla mtu hajajaribu uagizaji.

Chagua njia inayolingana na sera ya ufunguo

Ikiwa kitambulisho kinaweza kuhamishwa na sera inaruhusu uagizaji ulioandikwa, tumia mchakato wa usajili uliolindwa wa shirika na uweke P12 ya muda na nenosiri lake nje ya kumbukumbu na skripti. Ikiwa ufunguo haupaswi kamwe kuondoka kwenye kadi mahiri au mtoa huduma aliyelindwa, chagua mchanganyiko wa mteja na mtoa huduma unaounga mkono wazi hitaji hilo, au pata uthibitisho kutoka kwa muuzaji kwa toleo ulilosakinisha. Hakuna tawi hata moja ambalo ni njia mbadala ya lingine.

Kuongeza agizo tena kwenye profaili hakuwezi kutoa muunganisho ambao programu haina. Toleo jipya la mteja pia haliiongezi kwa lazima, kwa sababu uwezo huo ni wa muundo wa frontend yenyewe.

Baada ya ufunguo wa ndani kufanya kazi, seva bado hukagua utambulisho wa cheti, mnyororo na idhini. Ufunguo wa ndani unaotumika na utambulisho wa VPN uliokubaliwa ni matokeo tofauti, na kuyatenganisha ndiko kunakozuia ukomo wa frontend kugeuka kuwa sera dhaifu ya vyeti.