Tengo una conexión de red poco confiable entre dos máquinas: a veces las conexiones TCP activas se cortan por razones que escapan a mi control. Quiero establecer una conexión TCP confiable entre las dos máquinas.
Si la red fuera confiable, simplemente me ejecutaría ssh -L 1234:localhost:1234 remotehost
, con el servidor escuchando en el puerto 1234 remotehost
, y señalaría al cliente localhost:1234
. Pero si la conexión ssh muere, también lo hará la conexión reenviada. ¿Cómo puedo organizar la restauración automática de la conexión entre el cliente y el servidor?
No soluciones:
- Esto no es para aplicaciones interactivas, por lo que la pantalla no se aplica.
- Esto no se trata solo de volver a conectar un túnel SSH automáticamente, la autossh . Quiero continuar usando la misma conexión TCP tunelizada, no iniciar una nueva.
- En principio, una VPN haría el truco. Pero parece excesivo cuando solo quiero una conexión TCP, y me gustaría una solución que funcione incluso si no tengo permisos de root en ninguno de los lados.
Tengo un vago recuerdo de un programa llamado rocks
que hizo exactamente eso, pero parece haberse caído de la web. Estoy principalmente interesado en Linux en ambos lados (aunque esperaría que un programa en este nivel sea portátil para otros dispositivos), pero si conoce un programa que funcione entre QNX y VMS, mucho mejor.
scp
. Estaba respondiendo w / ssh keepalives basado en su ejemplo de reenvío de puertos. Re: escamoso salto aguas abajo, no hay mucho que puedas hacer, aparte de crear una sesión ssh con keepalives que sean más tolerantes (es decir, permitir más keepalives caídos conServerAliveInterval > 0
yServerAliveCountMax > 3
). NAT requiere intervalos de keepalives más bajos. La cuestión clave es identificar cuál es el problema y adaptarlo en consecuencia. Ponga las opciones.ssh/config
para que siempre estén ahí para ustedrocks
implementación ... aunque esto es obviamente un verdadero errorRespuestas:
¿Es el viejo un Sockets ( Rocks ) confiable sin mantenimiento lo que está buscando?
fuente
El único protocolo estándar que conozco con esta capacidad es MPTCP . Es transparente para la capa de aplicación, por lo que SSH además de MPTCP debería funcionar. Puede ejecutar las conexiones TCP subyacentes en diferentes rutas con diferentes IP, por lo que, en principio, podría usarse para migrar su conexión SSH dentro y fuera de la conexión VPN dependiendo de si la conexión VPN está activa.
No sé mucho sobre la madurez de las implementaciones de MPTCP, pero el diseño del protocolo parece bastante robusto.
Debe proteger sus conexiones SSH para que no se pierdan debido a la conectividad de red débil. No lo protegerá contra un mitm que quiera interrumpir su conexión SSH. Un mitm aún puede inyectar datos corruptos, que SSH detectará y romperá la conexión.
Un método de reconexión MPTCP integrado en el protocolo SSH sería el método que podría imaginar mantener viva una conexión durante el mayor tiempo posible. Pero no creo que tal característica haya sido diseñada para el protocolo SSH.
fuente
Puede usar
daemontools
para mantener el puerto ssh hacia adelante; no necesariamente mantendrá los programas dependiendo de la conexión activa mientras esté inactiva (como presumiblemente cuando ssh se desconecta, el puerto local comenzará a rechazar sus conexiones), pero es un comienzo.Sospecho que hay algunos
iptables
trucos, como hacer que ese puerto DROP paquetes tan pronto como el ssh forward desaparezca, por lo que los programas de conexión solo saben que los paquetes están desapareciendo, no siendo rechazados. Solo estoy aprendiendo adaemontools
mí mismo (nuevamente), así que no estoy seguro de si puede ejecutar un script personalizado cuando un servicio muere, pero sospecho que puede hacerlo.fuente
TCP hace esto automáticamente. Solo necesita deshabilitar o debilitar los hacks de limpieza prácticos típicos utilizados para eliminar conexiones TCP moribundas. Deshabilite TCP keepalive para su conexión y aumente considerablemente el límite para retransmisiones excesivas. En Linux, por ejemplo, escriba un gran número en
/proc/sys/net/ipv4/tcp_retries2
.Sin embargo, en una red moderna, un firewall de inspección de paquetes con estado puede olvidarse de una conexión TCP que no puede intercambiar paquetes regularmente, por lo que puede llover en su desfile.
fuente
reasons beyond my control
, que leí como IP dinámica o middleboxes con estado. En tales escenarios, TCP keepalive puede ayudar un poco. Pero no importa cómo configure TCP keepalive, no será suficiente para mantener viva la conexión cuando un middlebox pierde estado debido a que se reinicia.