Hindi mahanap ng OpenVPN ang ca.crt kahit naglo-load ang profile

Nagsisimula ang serbisyo, binabasa ang profile nang walang reklamo at pagkatapos ay namamatay sa isang linyang tila walang kaugnayan: hindi nito mabuksan ang ca.crt. Walang nagbago sa sertipiko, at ang landas ng profile sa unit file ay absolute. Eksaktong ang kombinasyong iyon ang palatandaan. Ang landas na ibinigay mo ay tumutukoy sa isang file, at ang mga pangalan sa loob ng file na iyon ay nireresolba sa ibang lugar nang lubusan, kaya ang isang paglulunsad na mukhang ganap na kwalipikado ay maaari pa ring magbasa ng mga susi nito mula sa direktoryo na walang sinuman ang nagtangka.

Kakaunti ang sanhi ng pagpalya, at sulit na paghiwalayin ang mga ito sa pagkakasunod-sunod: ang baseng direktoryo na talagang mayroon ang proseso, ang konteksto ng paglulunsad ng serbisyo, at ang mga pahintulot o sandbox sa paligid ng file kapag tama na ang landas. Bawat isa ay nag-iiwan ng ibang bakas — sa unit, sa proseso at sa file system.

Ang landas ng profile ay hindi baseng direktoryo

Isipin ang isang proseso na nagsisimula sa /tmp at binibigyan ng /etc/vpn/prod/tenant-a.ovpn. Sa loob ng profile na iyon, ang linyang ca ca.crt ay nagpapangalan ng relatibong landas. Walang anuman sa argumento na nakahanap ng profile ang nagsusulat muli ng pangalang iyon, kaya hinahanap ng proseso ang /tmp/ca.crt at nag-uulat ng kulang na file.

Ang nakakalito ay ang pagkakasunod-sunod ng mga error. OpenVPN ay unang nag-parse ng konfigurasyon at binubuksan ang mga tinukoy na file habang nararating ang mga ito, kaya ang typo sa profile ay iniuulat bago pa man mahawakan ang anumang susi, samantalang ang kulang na sertipiko ay lumilitaw lamang kapag umabot doon ang pag-parse. Ang isang profile na naglo-load ay katibayan ng tamang sintaks, hindi na natagpuan ang mga file na pinangalanan nito.

Ano ang hinihiwalay ng manwal: --config at --cd

Inilalarawan ng manwal ng OpenVPN 2.6 ang dalawang magkaibang opsyon. Ang isa ay naglo-load ng file ng konfigurasyon. Ang isa pa ay nagpapalit ng direktoryo ng proseso bago basahin ang konfigurasyon, susi, script at iba pang file, at nangangailangan ng absolute na direktoryo na walang anumang pagtukoy sa kasalukuyan.

openvpn --cd /etc/vpn/prod --config tenant-a.ovpn

Ang tawag na iyon ay isang anyo, hindi utos na ilunsad ang profile ng ibang tao. Ang ibinibigay nito ay determinismo: ang batayan ng bawat relatibong pangalan sa kadena ay nakasaad sa utos sa halip na mamanahin mula sa alinmang shell o tagapamahala na nagpasimula ng proseso. Ang alternatibo ay parehong wasto at kadalasang mas mabuti para sa serbisyo: hayaang manatili ang working directory at gawing absolute ang bawat tinukoy na file sa loob ng profile.

Anuman ang piliin mo, i-audit ang buong kadena at hindi ang unang pagpalya. Ang isang profile ay maaaring humila ng ibang file ng konfigurasyon, at ang mga relatibong pangalan ng kasamang file ay nireresolba laban sa parehong direktoryo ng proseso, hindi laban sa direktoryo ng file na nagsama sa kanila. Ang mga landas ng log, file ng pagpapatunay at pantulong na script ay sumusunod sa parehong tuntunin.

Ang serbisyo ay nagsisimula sa ibang lugar

Ang interaktibong shell sa direktoryo ng profile ay walang pinapatunayan tungkol sa isang nakabalot na unit. Ang mga tagapamahala ay nagtatakda ng sarili nilang working directory, at ang wrapper script ay maaaring muling baguhin ito bago tumakbo ang binary. Ang unit na pumapalya ang tanging paglulunsad na sulit pag-isipan.

systemctl show -p WorkingDirectory -p ExecStart --value openvpn@tenant-a
ls -l /proc/$(pgrep -n openvpn)/cwd

Ipinapakita ng ikalawang utos ang direktoryo na talagang hawak ng buhay na proseso, at ito ay mas mapagkakatiwalaan kaysa sa unit file kapag may wrapper. Kung hindi magkasundo ang dalawa, ang wrapper ang sagot at ang unit ay mapanlinlang na bakas.

Pagkatapos ng paghahanap: mga pahintulot, chroot at sandbox

Ang tamang baseng direktoryo ay maaari pa ring magbigay ng parehong mensahe, dahil magkaibang hakbang ang resolusyon at pag-access. Kailangan ng proseso ng pahintulot sa pagpapatupad sa bawat magulang na direktoryo at pahintulot sa pagbasa sa file, at ang unit ng serbisyo na nagtatago ng bahagi ng file system ay nagbabago sa kung ano ang makikita ng proseso.

Tatlong karaniwang variant ang nagdudulot ng parehong error. Ang file ay nababasa lamang ng root habang ang serbisyo ay nagbitiw ng pribilehiyo bago ito buksan. Nagtatakda ang unit ng protektibong tanaw ng file system na hindi kasama ang direktoryo ng profile. Tumatakbo ang daemon nang may chroot, kaya ang landas na umiiral sa host ay wala sa loob ng tanaw na iyon.

Mag-diagnose gamit ang pagmamay-ari ng file at pagkakakilanlan ng proseso, hindi sa pagluwag ng mga pahintulot. Ang gawing nababasa ng lahat ang isang pribadong susi upang patahimikin ang error na ito ay ipinagpapalit ang malakas na pagpalya sa tahimik, at ang susi ay mismong bahagi ng direktoryo na pinaka-ayaw mong ilantad.

Patunayan ang pagwawasto gamit ang sarili mong paglulunsad

I-restart ang tunay na unit mula sa direktoryong walang kaugnayan sa profile at panoorin ang parehong startup line. Pagkatapos ay kumpirmahin na hawak ng proseso ang nilalayong direktoryo habang tumatakbo, at ang na-load na sertipiko ay ang inaasahan mo.

systemctl restart openvpn@tenant-a
systemctl status openvpn@tenant-a --no-pager
journalctl -u openvpn@tenant-a -n 20 --no-pager

Kapag nagtagumpay ang pag-load ng mga landas, ang pagpapatunay at pagruruta ay magkaibang yugto pa rin na may sariling pagpalya, at ang koneksyon na bumabangon ngunit walang trapikong dumadaan ay ibang pagsisiyasat. Ang pagwawasto dito ay tungkol lamang sa kung saang direktoryo nagmula ang mga file, at dapat itong makita sa tawag sa halip na tandaan ng huling nagpatakbo nito nang manu-mano.

Kung ang profile ay ipinapakalat ng tagapamahala ng konfigurasyon, ilagay doon ang baseng direktoryo o ang mga absolute na pangalan ng file. Ang manu-manong pagwawasto sa isang host ay ang bersyon ng problemang ito na bumabalik pagkatapos ng susunod na muling pagbuo.