Tā pati komanda savienojas no čaulas un mirst zem cron, tāpēc dabiskais secinājums ir, ka vainīgs ir tunelis vai sertifikāts. Pirms tam noticēt, paskatieties, kas abiem palaidieniem ir kopīgs: binārais fails, konfigurācija un akreditācijas dati ir identiski, un mainījusies ir tikai procesa vide. Kad programma pat netiek atrasta, nekāds TLS atkļūdošanas apjoms nepalīdz. Labojums parasti ir ceļā, darba direktorijā un saujā vides mainīgo, nevis VPN.

command -v openvpn strādājošajā čaulā izdrukā atbildi, un tas ļoti bieži ir /usr/sbin/openvpn, direktorija, ko cron neiekļauj savā meklēšanas ceļā.

Tunelis nekad nesākās, tāpēc tunelis nav problēma

cron palaistie darbi manto minimālu vidi, parasti PATH=/usr/bin:/bin, un tiem nav vadošā termināļa. Viss, kas instalēts /usr/sbin vai /usr/local/sbin, vienkārši neparādās šajā sarakstā, un žurnāla rinda rāda openvpn: not found TLS kļūdas vietā. Python subprocess neizdodas citādi: tas manto interpretatora procesa vidi, kas var būt bagātāka par cron, bet joprojām tai nav čaulas, kas izvērstu tildi. Abas kļūmes notiek pirms tam, kad kāda pakete atstāj resursdatoru.

Ātrs veids, kā tās atšķirt, ir lasīt pirmo kļūdu, nevis pēdējo. Trūkstošs binārais fails rada čaulas vai Python izņēmumu, slikta konfigurācija rada OpenVPN lietošanas ziņojumu, bet īsta rokasspiediena kļūme rada laika zīmes un partnera adreses. Tikai trešā ir tuneļa problēma.

Absolūtie ceļi un argumentu saraksti pārspēj čaulas virknes

Nododiet atrisināto ceļu tieši un pilnībā izlaidiet čaulu. subprocess.run(["/usr/sbin/openvpn", "--config", config, "--verb", "4"], capture_output=True, text=True, timeout=90) dod atgriešanas kodu, stdout un stderr, neprasot čaulai interpretēt faila nosaukumu. Veidojiet konfigurācijas ceļu no os.environ["HOME"] vai pathlib.Path.home(), lai tilde nekad nebūtu jāizvērš. Kad tiešām vajag čaulas sintaksi, izmantojiet shlex.split, jo virknes sadalīšana ar .split() salūzt jebkurā ceļā ar atstarpi. Lasiet arī stderr, jo OpenVPN tur raksta lielāko daļu savu agrīno kļūmju.

Tas pats noteikums attiecas uz cron: darba rinda nav pieteikšanās čaula, tāpēc nekas neielādē jūsu profilu un nekas nedefinē jūsu aizstājvārdus.

Ko crontab patiešām manto

crontab ieraksts saņem to vidi, ko deklarē crontab, plus dažas mantotas noklusējuma vērtības, tāpēc izrakstiet ceļu vai ietiniet izsaukumu skriptā, kas to dara. Rinda kā PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin faila augšā aptver ierastās instalācijas vietas, un pāradresācija ar >> cron.log 2>&1 ir tas, kas padara nākamo kļūmi lasāmu. Ar paroli aizsargātam profilam zem cron nav iespējas pajautāt savu noslēpumu, jo nav termināļa, kur jautāt. Šāds savienojums pieder systemd vienībai, kas var nolasīt akreditācijas datu failu, nevis darbam, kas izliekas par interaktīvu.

Relatīvie ceļi ir otrais slazds. Testa palaidiene bieži notiek no mapes, kurā ir profils, bet cron darbs sākas pavisam citur, tāpēc --config office.ovpn atrisinās uz failu, kura tur nav, un ziņojums tiek lasīts kā trūkstošs fails, nevis trūkstošs tunelis.

Pierādiet to, noņemot vidi

Atveidojiet minimālo vidi tieši: env -i PATH=/usr/bin:/bin /usr/sbin/openvpn --config office.ovpn --verb 4. Sūdzība par ceļu vai termināli no šīs palaidienes nozīmē, ka problēma atrodas virs VPN. Ja tas savienojas, atlikušie aizdomās turamie ir konts, ar kuru tas darbojas, direktorija, kurā tas sākas, un akreditācijas dati, ko tas uzrāda. Jebkurš no diviem rezultātiem ir labāks par vēl vienu sertifikātu pārbaudes kārtu.

Pēc tam padariet ietvaru pašziņojošu. Izejiet ar atsevišķu statusu katram sasniegtajam posmam, reģistrējiet abas plūsmas ar laika zīmi, un nākamā kļūme pateiks, vai tas nomira ceļa atrisināšanā, autentifikācijā vai pēc tam, kad tunelis jau bija pacelts.

Vienībai vajadzīga arī pareiza secība: Wants=network-online.target kopā ar After=network-online.target neļauj klientam startēt pirms adreses vai noklusējuma maršruta parādīšanās, kas citādi izpaužas kā sertifikāta vai TLS kļūdas, kas pazūd manuālas restartēšanas laikā.

Saistītie raksti