May nag-uulat na ang VPN key ay pampubliko, at ang pangungusap na iyon ay nagtatago ng tatlong lubos na magkakaibang sitwasyon. Maaaring ito ay isang CA certificate na dapat taglayin ng bawat kliyente, isang pribadong identity key na hindi dapat umalis sa isang makina, o isang pinagsasaluhang lihim ng control channel na dapat hawakan ng dalawang dulo. Ang pag-aayos, pagkaapurahan at lawak ng pinsala ay magkakaiba sa bawat kaso, kaya ang unang gawain ay pag-uuri, hindi pagkilos. Kung mali ang kategorya, ang bawat susunod na hakbang ay nasayang na pagsisikap.

Magsimula sa direktiba, hindi sa pangalan ng file

Basahin ang aktibong configuration at alamin kung aling direktiba ang tumuturo sa materyal na pinag-uusapan. Ginagamit ng mga TLS option ng OpenVPN ang ca para sa pinagkakatiwalaang materyal ng certificate, ang cert para sa certificate ng lokal na peer at ang key para sa pribadong key na kabilang dito.

Walang pinatutunayan ang mga pangalan ng file. Ang file na pinangalanang key.pem ay maaaring may certificate, at ang naka-embed na block sa profile ay maaaring may eksaktong parehong bagay gaya ng hiwalay na file sa disk. Buksan ang file at tingnan ang header nito sa halip na magtiwala sa pangalan. Ang isang pagsusuring iyon ay nag-aalis ng karamihan ng kalabuan sa ulat.

Kung ang profile ay PKCS#12 bundle, i-unpack ito sa kontroladong lugar upang makita kung ano talaga ang laman. Ang isang bundle ay maaaring magdala ng certificate, ang chain nito at isang pribadong key, na nangangahulugang ang pagtagas ng bundle ay pagtagas ng tatlo.

Isulat ang pag-uuri bago baguhin ng kahit sino ang isang file: bagay, direktiba, aling mga peer ang may hawak at sino ang makakabasa. Ang pangungusap na iyon ang batayan ng buong tugon.

Ang CA certificate ay dinisenyo upang ibahagi

Ang pampublikong CA certificate ay materyal ng pagtitiwala. Kailangan ito ng mga kliyente upang i-verify ang server, at ang pamamahagi nito ay normal na kaso, hindi insidente. Ang paglathala nito ay hindi naglalathala ng pribadong signing key ng CA, at ang bagay na iyon ang magbibigay-daan sa isang umaatake na lumikha ng mga bagong pagkakakilanlan.

Ang pagkakaibang iyon ay dapat isulat nang malinaw sa ticket, dahil ang dalawa ay laging pinagpapalit. Ang tanong na dapat sagutin ay kung ang tumagas na file ay ang certificate o ang signing key, at isang sulyap sa nilalaman ng file ang magpapasya nito. Ang certificate ay may pampublikong key at lagda; ang signing key ay hindi lumilitaw dito kahit kaunti.

Ang pamamahagi ay nangangailangan pa rin ng pag-iingat. Dapat makuha ng mga kliyente ang certificate sa aprubadong landas ng paghahatid ng profile, hindi mula sa paste site, at ang certificate na dumarating sa hindi mapagkakatiwalaang ruta ay maaaring mapalitan habang papunta.

Ang peer key at ang tls-auth secret ay hindi

Ang pribadong key ng isang peer ay materyal ng pagkakakilanlan. Kapag nakopya na ito, hindi na kayang makilala ng server ang inilaan na device mula sa sinumang may kopya, dahil ang eksklusibong pagmamay-ari ang katangiang pinapatunayan. Ang pagpapatuloy ng awtorisasyon at pagpapalit ay desisyon ng may-ari ng VPN, hindi ng nakahanap ng file.

Ang tls-auth secret ay ikatlong bagay. Nagdaragdag ito ng HMAC authentication sa paligid ng mga packet ng control channel upang ang maling na-authenticate na packet ay itapon bago ang TLS exchange, at hindi ito ang pribadong key ng peer at hindi rin ang key na nag-e-encrypt ng data ng application.

Kung ang pinagsasaluhang lihim na iyon ay pampubliko, ang hadlang na ibinigay nito ay wala na para sa lahat ng mayroon nito. Hindi ito nangangahulugang ang bawat may hawak ay pumapasa sa mga pagsusuri ng certificate at user sa likod nito, kaya mas mahalaga ang pag-uuri kaysa sa antas ng alarma. Sabihin kung aling hadlang ang bumagsak, at sabihin kung alin ang natitira.

Ayusin ang papel na tumagas, hindi ang kapitbahay

Ang pinagsasaluhang lihim ay hindi na muling magiging pribado sa pamamagitan ng pagpapalit ng pangalan ng file o pagtatago ng download link. Ang pagpapalit ay nangangahulugan ng pagbuo ng bagong halaga at pamamahagi nito sa bawat peer sa isang koordinadong pagbabago, at ang pagpapalit ng isang panig lamang ay sumisira sa kasunduan para sa lahat ng may lumang halaga pa.

Kung naexpose ang pagkakakilanlan ng isang peer, gamitin ang proseso ng pag-revoke at muling pagpaparehistro ng operator para sa pagkakakilanlang iyon. Ang pagpapalit ng password ng walang kaugnayang account ay hindi nagpapawalang-bisa sa nakopyang certificate, at gayundin ang pagpapalit ng tls-auth file.

Tiyakin kung ano talaga ang ipinapatupad ng naka-deploy na server bago umasa sa alinman sa mga ito. Ang revocation list na hindi nire-refresh, o ang role check na na-disable habang may outage, ay ganap na nagbabago ng sagot. Basahin ang tumatakbong configuration, hindi ang kopya sa repository.

Hatulan ang nakaraang trapiko sa sarili nitong mga tuntunin

Ang naexpose na file ay hindi mismo nagsasabi kung ang mga sesyong nahuli noon ay maaaring i-decrypt. Nakadepende ito sa paraan ng pagtatatag ng key, sa naexpose na materyal at sa kung anong mga tala ang umiiral, at parehong «nawala ang lahat ng trapiko» at «walang nangyari» ay haka-haka kung wala ang mga katotohanang iyon.

Huwag mag-post ng isa pang kopya ng credential habang nagtatanong kung aling kategorya ito nabibilang. Sa halip, ibahagi ang mga pangalan ng direktiba at hindi-lihim na metadata sa aprubadong landas ng suporta.

Ang kapaki-pakinabang na konklusyon ay pinangalanan ang bagay, ang papel nito, ang nawalang proteksyon at ang kinakailangang koordinadong aksyon. Ang anumang mas maikli ay headline, hindi pagtatasa.

Kaugnay na mga artikulo