OpenVPN körs i ett skal men misslyckas under cron: det är PATH

Samma kommando ansluter från ett skal och dör under cron, så den naturliga slutsatsen är att tunneln eller certifikatet är skyldigt. Titta på vad de två körningarna har gemensamt innan du tror på det: binären, konfigurationen och inloggningsuppgifterna är identiska, och bara processens miljö har ändrats. När programmet inte ens hittas hjälper ingen mängd TLS-felsökning. Rättelsen ligger oftast i en sökväg, en arbetskatalog och en handfull miljövariabler, inte i VPN:en.

command -v openvpn i skalet som fungerar skriver ut svaret, och det är mycket ofta /usr/sbin/openvpn, en katalog som cron inte lägger på sin sökväg.

Tunneln startade aldrig, så tunneln är inte problemet

Jobb som startas av cron ärver en minimal miljö, vanligen PATH=/usr/bin:/bin, och ingen kontrollerande terminal. Allt som är installerat i /usr/sbin eller /usr/local/sbin saknas helt enkelt i den listan, och loggraden säger openvpn: not found i stället för ett TLS-fel. Pythons subprocess misslyckas annorlunda: den ärver tolkprocessens miljö, som kan vara rikare än crons men fortfarande inte har något skal som expanderar ett tilde. Båda felen inträffar innan ett enda paket lämnar värden.

Ett snabbt sätt att skilja dem åt är att läsa det första felet i stället för det sista. En saknad binär ger ett skal- eller Python-undantag, en dålig konfiguration ger ett OpenVPN-användningsmeddelande, och ett riktigt handskakningsfel ger tidsstämplar och peer-adresser. Bara det tredje är ett tunnelproblem.

Absoluta sökvägar och argumentlistor slår skalkommandon

Skicka den upplösta sökvägen explicit och hoppa över skalet helt. subprocess.run(["/usr/sbin/openvpn", "--config", config, "--verb", "4"], capture_output=True, text=True, timeout=90) ger dig en returkod, stdout och stderr utan att be ett skal tolka ett filnamn. Bygg konfigurationssökvägen från os.environ["HOME"] eller pathlib.Path.home(), så att ett tilde aldrig behöver expanderas. När du verkligen behöver skalsyntax, använd shlex.split, eftersom delning av en sträng med .split() går sönder på varje sökväg som innehåller ett mellanslag. Läs också stderr, eftersom OpenVPN skriver de flesta av sina tidiga fel där.

Samma regel gäller cron: jobbraden är inte ett inloggningsskal, så ingenting läser in din profil och ingenting definierar dina alias.

Vad en crontab faktiskt ärver

En crontab-post får den miljö som crontab-filen deklarerar plus några ärvda standardvärden, så skriv ut sökvägen eller linda in anropet i ett skript som gör det. En rad som PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin högst upp i filen täcker de vanliga installationsplatserna, och omdirigering med >> cron.log 2>&1 är det som gör nästa fel läsbart. En lösenordsfras-skyddad profil har ingen möjlighet att fråga efter sin hemlighet under cron, eftersom det inte finns någon terminal att fråga på. En sådan anslutning hör hemma i en systemd-enhet som kan läsa en inloggningsfil, inte i ett jobb som låtsas vara interaktivt.

Relativa sökvägar är den andra fällan. En testkörning sker ofta från mappen som innehåller profilen, och ett cron-jobb startar någon helt annanstans, så --config office.ovpn pekar på en fil som inte finns där och meddelandet läses som en saknad fil snarare än en saknad tunnel.

Bevisa det genom att skala av miljön

Återskapa den minimala miljön direkt: env -i PATH=/usr/bin:/bin /usr/sbin/openvpn --config office.ovpn --verb 4. Ett klagomål på sökväg eller terminal från den körningen betyder att problemet sitter ovanför VPN:en. Om den ansluter är de kvarvarande misstänkta kontot den körs som, katalogen den startar i och inloggningsuppgiften den presenterar. Båda resultaten är bättre än ännu en runda certifikatkontroll.

Gör sedan omslaget självrapporterande. Avsluta med en egen status för varje steg det nådde, logga båda strömmarna med tidsstämpel, och nästa fel berättar om det dog vid sökvägsupplösning, vid autentisering eller efter att tunneln redan var uppe.

En enhet behöver också rätt ordning: Wants=network-online.target plus After=network-online.target hindrar klienten från att starta innan en adress eller standardrutt finns, vilket annars visar sig som certifikat- eller TLS-fel som försvinner vid en manuell omstart.