TCP, establecimiento, cierre y temporizadores

TCP abre una conexión con tres mensajes: SYN, SYN-ACK y ACK. El cortafuegos con estado pasa por estados parecidos (en este laboratorio: SYN_ENVIADO, SYN_RECIBIDO y ESTABLECIDA) y solo da por válida la conversación al completarse. El cierre ordenado usa FIN en cada sentido; un RST la corta de golpe. Tras el cierre, muchos equipos conservan la entrada un rato corto para que los paquetes tardíos de esa conversación no abran otra por error. La definición del protocolo es la RFC 9293; los nombres de estado del cortafuegos son propios de cada fabricante.

Abre la consola y consulta paquetes. Sigue el flujo F-101 de principio a fin.

Una conexión puede estar bien establecida y, aun así, perder la entrada si pasa más tiempo del permitido sin que circule ningún paquete. Cuando la aplicación vuelve a hablar, su paquete llega a un cortafuegos que ya no recuerda nada. Ese paquete se descarta, y la aplicación lo vive como una conexión que «se queda colgada» hasta que agota sus propios reintentos.

En paquetes, localiza el flujo establecido cuyo último paquete aparece descartado por no tener sesión.

El temporizador de inactividad de las conexiones establecidas es el que borra una entrada sin tráfico. Un valor global corto protege la tabla; uno largo la expone. Por eso se prefiere ajustarlo por regla o por servicio cuando una aplicación lo necesita. Como referencia, la RFC 5382 pide a un NAT que, si abandona una conexión inactiva, no use un valor menor de 2 horas y 4 minutos para las establecidas; es una exigencia para NAT, y un cortafuegos de empresa puede fijar otra política, pero debe hacerlo sabiendo qué aplicaciones se afectan.

Consulta temporizadores y lee el valor de las conexiones establecidas.

Para explicar un corte hay que comparar la inactividad real con el temporizador. En el flujo del ERP hacia el servidor de base de datos, mide el tiempo entre el último paquete que circuló con normalidad y el que se descartó. Si supera el temporizador de la tarea anterior, la causa del síntoma está explicada por el reloj y no por un fallo de red.

Hay dos caminos sanos. El primero es que la aplicación envíe señales de actividad (paquetes de mantenimiento de conexión) a un intervalo menor que el temporizador. El segundo es subir el temporizador solo en la regla del ERP hacia la base de datos, y no globalmente: así la tabla no se llena de entradas viejas de todo el mundo. Cualquiera de los dos se registra como cambio y se prueba. Lo que no se hace es dejar el valor global enorme «por si acaso».