¿Qué provoca que se envíe un indicador de restablecimiento de TCP / IP (RST)?

123

Estoy tratando de averiguar por qué la conexión TCP / IP de mi aplicación sigue fallando cada 10 minutos (exactamente, en 1-2 segundos). Ejecuté Wireshark y descubrí que después de 10 minutos de inactividad, el otro extremo está enviando un paquete con el indicador de reinicio (RST) configurado. Una búsqueda en Google me dice que "la bandera RESET significa que el receptor se ha confundido y, por lo tanto, quiere cancelar la conexión", pero eso es un poco menos que el detalle que necesito. ¿Qué podría estar causando esto? ¿Y es posible que algún enrutador en el camino sea responsable de ello o esto siempre vendría del otro punto final?

Editar: Hay un enrutador (específicamente un Linksys WRT-54G) entre mi computadora y el otro punto final.¿Hay algo que deba buscar en la configuración del enrutador?

networking tcp

— Luke
fuente

12

Aquí hay otro: Comcast

— Tom Ritter

1

Je, afortunadamente, no tengo una dependencia de Comcast ya que esto ocurre dentro de una LAN. Ojalá pudiera echar la culpa tan fácilmente aunque;)

— Lucas

alguna vez te lo imaginate? No puedo comentar porque no tengo suficientes puntos, pero tengo exactamente el mismo problema que tú y estoy buscando una solución.

¿A qué servicio se refiere este caso particular? Es posible establecer keepalive en el socket (desde el nivel de la aplicación) para que los períodos de inactividad prolongados no resulten en que alguien (en el medio o no) intente forzar un restablecimiento de la conexión por falta de recursos.

— Arielf

¿"Comcast" dices? : D Consulte este repositorio relacionado: github.com/tylertreat/comcast

— joonas.fi

89

Un 'enrutador' podría estar haciendo cualquier cosa, particularmente NAT, que podría involucrar cualquier cantidad de errores en el tráfico ...

Una razón por la que un dispositivo enviará un RST es en respuesta a recibir un paquete para un socket cerrado.

Es difícil dar una respuesta firme pero general, porque todas las posibles perversiones han sido visitadas en TCP desde sus inicios, y todo tipo de personas podrían estar insertando RST en un intento de bloquear el tráfico. (Algunos 'firewalls nacionales' funcionan así, por ejemplo).

— Will Dean
fuente

6

El enrutador tiene un tiempo de espera de 10 minutos para las conexiones TCP o el enrutador tiene habilitada la "detección inteligente de paquetes de puerta de enlace".

— David Schwartz

2

Es un poco interesante sugerir que un enrutador puede tener errores.

— Marqués de Lorne

23

Ejecute un rastreador de paquetes (por ejemplo, Wireshark) también en el par para ver si es el par quien envía el RST o alguien en el medio.

— Alejandro
fuente

14

Acabo de pasar bastante tiempo solucionando este mismo problema. Ninguna de las soluciones propuestas funcionó. Resultó que nuestro administrador de sistemas asignó por error la misma IP estática a dos servidores no relacionados que pertenecen a diferentes grupos, pero que se encuentran en la misma red. Los resultados finales fueron conexiones vnc interrumpidas de forma intermitente, navegador que tuvo que actualizarse varias veces para recuperar la página web y otras cosas extrañas.

— OutputLogic
fuente

7

Algunos cortafuegos hacen eso si una conexión está inactiva durante x minutos. Algunos ISP configuran sus enrutadores para hacerlo también por varias razones.

En esta época, deberá manejar con elegancia (restablecer según sea necesario) esa condición.

— Brian Knoblauch
fuente

2

La conexión se restablece sin problemas, el problema es que el breve período de desconexión genera una alerta innecesariamente.

— Lucas

1

