Riconnettere un tunnel SSH SOCKS con autossh
Usate autossh con controlli di vitalità SSH, sapendo che riconnettere un tunnel non ripristina le vecchie connessioni delle applicazioni.
Un proxy SSH SOCKS scompare quando la sua connessione SSH termina. Un supervisore può riavviare quella connessione, ma non può riprendere ogni richiesta a un sito web che usava il vecchio flusso.
Per una configurazione SSH già funzionante, autossh può sorvegliare un inoltro dinamico mentre OpenSSH rileva un server che non risponde:
autossh -M 0 -N -o ServerAliveInterval=30 -o ServerAliveCountMax=3 -o ExitOnForwardFailure=yes -D 127.0.0.1:1080 [email protected]-M 0 disattiva il meccanismo separato di porta di monitoraggio di autossh. Esso conta sull'uscita di SSH perché il supervisore possa reagire. Le opzioni server-alive forniscono un controllo di vitalità a livello SSH; non richiedono una pagina a ogni destinazione che usate.
Tenete visibile la configurazione iniziale finché autenticazione e inoltro non funzionano. Il comportamento in background di autossh differisce da -f del semplice SSH: un avvio non presidiato non può fermarsi per chiedere una password o una passphrase della chiave. La sua porta di avvio documentata può anche distinguere un guasto immediato di configurazione da una sessione interrotta più tardi.
Dopo la riconnessione, l'ascoltatore locale può tornare disponibile. Le applicazioni potrebbero comunque dover ritentare le proprie operazioni fallite. Un caricamento interrotto prima di ricevere una risposta ha un esito a livello applicativo da risolvere, non solo un tunnel mancante da riavviare.
Infine, un trasporto SSH sano non dimostra che il gateway possa raggiungere un sito web specifico. Separate la sorveglianza del tunnel dal monitoraggio del lavoro che lo usa.