Qu'est-ce qui provoque l'envoi d'un indicateur de réinitialisation TCP / IP (RST)?


123

J'essaie de comprendre pourquoi la connexion TCP / IP de mon application continue de hocher toutes les 10 minutes (exactement, dans les 1-2 secondes). J'ai couru Wireshark et découvert qu'après 10 minutes d'inactivité, l'autre extrémité envoie un paquet avec l'indicateur de réinitialisation (RST) défini. Une recherche Google me dit que "l'indicateur RESET signifie que le récepteur est devenu confus et veut donc interrompre la connexion" mais c'est un peu court des détails dont j'ai besoin. Qu'est-ce qui peut causer cela? Et est-il possible qu'un routeur en cours de route en soit responsable ou cela viendrait-il toujours de l'autre point de terminaison?

Edit: Il y a un routeur (en particulier un Linksys WRT-54G) assis entre mon ordinateur et l'autre point de terminaison - y a-t-il quelque chose que je devrais rechercher dans les paramètres du routeur?


12
En voici un autre: Comcast
Tom Ritter

1
Heureusement, je n'ai pas de dépendance à Comcast car cela se produit dans un LAN. J'aimerais pouvoir rejeter le blâme aussi facilement que;)
Luke

Avez-vous déjà compris cela? Je ne peux pas faire de commentaire car je n'ai pas assez de points, mais j'ai exactement le même problème que vous aviez et je cherche une solution.

À quel service ce cas particulier fait-il référence? Il peut être possible de définir keepalive sur le socket (à partir du niveau de l'application) afin que de longues périodes d'inactivité n'entraînent pas que quelqu'un (au milieu ou non) essaie de forcer une réinitialisation de la connexion par manque de ressources.
arielf

"Comcast" dites-vous? : D Découvrez ce référentiel associé
joonas.fi

Réponses:


89

Un `` routeur '' pourrait faire n'importe quoi - en particulier NAT, ce qui pourrait impliquer n'importe quelle quantité de problèmes de bogue avec le trafic ...

Une des raisons pour lesquelles un périphérique enverra un RST est en réponse à la réception d'un paquet pour une socket fermée.

Il est difficile de donner une réponse ferme mais générale, car toutes les perversions possibles ont été visitées sur TCP depuis sa création, et toutes sortes de personnes pourraient insérer des RST pour tenter de bloquer le trafic. (Certains «pare-feu nationaux» fonctionnent comme ceci, par exemple.)


6
Soit le routeur a un délai d'expiration de 10 minutes pour les connexions TCP, soit le routeur a activé la «détection intelligente des paquets de passerelle».
David Schwartz

2
C'est un peu riche de suggérer qu'un routeur pourrait être rempli de bogues.
Marquis de Lorne le

23

Exécutez un renifleur de paquets (par exemple, Wireshark) également sur le pair pour voir si c'est le pair qui envoie le RST ou quelqu'un au milieu.


14

Je viens de passer un certain temps à résoudre ce problème. Aucune des solutions proposées n'a fonctionné. Il s'est avéré que notre administrateur système attribuait par erreur la même adresse IP statique à deux serveurs indépendants appartenant à des groupes différents, mais assis sur le même réseau. Les résultats finaux étaient des connexions vnc supprimées par intermittence, un navigateur qui devait être actualisé plusieurs fois pour récupérer la page Web, et d'autres choses étranges.


7

Certains pare-feu font cela si une connexion est inactive pendant x nombre de minutes. Certains FAI configurent leurs routeurs pour le faire également pour diverses raisons.

De nos jours, vous devrez gérer gracieusement (rétablir si nécessaire) cette condition.


2
La connexion est rétablie très bien, le problème est que la brève période de déconnexion provoque une alerte inutilement.
Luc

1
J'ai eu des problèmes spécifiquement avec l'équipement Cisco PIX / ASA. Ils ont des délais d'expiration particulièrement courts par défaut. L'équipement le moins cher est généralement «meilleur» à cet égard (car ils ne dépassent pas très rapidement le délai d'attente) ...
Brian Knoblauch

1
J'ajouterais même que TCP n'a jamais été complètement fiable du point de vue des connexions persistantes. Cela devient simplement plus perceptible de temps en temps. Autre exemple intéressant: certaines personnes peuvent implémenter une logique qui marque un client TCP comme hors ligne dès que la fermeture ou la réinitialisation de la connexion est détectée. Et parfois, ils ne prennent pas la peine de donner à un client une chance de se reconnecter. Ce n'est évidemment pas tout à fait correct.
Victor Yarema il y a

7

RST est envoyé par le côté effectuant la fermeture active car c'est le côté qui envoie le dernier ACK. Donc, s'il reçoit FIN du côté faisant la fermeture passive dans un état incorrect, il envoie un paquet RST qui indique à l'autre côté qu'une erreur s'est produite.


6
Les deux côtés envoient et reçoivent un FIN dans une fermeture normale. Il n'y a rien de mal dans cette situation, et donc aucune raison pour qu'un côté émette une réinitialisation. La première phrase n'a même pas de sens.
Marquis de Lorne le

2
[RST, ACK] peut également être envoyé par le côté recevant un SYN sur un port non écouté. Dans un cas que j'ai rencontré, le RST / ACK est arrivé environ 60 secondes après le premier SYN. FWIW
Les

@MarquisofLorne, la première phrase elle-même peut être considérée comme incorrecte. Mais l'expression «dans un mauvais état» dans la deuxième phrase la rend en quelque sorte valide.
Victor Yarema il y a

7

S'il y a un routeur faisant du NAT, en particulier un routeur bas de gamme avec peu de ressources, il vieillira d'abord les sessions TCP les plus anciennes. Pour ce faire, il définit le RSTdrapeau dans le paquet qui indique effectivement à la station réceptrice de fermer (sans grâce) la connexion. ceci est fait pour économiser des ressources.


3

Une chose à savoir est que de nombreux pare-feu Linux Netfilter sont mal configurés.

Si vous avez quelque chose comme:

-A FORWARD -m state --state RELATED, ESTABLISHED -j ACCEPTER

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

la réorganisation des paquets peut alors amener le pare-feu à considérer les paquets comme non valides et à générer ainsi des réinitialisations qui interrompront alors les connexions autrement saines.

La réorganisation est particulièrement probable avec un réseau sans fil.

Cela devrait plutôt être:

-A FORWARD -m state --state RELATED, ESTABLISHED -j ACCEPTER

-A FORWARD -m état --state INVALID -j DROP

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

En gros, à chaque fois que vous avez:

... -m état --state RELATED, ESTABLISHED -j ACCEPTER

il doit être immédiatement suivi de:

... -m état --state INVALID -j DROP

Il vaut mieux abandonner un paquet puis générer une réinitialisation TCP potentiellement perturbatrice du protocole. Les réinitialisations sont meilleures lorsqu'elles sont prouvées comme la bonne chose à envoyer ... car cela élimine les délais d'attente. Mais s'il y a une chance qu'ils soient invalides, ils peuvent causer ce genre de douleur.


0

En effet, il existe un autre processus dans le réseau qui envoie RST à votre connexion TCP.

Normalement, RST serait envoyé dans le cas suivant

  • Un processus ferme le socket lorsque le socket utilisant l'option SO_LINGER est activé
  • Le système d'exploitation effectue le nettoyage des ressources lorsque votre processus se termine sans fermer le socket.

Dans votre cas, cela ressemble à un processus qui connecte votre connexion (IP + port) et continue d'envoyer RST après avoir établi la connexion.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.