En el sitio de un cliente, el equipo de red agregó un firewall entre el cliente y el servidor. Esto hace que las conexiones inactivas se desconecten después de unos 40 minutos de inactividad. La gente de la red dice que el firewall no tiene ningún tiempo de espera de conexión inactiva, pero el hecho es que las conexiones inactivas se rompen.
Para evitar esto, primero configuramos el servidor (una máquina Linux) con TCP keepalives activado con tcp_keepalive_time = 300, tcp_keepalive_intvl = 300 y tcp_keepalive_probes = 30000. Esto funciona y las conexiones permanecen viables durante días o más. Sin embargo, también nos gustaría que el servidor detecte clientes muertos y elimine la conexión, por lo que cambiamos la configuración a tiempo = 300, intvl = 180, sondas = 10, pensando que si el cliente realmente estaba vivo, el servidor probaría cada 300 s (5 minutos) y el cliente respondería con un ACK y eso evitaría que el firewall lo vea como una conexión inactiva y lo elimine. Si el cliente estaba muerto, después de 10 sondas, el servidor abortaría la conexión. Para nuestra sorpresa, las conexiones inactivas pero vivas se matan después de unos 40 minutos como antes.
Wireshark que se ejecuta en el lado del cliente no muestra keepalives en absoluto entre el servidor y el cliente, incluso cuando los keepalives están habilitados en el servidor.
¿Qué podría estar pasando aquí?
Si la configuración de keepalive en el servidor es time = 300, intvl = 180, sondas = 10, esperaría que si el cliente está vivo pero inactivo, el servidor enviaría sondas de keepalive cada 300 segundos y dejaría la conexión sola, y si el el cliente está muerto, enviaría uno después de 300 segundos, luego 9 sondas más cada 180 segundos antes de cerrar la conexión. Estoy en lo cierto?
Una posibilidad es que el cortafuegos intercepte de alguna manera las sondas de mantenimiento del servidor y no las pase al cliente, y el hecho de que tenga una sonda hace pensar que la conexión está activa. ¿Es este comportamiento común para un firewall? No sabemos qué tipo de firewall está involucrado.
El servidor es un nodo de Teradata y la conexión es de una utilidad de cliente de Teradata al servidor de base de datos, puerto 1025 en el lado del servidor, pero hemos visto el mismo problema con una conexión SSH, por lo que creemos que afecta a todas las conexiones TCP.