Reconectarea unui tunel SSH SOCKS cu autossh
Folosiți autossh cu verificări de vitalitate SSH și înțelegeți că reconectarea unui tunel nu restaurează conexiunile vechi ale aplicațiilor.
Un proxy SSH SOCKS dispare când conexiunea sa SSH se termină. Un supraveghetor poate reporni acea conexiune, dar nu poate relua fiecare cerere către un site care folosea fluxul vechi.
Pentru o configurație SSH care funcționează deja, autossh poate supraveghea un redirecționare dinamică în timp ce OpenSSH detectează un server care nu răspunde:
autossh -M 0 -N -o ServerAliveInterval=30 -o ServerAliveCountMax=3 -o ExitOnForwardFailure=yes -D 127.0.0.1:1080 [email protected]-M 0 dezactivează mecanismul separat de port de monitorizare al autossh. Se bazează pe ieșirea SSH pentru ca supraveghetorul să poată reacționa. Opțiunile server-alive oferă o verificare de vitalitate la nivel de SSH; ele nu cer o pagină de la fiecare destinație pe care o folosiți.
Țineți configurația inițială vizibilă până când autentificarea și redirecționarea funcționează. Comportamentul în fundal al autossh diferă de -f din SSH simplu: o lansare nesupravegheată nu se poate opri pentru a cere o parolă sau o frază de cheie. Poarta sa de pornire documentată poate distinge, de asemenea, un eșec imediat de configurare de o sesiune întreruptă mai târziu.
După reconectare, ascultătorul local poate redeveni disponibil. Aplicațiile pot avea în continuare nevoie să reîncerce propriile operații eșuate. Un transfer întrerupt înainte de a primi un răspuns are un rezultat la nivel de aplicație de rezolvat, nu doar un tunel lipsă de repornit.
În cele din urmă, un transport SSH sănătos nu dovedește că poarta poate ajunge la un anumit site. Separați supravegherea tunelului de monitorizarea sarcinii care îl folosește.