Dieselfde opdrag verbind uit ’n dop en sterf onder cron, so die natuurlike gevolgtrekking is dat die tonnel of die sertifikaat fout is. Kyk eers wat die twee lopies gemeen het voordat jy dit glo: die binêre lêer, die konfigurasie en die geloofsbriewe is identies, en net die prosesomgewing het verander. Wanneer die program nie eers gevind word nie, help geen hoeveelheid TLS-ontfouting nie. Die oplossing lê gewoonlik in ’n pad, ’n werkmap en ’n handvol omgewingsveranderlikes, nie in die VPN nie.

command -v openvpn in die dop wat werk, druk die antwoord, en dit is baie dikwels /usr/sbin/openvpn, ’n gids wat cron nie op sy soekpad sit nie.

Die tonnel het nooit begin nie, dus is die tonnel nie die probleem nie

Take wat deur cron begin word, erf ’n minimale omgewing, gewoonlik PATH=/usr/bin:/bin, en geen beherende terminaal nie. Enigiets wat in /usr/sbin of /usr/local/sbin geïnstalleer is, is bloot afwesig uit daardie lys, en die logreël lees openvpn: not found in plaas van ’n TLS-fout. Python se subprocess misluk anders: dit erf die omgewing van die interpreteerderproses, wat ryker as cron se een kan wees maar steeds geen dop het om ’n tilde uit te brei nie. Albei mislukkings gebeur voordat ’n enkele pakket die gasheer verlaat.

’n Vinnige manier om hulle uitmekaar te hou, is om die eerste fout te lees in plaas van die laaste. ’n Ontbrekende binêre lêer lewer ’n dop- of Python-uitsondering, ’n slegte konfigurasie lewer ’n OpenVPN-gebruikboodskap, en ’n werklike handdrukfout lewer tydstempels en eweknie-adresse. Net die derde een is ’n tonnelprobleem.

Absolute paadjies en argumentlyste klop dopstringe

Gee die opgeloste pad eksplisiet en slaan die dop heeltemal oor. subprocess.run(["/usr/sbin/openvpn", "--config", config, "--verb", "4"], capture_output=True, text=True, timeout=90) gee jou ’n terugkeerkode, stdout en stderr sonder om ’n dop te vra om ’n lêernaam te interpreteer. Bou die konfigurasiepad uit os.environ["HOME"] of pathlib.Path.home(), sodat ’n tilde nooit uitgebrei hoef te word nie. Wanneer jy werklik dopsinntaks nodig het, gebruik shlex.split, want om ’n string met .split() te split breek op enige pad wat ’n spasie bevat. Lees ook stderr, want OpenVPN skryf die meeste van sy vroeë mislukkings daar.

Dieselfde reël geld vir cron: die werklyn is nie ’n aanmelddop nie, so niks laai jou profiel nie en niks definieer jou aliasse nie.

Wat ’n crontab werklik erf

’n Inskrywing in ’n crontab kry alles wat die crontab verklaar plus ’n paar geërfde verstekke, so spel die pad uit of draai die oproep in ’n skrip wat dit doen. ’n Reël soos PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin boaan die lêer dek die gewone installasieplekke, en herlei met >> cron.log 2>&1 is wat die volgende mislukking leesbaar maak. ’n Profiel met ’n wagfrase het geen manier om onder cron om sy geheim te vra nie, want daar bestaan geen terminaal om op te vra nie. So ’n verbinding hoort in ’n systemd-eenheid wat ’n geloofsbrieflêer kan lees, nie in ’n werk wat voorgee dat dit interaktief is nie.

Relatiewe paadjies is die tweede valstrik. ’n Toetsloop gebeur dikwels uit die gids wat die profiel bevat, en ’n cron-werk begin heeltemal elders, so --config office.ovpn wys na ’n lêer wat nie daar is nie en die boodskap lees as ’n ontbrekende lêer eerder as ’n ontbrekende tonnel.

Bewys dit deur die omgewing te stroop

Reproduseer die minimale omgewing direk: env -i PATH=/usr/bin:/bin /usr/sbin/openvpn --config office.ovpn --verb 4. ’n Pad- of terminaalklag uit daardie lopie beteken die probleem sit bo die VPN. As dit verbind, is die oorblywende verdagtes die rekening waaronder dit loop, die gids waarin dit begin, en die geloofsbrief wat dit voorlê. Enige van die twee uitkomste klop nog ’n rondte sertifikaatkontrole.

Maak dan die wikkel selfrapporterend. Sluit af met ’n afsonderlike status vir elke stadium wat dit bereik het, teken albei strome met ’n tydstempel aan, en die volgende mislukking vertel jou of dit by padoplossing, by verifikasie of nadat die tonnel reeds op was, doodgegaan het.

’n Eenheid het ook korrekte ordening nodig: Wants=network-online.target plus After=network-online.target hou die kliënt daarvan weg om te begin voordat ’n adres of verstekroete bestaan, wat anders na vore kom as sertifikaat- of TLS-foute wat by ’n handmatige herbegin verdwyn.

Verwante artikels