He tenido problemas específicamente con el equipo Cisco PIX / ASA. Tienen tiempos de espera especialmente cortos como valores predeterminados. El equipo más barato suele ser "mejor" en este sentido (ya que no se agota el tiempo de espera muy rápido) ...

— Brian Knoblauch

1

Incluso agregaría que TCP nunca fue realmente completamente confiable desde el punto de vista de las conexiones persistentes. Simplemente se vuelve más notorio de vez en cuando. Otro ejemplo interesante: algunas personas pueden implementar una lógica que marca a un cliente TCP como fuera de línea tan pronto como se detecta el cierre o reinicio de la conexión. Y luego, a veces, no se molestan en darle a un cliente la oportunidad de volver a conectarse. Obviamente, esto no es del todo correcto.

— Victor Yarema hace

7

RST es enviado por el lado que realiza el cierre activo porque es el lado que envía el último ACK. Entonces, si recibe FIN del lado que realiza el cierre pasivo en un estado incorrecto, envía un paquete RST que indica al otro lado que ha ocurrido un error.

— Vishal gupta
fuente

6

Ambas partes envían y reciben una FIN en un cierre normal. No hay nada de malo en esta situación y, por lo tanto, no hay razón para que una de las partes emita un reinicio. La primera oración ni siquiera tiene sentido.

— Marqués de Lorne

2

[RST, ACK] también puede ser enviado por el lado que recibe un SYN en un puerto que no se está escuchando. En un caso que encontré, el RST / ACK se produjo unos 60 segundos después del primer SYN. FWIW

— Les

@MarquisofLorne, la primera oración en sí puede tratarse como incorrecta. Pero la frase "en un estado incorrecto" en la segunda oración la hace de alguna manera válida.

— Victor Yarema hace

7

Si hay un enrutador que hace NAT, especialmente un enrutador de gama baja con pocos recursos, envejecerá primero las sesiones TCP más antiguas. Para hacer esto, establece la RSTbandera en el paquete que efectivamente le dice a la estación receptora que cierre la conexión (de manera muy poco elegante). esto se hace para ahorrar recursos.

— MKII
fuente

3

Una cosa a tener en cuenta es que muchos firewalls netfilter de Linux están mal configurados.

Si tienes algo como:

-A FORWARD -m estado --state RELACIONADO, ESTABLECIDO -j ACEPTAR

-A ADELANTE -p tcp -j REJECT --reject-with tcp-reset

luego, el reordenamiento de paquetes puede hacer que el cortafuegos considere que los paquetes no son válidos y, por lo tanto, genere reinicios que romperán las conexiones que de otro modo serían saludables.

El reordenamiento es particularmente probable con una red inalámbrica.

En cambio, esto debería ser:

-A FORWARD -m estado --state RELACIONADO, ESTABLECIDO -j ACEPTAR

-A FORWARD -m estado --state INVALID -j DROP

-A ADELANTE -p tcp -j REJECT --reject-with tcp-reset

Básicamente en cualquier momento que tenga:

... -m estado --estado RELACIONADO, ESTABLECIDO -j ACEPTAR

debe ser seguido inmediatamente por:

... -m estado --state INVALID -j DROP

Es mejor eliminar un paquete y luego generar un protocolo que pueda interrumpir el restablecimiento de tcp. Los restablecimientos son mejores cuando se demuestra que son lo correcto para enviar ... ya que esto elimina los tiempos de espera. Pero si existe la posibilidad de que no sean válidos, pueden causar este tipo de dolor.

— Laberinto
fuente

0

Esto se debe a que hay otro proceso en la red que envía RST a su conexión TCP.

Normalmente, RST se enviaría en el siguiente caso

Un proceso cierra el socket cuando el socket que usa la opción SO_LINGER está habilitado
El sistema operativo está realizando la limpieza de recursos cuando su proceso sale sin cerrar el socket.

En su caso, parece que un proceso está conectando su conexión (puerto IP +) y sigue enviando RST después de establecer la conexión.

— Ben
fuente