Reconnecter un tunnel SSH SOCKS avec autossh
Utilisez autossh avec des contrôles de vivacité SSH en gardant à l'esprit que reconnecter un tunnel ne rétablit pas les anciennes connexions des applications.
Un proxy SSH SOCKS disparaît lorsque sa connexion SSH se termine. Un superviseur peut redémarrer cette connexion, mais il ne peut pas reprendre chaque requête de site web qui utilisait l'ancien flux.
Pour une configuration SSH déjà fonctionnelle, autossh peut superviser un transfert dynamique pendant qu'OpenSSH détecte un serveur qui ne répond plus :
autossh -M 0 -N -o ServerAliveInterval=30 -o ServerAliveCountMax=3 -o ExitOnForwardFailure=yes -D 127.0.0.1:1080 [email protected]-M 0 désactive le mécanisme distinct de port de surveillance d'autossh. Il compte sur la sortie de SSH pour que le superviseur puisse réagir. Les options server-alive fournissent un contrôle de vivacité au niveau SSH ; elles ne demandent pas de page à chaque destination que vous utilisez.
Gardez la configuration initiale visible jusqu'à ce que l'authentification et le transfert fonctionnent. Le comportement en arrière-plan d'autossh diffère de -f du SSH simple : un lancement sans surveillance ne peut pas s'arrêter pour demander un mot de passe ou une phrase de passe de clé. Sa porte de démarrage documentée peut aussi distinguer un échec immédiat de configuration d'une session interrompue plus tard.
Après la reconnexion, l'écouteur local peut redevenir disponible. Les applications peuvent néanmoins devoir réessayer leurs propres opérations échouées. Un envoi interrompu avant de recevoir une réponse a un résultat au niveau applicatif à résoudre, pas seulement un tunnel manquant à redémarrer.
Enfin, un transport SSH sain ne prouve pas que la passerelle peut atteindre un site web donné. Séparez la supervision du tunnel de la surveillance de la tâche qui l'utilise.