Aling openvpn binary ang tumatakbo? Suriin ang landas ng paglulunsad

Isang lumang solusyon ang naglipat ng executable ng OpenVPN sa ibang lugar at nag-iwan ng shell wrapper sa orihinal na landas. Pagkalipas ng mga buwan, may darating na update, at ang pag-undo sa solusyon ay nagiging hulaan kung aling file ang talagang kliyente. Ang pangalan ng utos, ang executable na naka-configure sa serbisyo at ang sariling listahan ng file ng package ay maaaring tumukoy sa magkaibang bagay, at ang pag-aayos ng isa nang wala ang iba ay gumagawa ng host na mukhang maayos at mas masama ang kilos.

Magsimula sa landas na inilulunsad ng serbisyo

Ang terminal at ang systemd unit ay hindi nagre-resolve ng executable sa parehong paraan. Naghahanap ang shell sa isang PATH; nagpapangalan ang unit ng landas, at ang mga drop-in override ay makapagpapalit nito nang hindi hinahawakan ang file na binabasa mo. Ipinapaliwanag ng pagkakaibang iyon ang halos lahat ng kalituhan sa gawaing ito. Ito rin ang nagtatakda kung aling file ang dapat na target ng pag-aayos mo.

Tanungin ang unit kung ano ang inilulunsad nito, kasama ang mga drop-in na nagbabago nito, at basahin ang resultang ExecStart line sa halip na ang bahaging inaakala mong awtoritatibo. Pagkatapos sundan ang landas na iyon sa anumang symbolic link hanggang sa huling file. Ang wrapper na nagtatapos sa exec sa isang nakatagong direktoryo ay karaniwang ayos mula sa mga lumang pag-aayos na ito.

Isulat ang na-resolve na landas bago magbago ng anuman.

systemctl cat [email protected] | grep -n 'ExecStart'
readlink -f "$(command -v openvpn)"

Ihambing ang pangalan ng utos sa landas ng serbisyo

Kadalasang magkaiba ang dalawang sagot, at ang pagkakaibang iyon ay hindi awtomatikong depekto. Maaaring maglunsad ng sariling landas ang isang plugin ng NetworkManager, at maaaring mag-mount ng isa pa ang isang container.

Ang mahalaga ay malaman kung aling may-ari ang naglulunsad ng prosesong naglilingkod sa trapiko. Kung ang unit ay nagpapatakbo ng /usr/local/sbin/openvpn-wrapper samantalang nire-resolve ng shell mo ang /usr/sbin/openvpn, walang nababago sa serbisyo ang pag-aayos sa pangalawang file.

Itanong kung aling package ang may-ari ng bawat kandidato, pagkatapos ay magpasya kung ang file ay pinamamahalaan ng package o inilagay nang lokal. Ang file na walang nagmamay-ari na package ay file na sadyang inilagay ng isang tao roon, at karapat-dapat itong magkaroon ng pangalan, may-ari at dahilan bago burahin. Karaniwan din ang kabaligtarang pagkakamali: pag-overwrite sa file ng package gamit ang lumang naka-save na binary dahil ginamit ng isang post sa forum ang parehong direktoryo.

Hayaan ang database ng package na magsalita tungkol sa mga file ng package

Kapag ang software ay galing sa isang Debian package, masasabi ng database ng package kung tumutugma pa ang mga file nito sa na-install. Ito ay makitid na tanong tungkol sa integridad, hindi hatol sa seguridad, at mahalaga ang pagkakaiba kapag nagpapasya ka kung ano ang aayusin. Ang hindi pagtutugma ay nangangahulugang nagbago ang file pagkatapos ng pag-install, na maaaring ang lumang solusyon mo o isang lehitimong lokal na pag-edit. Hindi niresolba ng output kung alin, kaya basahin ito bilang palatandaan at hindi bilang konklusyon.

Patakbuhin ang verification at basahin ang output sa halip na ituring na patunay ng kahit ano ang walang laman na resulta.

dpkg -S /usr/sbin/openvpn
dpkg --verify openvpn

Manwal ng dpkg ay nagdodokumento na inihahambing ng verification ang mga naka-install na file sa metadata na naitala nang lokal, gamit ang mga naka-save na checksum kung mayroon. Napapansin nito ang binagong file ng package, at hindi nito masasabi kung may ibang binary na inilulunsad sa halip.

Itala ang kalagayan bago mag-ayos

Tipunin ang na-resolve na landas ng paglulunsad, ang kaugnayan ng file sa package, ang lokasyon ng wrapper at ang talaan ng pagbabagong nagdala nito. Kopyahin ang wrapper sa protektadong lugar kung naglalaman ito ng gawaing integrasyon na kakailanganin mamaya.

Huwag i-paste ang nilalaman ng wrapper sa isang thread ng suporta bago ito basahin, dahil kung minsan ay may dalang kredensyal o detalye ng gateway ang mga script na ito.

Itala kung aling mga profile ang ginagamit ng serbisyo at sino ang konektado habang nagtatrabaho ka, dahil maaaring maputol ng pag-restart ng tunnel ang session na ginagamit mo sa pangangasiwa ng host.

I-verify ang paglulunsad, pagkatapos ay alisin ang wrapper

Pagkatapos ng pag-aayos, simulan ang serbisyo at kumpirmahin na ang proseso ay tumatakbo sa landas na nilayon mo. Ang query ng bersyon na ginawa sa kamay ay nagpapatunay na gumagana ang file; hindi nito pinapatunayan na ginagamit ito ng unit.

Pagkatapos ay muling ikonekta ang isang kliyente at suriin kung nag-aauthenticate pa rin ang profile, dahil ang pagpapalit ng binary na hindi pinapansin ang orihinal na mga opsyon ay mabibigo sa paraang mukhang problema sa sertipiko.

Alisin ang inilipat na wrapper sa pamamagitan ng parehong talaan ng pagbabagong nagdala nito. Ang natapos na pag-aayos ay nagsasaad kung aling executable ang tumatakbo, bakit, at aling file ang tinanggal; ang ibalik ang pangalan ng file at umasa ay hindi pareho.