Bakit humihingi pa rin ng file ng pribadong key ang OpenVPN kahit may token
Malamang na hindi kailanman pinangalanan ng profile ang token. Ihiwalay ang library ng provider sa serialized na pagkakakilanlan ng certificate, pagkatapos ay subukan mula sa prosesong kumokonekta.
Isinasaksak mo ang token, nakikita ito ng tool ng provider mismo, at humihingi pa rin ng file ng pribadong key ang VPN client. Ang kahilingang iyon ay hindi patunay na hindi sinusuportahan ang token. Karaniwang ibig sabihin nito ay hindi kailanman sinabi ng profile sa client na gamitin ang token, kaya bumalik ito sa mga input ng certificate at key na inaasahan nito bilang default.
Dalawang magkahiwalay na halaga ang dapat tama bago tumigil ang pagbabalik na iyon: ang provider na naglalantad ng token, at ang pagkakakilanlan ng certificate sa loob nito. Ibinibigay ang mga ito ng magkaibang opsyon at madaling pagkamalitin.
Humihingi ng file ang client dahil sinasabi ng profile
Ang default na profile ay umaasa ng file ng certificate at file ng pribadong key, o isang pakete ng PKCS#12. Kapag wala ang mga input na iyon, wala nang mai-load ang client at kumikilos nang halos tulad ng kapag kulang ang file, kaya binabasa ang sintomas bilang sirang landas at hindi bilang kulang na mekanismo. Pinapalitan ng landas ng PKCS#11 ang mga input na iyon sa halip na dagdagan ang mga ito, kaya ang profile na pinangalanan pa rin ang file ng key ay patuloy na gagamit ng file. Sadyang alisin ang mga input ng file at hayaang ibigay ng token ang dalawang hati.
Pinangalanan ng opsyon ng provider ang isang library ng middleware, hindi isang device at hindi isang certificate. Kung ma-load ng naka-package na client ang library na iyon ay nakasalalay sa kung paano ito ginawa, kabilang ang opsyonal na suporta sa p11-kit na pinapagana ng ilang build at iniiwan ng iba. Hindi masasabi ng pangkalahatang tutorial kung anong kaayusan mayroon ang iyong pakete.
Ang serialized na pagkakakilanlan ay ibang halaga
Ang pagkakakilanlan ng certificate ay isang mahabang serialized na string na ginagawa ng proseso ng pagtuklas, at hindi ito ang landas ng library, hindi ang PIN ng token, at hindi ang pangalan ng account sa VPN. Madalas itong naglalaman ng mga karakter na kailangan ng panipi, at ang halagang walang panipi ay maaaring putulin o mabasa nang mali nang walang malinaw na error. Gamitin ang sariling opsyon ng client na pagtuklas ng pagkakakilanlan upang ilista ang inilalantad ng token, pagkatapos ay kopyahin nang eksakto ang nilalayong entry. Ang pagpili ng unang object sa listahan ang paraan kung paano nagtatapos ang isang device sa pagpapakita ng maling certificate.
Sinasagot din ng output ng pagtuklas ang naunang tanong: kung ang token ay nakikita sa provider na iyon. Kung wala itong nakalista, nasa itaas ng VPN client ang problema at pag-aari ito ng middleware.
Ang prosesong kumokonekta ay dapat maabot ang token
Ang operasyon sa token na gumagana sa iyong desktop session ay walang pinatutunayan tungkol sa isang serbisyo ng system. Maaaring tumakbo ang serbisyo bilang ibang user, sa ibang mount namespace, may landas ng module na iniiwan ang library ng provider, o walang pahintulot na buksan ang node ng device. Tukuyin kung aling proseso ang tunay na may hawak ng koneksyon at subukan mula sa kontekstong iyon.
Ang paghawak ng PIN ay karapat-dapat sa sariling desisyon. Nag-aalok ang reference na implementasyon ng cache ng PIN at protektadong landas ng authentication, at pareho itong umiiral upang makapili ang operator ng workflow sa halip na mag-imbento nito. Huwag gawing plaintext na PIN sa loob ng pinagsasaluhang profile ang isang pangangailangang walang pagmamatyag, dahil ipinagpapalit niyon ang proteksyon ng token sa kaginhawahan. Kung saan ipinagbabawal ng token ang pag-export ng key, nangyayari ang paglagda sa device at ang PIN ang tanging lokal na lihim. Tratuhin ito nang may pag-iingat na inaasahan niyon.
Ano ang hindi pinapalitan ng token
Ina-authenticate ng token ang client sa ilalim ng naka-deploy na patakaran, at hindi nito pinapalitan ang mga pagsusuri ng client sa server. Ang matagumpay na napiling certificate ay hindi pahintulot na tanggapin ang isang hindi inaasahang certificate ng gateway, at ang dalawang beripikasyon ay nagpoprotekta sa magkasalungat na direksyon.
Kailangan pa ring mangyari ang enrollment sa issuer, at kailangan pa ring pahintulutan ng gateway ang pagkakakilanlan.
Para sa pagtanggap, paghiwalayin ang mga yugto: naglo-load ang provider, natagpuan ang nilalayong certificate, ginagamit ang pribadong key na may lokal na awtorisasyon, nag-a-authenticate ang VPN, at nagtatagumpay ang operasyon sa resource. Huminto sa unang yugtong nabigo sa halip na magpaikot-ikot sa mga password at i-reinstall ang crypto stack.
Itala ang mga bersyon, pagmamay-ari ng module, ang napiling pampublikong identifier at ang mga nalinis na error, at ilayo ang mga PIN at bundle ng kredensyal sa talaang iyon.