Depuración de conexiones TCP "obstruidas"

Tengo problemas con una conexión a Internet que parece "congelar" aleatoriamente las conexiones tcp arbitrarias cuando no se han utilizado durante un tiempo. Las conexiones permanecen establecidas, pero no se reciben datos.

Cuando esto sucede, netstat aún muestra el estado de la conexión como ESTABLISHEDen la computadora local:

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name Timer
tcp        0     53 192.168.0.10:41129      173.255.235.238:143     ESTABLISHED 8219/gnutls-cli  on (79.31/13/0)

..y el servidor remoto:

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name Timer
tcp        0      0 173.255.235.238:143     68.5.174.98:41129       ESTABLISHED 5303/imapd       off (0.00/0/0)

Sin embargo, parece que no se transfieren datos en absoluto. Si ejecuto strace en el proceso local y remoto, ambos solo muestran una secuencia repetitiva de llamadas seleccionadas (con diferentes fds, por supuesto), por ejemplo

select(6, [0 5], NULL, NULL, {0, 50000}) = 0 (Timeout)
select(6, [0 5], NULL, NULL, {0, 50000}) = 0 (Timeout)
select(6, [0 5], NULL, NULL, {0, 50000}) = 0 (Timeout)

La conexión a Internet en general no parece afectada, todavía puedo establecer nuevas conexiones al mismo servicio en el mismo servidor sin ningún problema. Sin embargo, las aplicaciones locales afectadas parecen ignorar el problema y simplemente se bloquean.

Aproximadamente 10 minutos después del intento de transmisión en el extremo local, la conexión en el extremo remoto desaparece del netstat (no pude detectar ningún estado intermedio), pero aún permanece ESTABLISHEDen el extremo local.

Finalmente, después de algunos minutos más, la aplicación local aborta con un tiempo de espera y también desaparece de la salida netstat local.

Cuando miro una captura de paquetes de esta conexión en el lado del cliente, hay un largo (esperado) período de inactividad que parece desencadenar el problema, luego el extremo local intenta transmitir algunos datos nuevamente pero nunca recibe un ACK. En cambio, salen 15 retransmisiones TCP, con intervalos que aumentan de 0.3 segundos a 120 segundos. No se captura ninguna actividad después de eso.

¿Alguien tiene una sugerencia de cómo podría depurar esto para averiguar dónde se encuentra el problema y cómo solucionarlo?

Además y / o como una solución temporal: ¿hay alguna forma de reducir globalmente el tiempo de espera en el cliente y / o servidor para reducir el tiempo antes de que la aplicación local aborte?

Resumiendo del hilo del usuario debian :

Estos síntomas son consistentes con algunos dispositivos NAT ubicados entre el cliente y el servidor y que dejan caer las conexiones inactivas después de 300 segundos.

Debe haber un dispositivo NAT en algún lugar de la cadena, porque la idea del cliente de su dirección IP (192.168.0.10) difiere de la que el servidor usa para enviar datos al cliente (68.5.174.98). Además, la red 192.168.xy está reservada para uso local.

Una solución alternativa es habilitar TCP keep-alive. Desafortunadamente, esto debe configurarse en cada programa por separado (por ejemplo, usando la ServerAliveIntervalopción en ssh). Sin embargo, en Linux, la biblioteca libkeepalive se puede usar LD_PRELOADpara activar la opción de socket necesaria incluso para programas que normalmente no la admiten.

Para mí, una mejor solución fue reemplazar la pasarela de cable responsable de Cisco DPC3825 con un módem de cable NetGear CMD31T y la pasarela NetGear WGR614v9. El primero también hace NAT, pero no tiene un tiempo de espera tan ridículamente corto.