Un proxy SSH SOCKS desaparece cuando termina su conexión SSH. Un supervisor puede reiniciar esa conexión, pero no puede reanudar cada solicitud de sitio web que usaba el flujo antiguo.

Para una configuración SSH que ya funciona, autossh puede supervisar un reenvío dinámico mientras OpenSSH detecta un servidor que no responde:

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 mecanismo separado de puerto de monitorización de autossh. Se apoya en que SSH salga para que el supervisor pueda reaccionar. Las opciones server-alive proporcionan una comprobación de vida a nivel de SSH; no solicitan una página a cada destino que utilice.

Mantenga visible la configuración inicial hasta que funcionen la autenticación y el reenvío. El comportamiento en segundo plano de autossh difiere del -f del SSH simple: un lanzamiento sin supervisión no puede detenerse para pedir una contraseña o una frase de clave. Su puerta de inicio documentada también puede distinguir un fallo inmediato de configuración de una sesión rota más tarde.

Tras la reconexión, el oyente local puede volver a estar disponible. Puede que las aplicaciones aún necesiten reintentar sus propias operaciones fallidas. Una carga interrumpida antes de recibir una respuesta tiene un resultado a nivel de aplicación que resolver, no solo un túnel ausente que reiniciar.

Por último, un transporte SSH sano no demuestra que la puerta de enlace pueda alcanzar un sitio web concreto. Separe la supervisión del túnel de la monitorización del trabajo que lo usa.

Artículos relacionados