Paano nireresolba ng OpenVPN ang sertipiko at susi: inline PEM o landas
Ang parehong direktiba ay nagdadala ng landas ng file o naka-embed na PEM object. Basahin kung alin ang ginagamit ng na-load na profile bago ilipat ang mga sertipiko.
Sinasabi ng mensahe na OpenVPN ay hindi makapag-load ng inline na sertipiko, samantalang ang filename na nasa isip mo ay nagsasabi ng kabaligtaran. Ang natanggap ng parser ay mas mahalaga kaysa sa nilalaman ng file system, dahil ang direktiba cert ay tumatanggap ng dalawang ganap na magkaibang uri ng halaga. Ang isa ay landas na binubuksan nito; ang iba ay tekstong PEM na dumating sa loob ng configuration. Hangga't hindi mo alam kung anong anyo ang natanggap ng tumatakbong kliyente, bawat pagwawasto ay hula lamang.
Dalawang anyo ng imbakan, isang direktiba
Ang mga direktibang cert, key at ca ay tumatanggap ng landas o naka-embed na bloke. Kapag landas ang halaga, binubuksan ng OpenVPN ang file na iyon at binabasa ang object mula sa disk. Kapag ang configuration ay may bloke na napapaligiran ng mga cert tag, ginagamit ng parehong direktiba ang nilalaman sa pagitan ng mga tag na iyon sa halip, at walang hiwalay na file na kasangkot.
Parehong nagbubunga ang dalawang anyo ng parehong uri ng object sa huli, kaya ang gumaganang deployment ay makakalipat sa pagitan ng mga ito nang walang ibang pagbabago. Ang profile na may naka-embed na sertipiko ng kliyente at pribadong susi ay self-contained, at gumagana ang pagkopya nito sa ibang makina nang hindi rin kinokopya ang direktoryo ng mga sertipiko.
Hindi totoo ang kabaligtaran. Ang paglalagay ng client.crt sa tabi ng profile na nag-e-embed ng sarili nitong data ay walang binabago, dahil walang anuman sa configuration ang tumutukoy sa file na iyon. Ito ang pinakakaraniwang dahilan kung bakit ang file na malinaw na umiiral ay tila binabalewala.
Paano nagiging object ang isang naka-embed na bloke
Ang naka-embed na nilalaman ay kinukuha mula sa configuration at ibinibigay sa PEM parser bilang teksto. Inaasahan ng parser na iyon ang karaniwang hangganan: isang linyang BEGIN, isang base64 payload at isang tumutugmang linyang END. Kung ang bloke ay naputol ng bigong pagkopya, nabalot sa HTML ng isang download page o nabuksan sa editor na nag-normalize ng mga gitling, nabibigo ang parser sa nilalaman na tila naroroon.
<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>
Iyon din ang dahilan kung bakit ang pananalita ng error ay nakaliligaw. Ang salitang naka-embed ay naglalarawan kung saan tumingin ang loader, hindi kung ano ang natagpuan doon. Ang file na pinangalanan sa isang configuration at ang object na naka-embed dito ay maaaring magdulot ng parehong reklamo kapag ang mga batayang byte ay hindi magamit.
Suriin kung aling anyo ang aktwal na ginagamit ng na-load na profile, hindi kung aling file ang aksidenteng binuksan ng iyong editor:
grep -nE '^(ca|cert|key) |^<(ca|cert|key)>' client.ovpn
Paano nireresolba ang reperensya ng landas
Ang halaga ng landas ay binubuksan kaugnay ng working directory ng kliyente, hindi ng direktoryo na naglalaman ng configuration. Sa ilalim ng systemd, ang working directory na iyon ay ang itinatakda ng unit, at ang interactive na pagtakbo mula sa iyong shell ay nagmamana ng ibang bagay. Kaya ang parehong configuration file ay maaaring gumana kapag sinubukan mo ito nang manu-mano at mabigo bilang serbisyo.
Ang mga relatibong landas ay nagmamana ng parehong kalabuan. Kapag nakakita ka ng hubad na filename, itanong kung ano ang kasalukuyang direktoryo ng proseso sa produksyon sa halip na ipagpalagay na tugma ito sa iyong terminal.
Para sa sertipikong hiwalay na nakaimbak, kinukumpirma ng offline na pagsusuri ang object bago mo i-debug ang anumang bagay sa itaas nito:
openssl x509 -in client.crt -noout -subject -issuer -dates
openssl pkey -in client.key -noout -check
Pinapatunayan ng mga utos na iyon na ang mga file ay nababasa at balido sa estruktura. Hindi nila pinapatunayan na ang kapares ay nagtitiwala sa issuer, na ang sertipiko ay nasa loob pa ng panahon ng bisa, o na ang susi ay pag-aari nito.
Ano ang maaari at hindi maaaring sabihin ng error ng parser
Ang bigong pagsusuri ay naglilokasyon ng problema sa isang input at isang yugto. Hindi nito sinasabi kung alin sa dalawang anyo ng imbakan ang ginamit ng kliyente, at hindi rin nito sinasabi kung tatanggapin ang object. Ito ay magkahiwalay na tanong na may magkahiwalay na ebidensya.
Kapag nagtagumpay ang pagsusuri, ang susunod na bigo ay kabilang sa mas huling yugto. Ang pagtanggi ng tiwala, hindi pagtutugma ng layunin o hindi pagtutugma ng susi ay iniuulat ng kapares o ng TLS layer, hindi ng loader. Ang paulit-ulit na pagpapalit ng parehong file ay hindi maglilipat ng error na iyon.
Ilayo ang sensitibong kalahati sa mga pampublikong ulat habang nag-iimbestiga. Ibahagi ang mga pangalan ng direktiba, teksto ng error at istruktura ng bloke, na inalis ang materyal ng susi at anumang nagpapakilalang payload. Ang manwal ng openvpn(8) ay nagdodokumento ng dalawang anyo ng mga direktiba ng file at ng pag-uugali ng working directory sa likod ng mga ito.