O sarcină programată care a rulat fără VPN pare în regulă

Starea sarcinii spune succes, jurnalul arată o rulare finalizată, iar datele sunt învechite sau lipsesc. Această combinație înseamnă de obicei că sarcina programată a pornit fără calea de care avea nevoie, iar ceva mai jos a înghițit eșecul. Un program care se declanșează la timp nu spune nimic despre faptul că rețeaua era pregătită. Exact în golul dintre aceste două fapte trăiește acest eșec.

Admiterea aparține rulării, nu existenței unui fișier cron.

O rulare verde nu este o sarcină finalizată

Un planificator notează că un proces a pornit și apoi a ieșit; nu are habar dacă procesul a ajuns la resursa pentru care există. Un script care tratează o conexiune eșuată ca rezultat gol, sau prinde o eroare și iese cu zero, va arăta sănătos pentru totdeauna. Simptomul nu este o stare roșie; este o stare plauzibilă atașată de muncă lipsă.

Numiți de ce are nevoie de fapt rularea înainte de a decide cum o verificați. O copie de siguranță poate avea nevoie de DNS privat și de un punct final autentificat, nu doar de un proces de tunel.

Verificați conexiunea, nu numele interfeței

O interfață numită tun0 poate exista fără sesiunea care contează, iar o altă conexiune poate deține acel nume. Verificați obiectul concret de care depinde sarcina: o identitate de profil, o instanță de serviciu sau o mică operațiune aprobată împotriva resursei. Țineți verificarea limitată în timp și țineți acreditările în afara argumentelor procesului și a jurnalelor de diagnostic.

Definiți și rezultatul deconectării. O săritură obișnuită, o reîncercare într-o fereastră scurtă și un termen ratat vizibil operatorului sunt trei răspunsuri diferite, iar un program recurent nu alege între ele.

Săriturile și eșecurile sunt rezultate diferite

[Service]
Type=oneshot
User=worker
ExecCondition=/usr/local/libexec/check-office-path
ExecStart=/usr/local/bin/private-task

Într-o implementare systemd, ExecCondition= rulează acel verificator înainte de sarcina de lucru. Comportamentul său la ieșire este specific: zero continuă, codurile de la unu la 254 sar peste comenzile de pornire rămase fără a marca unitatea ca eșuată, iar 255 sau o terminare anormală o fac să eșueze. Asta oferă trei semnale distincte, utile doar dacă contractul verificatorului este mapat deliberat pe ele. Setările care redefinesc succesul pot schimba imaginea, așa că documentați maparea.

Înregistrarea săriturilor este cea care face proiectarea onestă. O rulare sărită care nu apare nicăieri este imposibil de distins de o rulare reușită, iar tratarea fiecărei erori a verificatorului ca o săritură tăcută ascunde la nesfârșit o implementare defectă.

Protejați întreaga rulare, nu doar începutul

O verificare de pregătire observă lumea înainte de lansare; nu supraveghează fiecare socket după aceea. Când o cale directă nu este niciodată acceptabilă pentru această sarcină, atașați o politică de ieșire aprobată, aplicată continuu și care acoperă DNS, IPv6 și transportul propriu al tunelului. Comutarea stării globale IPv6 a gazdei nu înlocuiește o politică limitată la sarcină.

Decideți dacă un eveniment nou poate suprapune o sarcină încă în curs, păstrați regula la proprietarul sarcinii de lucru și faceți reîncercarea sigură pentru operațiunea pe date. Oprirea unei sarcini la deconectare limitează munca fără a garanta nimic despre traficul de rezervă.

Acceptați fluxul de lucru în trei cazuri: cale pregătită, cale indisponibilă și pierdere în timpul rulării. Orice mai puțin testează programarea, nu sarcina.