Sesiunea SSH moare odată cu VPN-ul: tmux sau un executant de sarcini?

Indicatorul VPN devine verde, ruta revine, iar fereastra SSH pe care ați lăsat-o deschisă nu mai returnează niciodată promptul. Restabilirea unei rute nu restabilește conversația TCP care o folosea, așa că tot ce s-a tastat în acea fereastră s-a pierdut. Dacă adevărata preocupare este un buffer de editor sau o migrare lungă, soluția este să nu mai legați acea muncă de o singură conexiune. tmux și un executant de sarcini rezolvă jumătăți diferite ale acelei probleme.

Un VPN reconectat nu reia socketul

TCP nu are noțiunea de reluare după o schimbare de adresă. Conexiunea SSH este identificată de ambele capete, iar când tunelul este reconstruit, adresa locală se poate schimba și vechiul socket este mort. Serverul observă acest lucru în cele din urmă, dar terminalul dumneavoastră îl observă imediat.

Un keepalive pe partea clientului detectează un partener mort mai devreme. Nu readuce sesiunea și nu poate recupera o comandă care rula deja. Keepalive este un detector, nu un instrument de recuperare. Nu spune nimic despre dacă comanda de la distanță a supraviețuit.

Puneți munca pe gazda de la distanță

Creați sesiunea pe gazda de la distanță, nu pe laptop. Conectați-vă ca de obicei, porniți tmux acolo și rulați editorul sau migrarea în interiorul lui. Detașați-vă cu prefixul implicit și sesiunea continuă să ruleze în timp ce conexiunea SSH dispare. Pornirea tmux local protejează shell-ul dumneavoastră de o fereastră închisă, nu o comandă de la distanță de un tunel mort.

ssh [email protected]
tmux new-session -s office-work

După ce VPN-ul revine, deschideți o conexiune SSH nouă către aceeași gazdă și reconectați-vă după nume. Obiectul durabil este sesiunea, nu conexiunea. Dați-i un nume pe care îl veți recunoaște și după o săptămână.

tmux față de un executant de sarcini

tmux menține în viață un proces interactiv cât timp gazda rulează. Un executant de sarcini sau un manager de servicii menține în viață o sarcină neinteractivă, îi înregistrează starea de ieșire și supraviețuiește terminării complete a sesiunii SSH. Primul este pentru munca pe care o urmăriți; al doilea pentru munca pe care o programați și o inspectați mai târziu.

Niciunul nu supraviețuiește unei reporniri, dacă gazda nu este configurată să îl restaureze. O sesiune tmux moare odată cu mașina, iar o sarcină temporară moare odată cu pornirea, dacă nu a fost înregistrată ca unitate. Alegeți în funcție de ceea ce trebuie să supraviețuiască munca.

Ambele abordări au nevoie și de un jurnal pe care să îl citiți după reconectare. Fără el, știți că procesul există, dar nu ce a făcut. Notați calea jurnalului lângă numele sesiunii.

Decideți după ceea ce trebuie să supraviețuiască

Decideți după cel mai rău lucru care se poate întâmpla dacă munca se oprește la jumătate. O sesiune de editor pierde bufferele nesalvate, ceea ce este enervant, dar recuperabil. O migrare care confirmă jumătate din modificările ei nu este, iar asta pledează pentru un executant cu un rezultat înregistrat. Dacă sarcina este interactivă și lungă, tmux plus un jurnal scris este de obicei suficient.

systemd-run --user --unit=migrate-customers --collect ./migrate.sh

Orice ați alege, inspectați rezultatul înregistrat înainte de a rula ceva din nou. O ultimă linie lipsă vă spune ce a văzut laptopul, nu ce a confirmat serverul. Această distincție este motivul pentru a ține munca în afara conexiunii de la bun început, iar modelul de detașare și reconectare este cea mai mică versiune a ei.