Gumagana ang OpenVPN sa shell ngunit nabibigo sa ilalim ng cron: ang PATH ang dahilan

Ang parehong command ay kumokonekta mula sa shell at namamatay sa ilalim ng cron, kaya ang natural na kongklusyon ay ang tunnel o ang certificate ang may kasalanan. Tingnan kung ano ang pareho sa dalawang pagtakbo bago ito paniwalaan: magkapareho ang binary, configuration at credentials, at ang environment ng proseso lang ang nagbago. Kapag hindi man lang mahanap ang programa, walang dami ng TLS debugging ang makakatulong. Karaniwang nasa isang path, isang working directory at isang dakot ng environment variable ang pagwawasto, hindi sa VPN.

Ang command -v openvpn sa shell na gumagana ay nagpi-print ng sagot, at madalas ito ay /usr/sbin/openvpn, isang directory na hindi inilalagay ng cron sa search path nito.

Hindi kailanman nagsimula ang tunnel, kaya hindi ang tunnel ang problema

Ang mga job na sinisimulan ng cron ay nagmamana ng minimal na environment, karaniwang PATH=/usr/bin:/bin, at walang controlling terminal. Anumang naka-install sa /usr/sbin o /usr/local/sbin ay basta wala sa listahang iyon, at ang linya ng log ay nagbabasa ng openvpn: not found sa halip na TLS error. Ang subprocess ng Python ay nabibigo nang iba: nagmamana ito ng environment ng interpreter process, na maaaring mas mayaman kaysa sa cron ngunit wala pa ring shell na magpapalawak ng tilde. Parehong pagkabigo ay nangyayari bago umalis ang kahit isang packet sa host.

Ang mabilis na paraan upang maiba sila ay basahin ang unang error sa halip na ang huli. Ang nawawalang binary ay gumagawa ng shell o Python exception, ang masamang configuration ay gumagawa ng OpenVPN usage message, at ang tunay na pagkabigo ng handshake ay gumagawa ng timestamp at address ng peer. Ang pangatlo lamang ang problema sa tunnel.

Ang absolute path at argument list ay nananalo sa shell string

Ipasa ang resolved na path nang malinaw at laktawan nang tuluyan ang shell. subprocess.run(["/usr/sbin/openvpn", "--config", config, "--verb", "4"], capture_output=True, text=True, timeout=90) ay nagbibigay ng return code, stdout at stderr nang hindi hinihiling sa shell na bigyang-kahulugan ang filename. Buuin ang path ng configuration mula sa os.environ["HOME"] o pathlib.Path.home(), upang hindi na kailangang palawakin ang tilde. Kapag talagang kailangan mo ng shell syntax, gamitin ang shlex.split, dahil ang paghahati ng string gamit ang .split() ay nasisira sa anumang path na may espasyo. Basahin din ang stderr, dahil isinusulat doon ng OpenVPN ang karamihan ng maagang pagkabigo nito.

Ang parehong tuntunin ay nalalapat sa cron: ang linya ng job ay hindi login shell, kaya walang naglo-load ng iyong profile at walang nagtatakda ng iyong alias.

Ano ba talaga ang namamana ng crontab

Ang entry sa crontab ay nakakakuha ng environment na idinedeklara ng crontab at ilang minanang default, kaya isulat nang buo ang path o balutin ang tawag sa isang script na gumagawa nito. Ang linyang tulad ng PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin sa itaas ng file ay sumasaklaw sa karaniwang lokasyon ng pag-install, at ang redirect gamit ang >> cron.log 2>&1 ang gumagawa sa susunod na pagkabigo na mabasa. Ang profile na protektado ng passphrase ay walang paraan upang hilingin ang sikreto nito sa ilalim ng cron, dahil walang terminal na mapagtatanungan. Ang ganoong koneksyon ay nabibilang sa isang systemd unit na makakabasa ng credential file, hindi sa isang job na nagpapanggap na interactive.

Ang relative path ang pangalawang bitag. Ang pagsubok ay madalas mangyari mula sa folder na may profile, at ang cron job ay nagsisimula sa ibang lugar, kaya ang --config office.ovpn ay nagreresolba sa file na wala roon at ang mensahe ay binabasa bilang nawawalang file kaysa nawawalang tunnel.

Patunayan ito sa pamamagitan ng pagtanggal ng environment

Muling likhain ang minimal na environment nang direkta: env -i PATH=/usr/bin:/bin /usr/sbin/openvpn --config office.ovpn --verb 4. Ang reklamo tungkol sa path o terminal mula sa pagtakbo ay nangangahulugang ang problema ay nasa itaas ng VPN. Kung kumokonekta ito, ang natitirang pinaghihinalaan ay ang account na pinapatakbo nito, ang directory kung saan ito nagsisimula at ang credential na ipinapakita nito. Alinman sa dalawang resulta ay mas mabuti kaysa sa isa pang pag-ikot ng certificate check.

Pagkatapos gawing self-reporting ang wrapper. Lumabas na may natatanging status para sa bawat yugtong naabot, i-log ang parehong stream na may timestamp, at sasabihin sa iyo ng susunod na pagkabigo kung namatay ito sa path resolution, sa authentication o matapos nang nakaangat ang tunnel.

Ang unit ay nangangailangan din ng tamang pagkakasunod-sunod: ang Wants=network-online.target kasama ang After=network-online.target ay pumipigil sa client na magsimula bago umiral ang address o default route, na kung hindi ay lumalabas bilang certificate o TLS error na nawawala kapag manu-manong ini-restart.