OpenVPN працуе ў абалонцы, але пад cron не запускаецца: справа ў PATH

Тая самая каманда падключаецца з абалонкі і памірае пад cron, таму натуральная выснова — вінаваты тунель або сертыфікат. Паглядзіце, што агульнае ў двух запускаў, перш чым у гэта паверыць: бінарны файл, канфігурацыя і ўліковыя даныя аднолькавыя, змянілася толькі асяроддзе працэсу. Калі праграма нават не знойдзена, ніякая адладка TLS не дапаможа. Выпраўленне звычайна ляжыць у шляху, працоўным каталогу і жмені зменных асяроддзя, а не ў VPN.

command -v openvpn у абалонцы, якая працуе, друкуе адказ, і вельмі часта гэта /usr/sbin/openvpn, каталог, які cron не дадае ў свой шлях пошуку.

Тунель так і не стартаваў, значыць, праблема не ў тунелі

Заданні, запушчаныя cron, атрымліваюць у спадчыну мінімальнае асяроддзе, звычайна PATH=/usr/bin:/bin, і не маюць кіруючага тэрмінала. Усё, што ўсталявана ў /usr/sbin або /usr/local/sbin, проста адсутнічае ў гэтым спісе, і радок журнала чытаецца як openvpn: not found замест памылкі TLS. Python-аўскі subprocess падае інакш: ён атрымлівае ў спадчыну асяроддзе працэсу інтэрпрэтатара, якое можа быць багацейшым за cron-аўскае, але абалонкі для разгортвання тыльды ў ім усё яшчэ няма. Абодва збоі адбываюцца перш, чым хоць адзін пакет пакіне хост.

Хуткі спосаб іх адрозніць — чытаць першую памылку, а не апошнюю. Адсутны бінарны файл дае выключэнне абалонкі або Python, дрэнная канфігурацыя дае паведамленне аб выкарыстанні OpenVPN, а сапраўдны збой рукапаціскання дае адзнакі часу і адрасы партнёраў. Толькі трэці выпадак — праблема тунеля.

Абсалютныя шляхі і спісы аргументаў лепш за радкі абалонкі

Перадавайце вырашаны шлях явна і цалкам абыдзіце абалонку. subprocess.run(["/usr/sbin/openvpn", "--config", config, "--verb", "4"], capture_output=True, text=True, timeout=90) дае вам код вяртання, stdout і stderr, не просячы абалонку інтэрпрэтаваць імя файла. Будуйце шлях канфігурацыі з os.environ["HOME"] або pathlib.Path.home(), каб тыльду ніколі не даводзілася разгортваць. Калі вам сапраўды патрэбны сінтаксіс абалонкі, выкарыстоўвайце shlex.split, бо разбіццё радка праз .split() ламаецца на любым шляху з прабелам. Чытайце таксама stderr, бо OpenVPN запісвае туды большасць сваіх ранніх збояў.

Тое ж правіла датычыцца cron: радок задання — не лагін-абалонка, таму нішто не чытае ваш профіль і нішто не вызначае вашыя псеўданімы.

Што crontab насамрэч атрымлівае ў спадчыну

Запіс crontab атрымлівае тое асяроддзе, якое абвяшчае crontab, плюс некалькі ўспадкаваных значэнняў па змаўчанні, таму прапішыце шлях цалкам або абгарніце выклік скрыптам, які гэта робіць. Радок накшталт PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin уверсе файла пакрывае звычайныя месцы ўсталявання, і перанакіраванне праз >> cron.log 2>&1 — гэта тое, што робіць наступны збой чытэльным. Профіль, абаронены парольнай фразай, не мае як спытаць свой сакрэт пад cron, бо няма тэрмінала, дзе запытаць. Такое злучэнне належыць модулю systemd, які можа чытаць файл уліковых даных, а не заданню, якое прыкідваецца інтэрактыўным.

Адносныя шляхі — другая пастка. Тэставы запуск часта адбываецца з папкі, дзе ляжыць профіль, а заданне cron пачынаецца зусім у іншым месцы, таму --config office.ovpn вырашаецца ў файл, якога там няма, і паведамленне чытаецца як адсутны файл, а не адсутны тунель.

Дакажыце гэта, зняўшы асяроддзе

Аднавіце мінімальнае асяроддзе напрамкі: env -i PATH=/usr/bin:/bin /usr/sbin/openvpn --config office.ovpn --verb 4. Скарга на шлях або тэрмінал з гэтага запуску азначае, што праблема вышэй за VPN. Калі ён падключаецца, пакінутыя падазроныя — гэта ўліковы запіс, пад якім ён працуе, каталог, з якога ён стартуе, і ўліковыя даныя, якія ён падае. Любы з двух вынікаў лепш за чарговы круг праверкі сертыфікатаў.

Затым зрабіце абгортку самасправаздачнай. Выходзьце з асобным статусам для кожнага дасягнутага этапу, запісвайце абодва патоку з адзнакай часу, і наступны збой скажа вам, ці памёр ён на вырашэнні шляху, на аўтэнтыфікацыі ці пасля таго, як тунель ужо быў узняты.

Модулю таксама патрэбен правільны парадак: Wants=network-online.target плюс After=network-online.target не даюць кліенту стартаваць раней, чым з’явіцца адрас або маршрут па змаўчанні, што інакш выглядае як памылкі сертыфіката або TLS, якія знікаюць пры ручным перазапуску.