La conexión SSH se congela en un punto de acceso 4G pero no en ningún Wifi

Question

Breve descripción

He estado viendo un comportamiento extraño en mi conexión SSH durante años, pero nunca pensé en plantear una pregunta hasta hoy. Intenté buscar mucho sobre esto pero no pude encontrar ningún motivo.

Ambiente

1. Básicamente, tengo varias instancias de AWS EC2 ejecutándose en diferentes regiones (como Irlanda, Mumbai, etc.).
2. Tengo una Mac.
3. Y estoy ubicado en la India (en caso de que a alguien se le ocurra alguna razón).

Planteamiento del problema 1

Cuando mi Mac está conectada a un punto de acceso personal (desde un dispositivo Samsung o desde un iPhone) a través de una red 4G, mi conexión SSH se congela después de unos minutos (no más de 3) si no trabajo en la sesión SSH (básicamente, el La conexión SSH fue ideal). Entonces tengo que seguir presionando la tecla de flecha solo para mantenerlo vivo.

Planteamiento del problema 2 (que no es un problema)

Pero cuando mi Mac está conectada a una conexión Wifi de banda ancha, este problema nunca ocurre. Mi conexión SSH permanece conectada durante horas incluso después de que despierto mi Mac del modo de suspensión (abro la tapa).

Basándome en mi búsqueda en Google nuevamente hoy, encontré varios artículos que brindan soluciones para usar opciones como TCPKeepAliveo ServerAliveInterval:

1. ¿Qué hacen exactamente las opciones `ServerAliveInterval` y `ClientAliveInterval` en sshd_config?
2. ¿Cómo funciona tcp-keepalive en ssh?
3. https://raspberrypi.stackexchange.com/questions/8311/ssh-connection-timeout-when-connecting
4. https://patrickmn.com/aside/how-to-keep-alive-ssh-sessions/

Pero no pude encontrar ninguna publicación que dicte este problema. ¿Alguien de ustedes tiene alguna idea sobre este comportamiento? Estaré encantado de brindarte cualquier detalle posible sobre mi conexión de punto de acceso 4G.

Answer 1

Supongo que un sistema que rastrea (y olvida) las conexiones con estado está causando esto. Cuando NAT está en uso (y es muy frecuente el caso cuando no está en IPv6), normalmente el sistema que realiza NAT necesita una memoria para recordar dónde enviar las respuestas. Para su banda ancha Wifi, el sistema que realiza NAT puede tener una memoria más larga para recordar conexiones activas (por ejemplo, Linuxfiltro de red'sconectarpor defecto recuerda las conexiones TCP durante 5 días, mientras que recuerda los flujos UDP durante 2 o 3 minutos). El sistema equivalente que realiza NAT en su ruta 4G probablemente tenga una memoria más corta, un poco menos de 3 minutos.

Para solucionar esto, como encontró y vinculó en su pregunta, puede configurar el parámetro ssh específicoServerAliveInterval que enviará datos vacíos (como protocolo SSH) periódicamente cuando no haya actividad de una manera similar aTCP mantener activo. Esto hará que la conexión siempre se vea como activa para el sistema que realiza NAT y no la olvidará. Entonces en tu ~/.ssh/configarchivo podrías agregar:

ServerAliveInterval 115

con 115, un valor elegido ligeramente inferior a 2 minutos para ser conservador: un valor inferior a la duración estimada de seguimiento de las conexiones activas en el dispositivo NAT invisible en la ruta, pero tampoco demasiado bajo (ver más adelante). De modo que, en el peor de los casos, cuando el estado de seguimiento está a 5 segundos de estar a punto de eliminarse, vuelve a la supuesta vida útil de 120 segundos.

El inconveniente es que (al menos en su acceso de banda ancha Wifi) si pierde la conectividad durante algún tiempo y luego la recupera, esto podría haber hecho que el cliente piense que el servidor remoto no funciona y habrá cerrado la conexión. También puedes modificarServerAliveCountMaxpara esto, pero de todos modos, si el valor predeterminado es 3, se requeriría algo así como 3*115=345 s de pérdida de conectividad, más de 5 minutos, antes de tener la posibilidad de tener este problema.

El lado del servidor tiene un equivalenteClientAliveIntervalque puedes configurar allí en su sshd_configarchivo, para el mismo propósito. Esto tendría el beneficio adicional de no mantener conexiones de clientes ssh fantasmas que se consideren todavía conectadas durante un período de tiempo cuando el lado del cliente perdió la conectividad de todos modos.