OpenVPN kører i en shell, men fejler under cron: det er PATH

Den samme kommando forbinder fra en shell og dør under cron, så den naturlige konklusion er, at tunnelen eller certifikatet er skyld i det. Se på, hvad de to kørsler har til fælles, før du tror på det: binæren, konfigurationen og legitimationsoplysningerne er identiske, og kun processens miljø er ændret. Når programmet ikke engang bliver fundet, hjælper ingen mængde TLS-fejlfinding. Rettelsen ligger normalt i en sti, en arbejdsmappe og en håndfuld miljøvariabler, ikke i VPN’en.

command -v openvpn i den shell, der virker, udskriver svaret, og det er meget ofte /usr/sbin/openvpn, en mappe som cron ikke sætter på sin søgesti.

Tunnelen startede aldrig, så tunnelen er ikke problemet

Job, der startes af cron, arver et minimalt miljø, sædvanligvis PATH=/usr/bin:/bin, og ingen styrende terminal. Alt, der er installeret i /usr/sbin eller /usr/local/sbin, mangler ganske enkelt på den liste, og loglinjen siger openvpn: not found i stedet for en TLS-fejl. Pythons subprocess fejler anderledes: den arver miljøet fra fortolkerprocessen, som kan være rigere end crones, men stadig ikke har nogen shell til at udvide en tilde. Begge fejl sker, før en eneste pakke forlader værten.

En hurtig måde at skelne dem er at læse den første fejl i stedet for den sidste. En manglende binær giver en shell- eller Python-undtagelse, en dårlig konfiguration giver en OpenVPN-brugsmeddelelse, og en rigtig håndtryksfejl giver tidsstempler og peer-adresser. Kun den tredje er et tunnelproblem.

Absolutte stier og argumentlister slår shell-strenge

Send den opløste sti eksplicit og spring shellen helt over. subprocess.run(["/usr/sbin/openvpn", "--config", config, "--verb", "4"], capture_output=True, text=True, timeout=90) giver dig en returkode, stdout og stderr uden at bede en shell om at fortolke et filnavn. Byg konfigurationsstien ud fra os.environ["HOME"] eller pathlib.Path.home(), så en tilde aldrig skal udvides. Når du virkelig har brug for shell-syntaks, brug shlex.split, fordi opsplitning af en streng med .split() går i stykker på enhver sti, der indeholder et mellemrum. Læs også stderr, da OpenVPN skriver de fleste af sine tidlige fejl der.

Den samme regel gælder for cron: joblinjen er ikke en login-shell, så intet indlæser din profil, og intet definerer dine aliaser.

Hvad en crontab faktisk arver

En crontab-post får det miljø, crontab’en erklærer, plus nogle få arvede standarder, så skriv stien ud eller pak kaldet ind i et script, der gør det. En linje som PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin øverst i filen dækker de sædvanlige installationssteder, og omdirigering med >> cron.log 2>&1 er det, der gør den næste fejl læsbar. En adgangsfrasesbeskyttet profil har ingen måde at spørge om sin hemmelighed under cron, da der ikke findes nogen terminal at spørge på. Sådan en forbindelse hører i en systemd-enhed, der kan læse en legitimationsfil, ikke i et job, der foregiver at være interaktivt.

Relative stier er den anden fælde. En testkørsel sker ofte fra mappen, der rummer profilen, og et cron-job starter et helt andet sted, så --config office.ovpn peger på en fil, der ikke er der, og meddelelsen læses som en manglende fil snarere end en manglende tunnel.

Bevis det ved at skrælle miljøet af

Gengiv det minimale miljø direkte: env -i PATH=/usr/bin:/bin /usr/sbin/openvpn --config office.ovpn --verb 4. En klage over sti eller terminal fra den kørsel betyder, at problemet sidder oven over VPN’en. Hvis den forbinder, er de resterende mistænkte den konto, den kører som, den mappe, den starter i, og den legitimationsoplysning, den fremviser. Begge resultater er bedre end endnu en runde certifikatkontrol.

Gør derefter indpakningen selvrapporterende. Afslut med en særskilt status for hvert trin, den nåede, log begge strømme med et tidsstempel, og den næste fejl fortæller dig, om den døde ved stiopløsning, ved godkendelse eller efter at tunnelen allerede var oppe.

En enhed har også brug for korrekt rækkefølge: Wants=network-online.target plus After=network-online.target forhindrer klienten i at starte, før der findes en adresse eller standardrute, hvilket ellers viser sig som certifikat- eller TLS-fejl, der forsvinder ved en manuel genstart.