¿Qué tiempos de inactividad aplican realmente los gateways NAT y balanceadores de carga habituales, y qué intervalo de keep-alive los supera?

Pregunta abierta

Las conexiones de larga duración (pools de bases de datos, suscripciones a colas de mensajes, sesiones WebSocket, túneles VPN) atraviesan dispositivos NAT y balanceadores de carga que eliminan las asignaciones inactivas. La RFC 4787 establece un mínimo de dos minutos para las asignaciones UDP y la RFC 5382 uno de 2 horas 4 minutos para las conexiones TCP establecidas. Sin embargo, son mínimos exigidos a los NAT que cumplen el estándar, no garantías sobre los dispositivos realmente desplegados: se informa con frecuencia de que los gateways NAT en la nube, los balanceadores de carga gestionados, los routers domésticos y los operadores móviles expiran las asignaciones mucho antes, y el valor por defecto de keep-alive en Linux, dos horas (tcp_keepalive_time), es mayor que cualquiera de ellos. Cuando una asignación expira, ninguno de los extremos se entera: según el dispositivo, la siguiente escritura se retransmite al vacío hasta que el temporizador de retransmisión se rinde, o bien un RST enviado por el middlebox corta la conexión de forma abrupta.

La pregunta tiene, por tanto, dos partes. ¿Qué tiempos de inactividad aplican hoy los gateways NAT en la nube, los balanceadores de carga gestionados, los routers domésticos y los operadores móviles de uso extendido, para TCP y para UDP por separado? Y ¿qué intervalos de keep-alive (ajustes TCP_KEEPIDLE por socket, pings a nivel de aplicación, pings de QUIC o de WebSocket) han demostrado mantener vivas las sesiones a través de esos dispositivos sin generar un tráfico que suponga en sí mismo un coste, por ejemplo en enlaces móviles con tarifa por consumo?

Qué contiene una respuesta útil

• El dispositivo o servicio, su configuración cuando sea relevante y la fecha de la observación, porque los tiempos de espera cambian entre generaciones de producto.
• El protocolo y el estado observados: TCP establecido, TCP transitorio (semiabierto o en cierre) y UDP tienen cada uno su propio temporizador en la RFC 4787 y la RFC 5382.
• El tiempo de espera documentado, citando la página del fabricante e indicando su URL, y el medido si ambos difieren.
• Si el dispositivo responde con un RST, con un error ICMP o con silencio a un paquete que llega a una asignación expirada; el silencio es el caso que deja colgados los pools de conexiones.
• El intervalo de keep-alive que funcionó y el más corto que no lo hizo, y cómo se realizó la medición, por ejemplo con conexiones inactivas de duración creciente seguidas de una escritura, repetidas las veces necesarias para descartar otras causas.
• Las anécdotas, identificadas como tales y separadas de los resultados medidos.