Binabalewala ang client-config-dir matapos maging serbisyo ang OpenVPN

Bumangon ang tunnel mo at kumonekta ang kliyente, pero nawawala ang fixed address at ang mga naipush na ruta na itinakda mo para sa isang user na iyon. Walang “file not found” sa log, at iyon ang nagpapadala sa mga tao na muling gumawa ng mga sertipiko. Sa karamihan ng mga kasong ito, tumatakbo ang daemon mula sa ibang direktoryo kaysa sa shell na ginamit mo sa pagsubok, at client-config-dir ay hindi kailanman niresolba ayon sa inaasahan mo. Ang pagwawasto ay pagwawasto ng path, hindi pag-reset ng kredensyal.

Basahin ang unit bago hawakan ang configuration

Magsimula sa prosesong talagang tumatakbo, hindi sa file na inedit mo. Tanungin ang systemd tungkol sa execution line, working directory at account na binabaan nito. Ang tatlong sagot na iyon ang nagpapaliwanag sa karamihan ng mga kabiguan sa klase na ito:

systemctl show openvpn-server@server -p ExecStart -p WorkingDirectory -p User -p RootDirectory

Ang walang laman na WorkingDirectory ay nangangahulugang nagsisimula ang unit sa /, kaya ang relatibong client-config-dir ccd ay hinahanap sa /ccd. Halos hindi umiiral ang direktoryong iyon, at hindi itinuturing ng daemon na nakamamatay ang kawalan nito.

Ihambing iyon sa interactive na paglunsad na ginamit mo noong pagsubok, kung saan ang kasalukuyang direktoryo ng shell mo ay malamang na direktoryo ng configuration. Parehong file, parehong keyword, dalawang magkaibang resulta.

Laban sa ano nireresolba ang relatibong path

Ang keyword ay nireresolba laban sa working directory ng proseso sa sandaling gamitin ang opsyon. Hindi ito nangangahulugang “sa tabi ng configuration file na ipinasa ko gamit ang --config”. Masayang babasahin ng OpenVPN ang configuration mula sa absolute path at ireresolba pa rin ang relatibong halaga sa ibang lugar, at iyon mismo ang bitag dito. Isinasaad ng manwal ng OpenVPN 2.6 ang tuntunin sa ilalim ng --client-config-dir at muli sa ilalim ng --cd.

Binabago ng keyword na cd ang kontekstong iyon bago basahin ang iba pang file, kaya ang unit na nagtatakda ng cd /etc/openvpn/server at pagkatapos ay client-config-dir ccd ay nireresolba sa /etc/openvpn/server/ccd. Kung magdadagdag ka ng cd, suriin ang pagkakasunod-sunod ng mga direktiba at tandaan na naaapektuhan nito ang bawat iba pang relatibong reperensiya sa parehong file.

Sundan ang path bilang account ng daemon

Maaaring tama ang path pero hindi pa rin mabasa. Pagkatapos ng pagbaba ng pribilehiyo ay hindi na root ang daemon, kaya kailangan ng bawat parent directory ng search permission para sa account na iyon, at ang client file mismo ay kailangan ng read permission. Sapat na ang isang kulang na execute bit sa isang parent upang itago ang file, at ang error ay lumilitaw lamang bilang kliyenteng tahimik na nakakakuha ng default pool.

namei ang nagpi-print ng permiso ng bawat bahagi sa ayos, na mas mabilis kaysa sa pagsuri ng mga direktoryo nang isa-isa:

namei -l /etc/openvpn/server/ccd/client1

Pagkatapos ay subukan ang pagbasa bilang service account at hindi bilang ikaw mismo:

runuser -u openvpn -- test -r /etc/openvpn/server/ccd/client1 && echo readable

Kung gumagamit ang unit ng chroot, dapat umiral ang direktoryo sa loob ng kulungan, at ang path sa configuration ay binibigyang-kahulugan pagkatapos mailapat ang chroot. Ang file na nasa host sa labas ng kulungan ay hindi nakikita mula sa loob.

Kumpirmahin ang paghahanap sa halip na manghula

Itaas ang antas ng log para sa isang restart at basahin ang sinasabi ng server tungkol sa mga opsyong partikular sa kliyente. Sa verb 4 iniuulat ng daemon ang configuration bawat kliyente na inangkat nito, kaya ang nawawalang linya ay direktang ebidensiya na walang file na nabasa para sa koneksiyon na iyon.

openvpn --config /etc/openvpn/server.conf --verb 4 --client-config-dir /etc/openvpn/server/ccd

Patakbuhin iyon sa foreground sa isang bakanteng port at ikonekta ang isang kliyente. Tinatanggal niyon ang systemd nang lubusan sa larawan: kung lumilitaw dito ang mga override at hindi sa ilalim ng serbisyo, ang pagkakaiba ay konteksto ng unit, hindi ang file.

Magpasya kung ano ang dapat mangyari kapag walang file na tumutugma. Kung walang ccd-exclusive ang kliyente ay tinatanggap lamang gamit ang global pool settings, at iyon ang tahimik na kabiguan na inilarawan sa itaas. Kapag mayroon nito, ang nawawalang file ay nagiging tinanggihang koneksiyon, at ang pagtanggi ay mas madaling mapansin pero mas mahirap i-debug sa ilalim ng load.

Itama, i-restart, i-verify

Gawing absolute ang direktoryo sa configuration at panatilihin itong ganoon. Ang mga relatibong path ay ligtas lamang kapag ipinako ng unit ang working directory, at ang pagpako ay karagdagang gumagalaw na bahagi na aalisin ng isang tao mamaya.

client-config-dir /etc/openvpn/server/ccd
ccd-exclusive

I-restart ang instance, ikonekta muli ang isang kilalang kliyente at basahin ang address na natanggap nito kasama ang mga rutang naipush dito. Kung tumutugma ang address sa linyang ifconfig-push sa file ng kliyenteng iyon, gumana ang paghahanap. Kung nahuhulog pa rin ang kliyente sa pangkalahatang pool, bumalik sa bilang ng mga linya ng log: zero import ang ibig sabihin ay mali ang path o ang pagkakakilanlan, isang import na may maling nilalaman ang ibig sabihin ay nag-edit ka ng ibang file kaysa sa binabasa ng daemon.

Bumalik sa pamamagitan ng pagpapanumbalik ng nakaraang unit at configuration nang magkasama, pagkatapos ay i-restart. Hindi kailangang muling ilabas ang mga sertipiko para sa alinman sa mga ito, at ang pagtrato sa problema ng direktoryo bilang problema ng kredensyal ay ang paraan na ang limang minutong pagwawasto ay nagiging maintenance window.