Reconnectar un túnel SSH SOCKS amb autossh
Feu servir autossh amb comprovacions de vida SSH tot entenent que reconnectar un túnel no restaura les connexions antigues de les aplicacions.
Un proxy SSH SOCKS desapareix quan acaba la seva connexió SSH. Un supervisor pot reiniciar aquesta connexió, però no pot reprendre cada petició de lloc web que feia servir el flux antic.
Per a una configuració SSH que ja funciona, autossh pot supervisar un reenviament dinàmic mentre OpenSSH detecta un servidor que no respon:
autossh -M 0 -N -o ServerAliveInterval=30 -o ServerAliveCountMax=3 -o ExitOnForwardFailure=yes -D 127.0.0.1:1080 [email protected]-M 0 desactiva el mecanisme separat de port de monitoratge d'autossh. Es basa en que SSH surti perquè el supervisor pugui reaccionar. Les opcions server-alive forneixen una comprovació de vida a nivell SSH; no demanen cap pàgina a cada destinació que feu servir.
Mantingueu la configuració inicial visible fins que l'autenticació i el reenviament funcionin. El comportament en segon pla d'autossh difereix del -f de l'SSH simple: un llançament no atès no es pot aturar per demanar una contrasenya o una frase de clau. La seva porta d'inici documentada també pot distingir una fallada immediata de configuració d'una sessió trencada més endavant.
Després de la reconnexió, l'oient local pot tornar a estar disponible. Les aplicacions encara poden necessitar reintentar les seves pròpies operacions fallides. Una pujada interrompuda abans de rebre una resposta té un resultat a nivell d'aplicació per resoldre, no només un túnel que falta per reiniciar.
Finalment, un transport SSH sa no demostra que la passarel·la pugui arribar a un lloc web concret. Separeu la supervisió del túnel del monitoratge de la feina que el fa servir.