Quelles sont les ramifications de la définition de tcp_tw_recycle / reuse à 1?

J'ai défini les deux tcp_tw_recycle / reuse sur 1 dans mon fichier de configuration.

Quelles sont les ramifications de cela?

Si un socket TCP est réutilisé, cela pose-t-il un risque pour la sécurité? c'est-à-dire 2 connexions différentes pouvant potentiellement envoyer des données?

Convient-il aux connexions de courte durée avec peu de chances de reconnexion?

Par défaut, lorsque les deux tcp_tw_reuseet tcp_tw_recyclesont désactivés, le noyau s'assurera que les sockets en TIME_WAITétat resteront dans cet état assez longtemps - assez longtemps pour être sûr que les paquets appartenant aux connexions futures ne seront pas confondus avec les paquets tardifs de l'ancienne connexion.

Lorsque vous activez tcp_tw_reuse, les sockets en TIME_WAITétat peuvent être utilisées avant leur expiration, et le noyau essaiera de s'assurer qu'il n'y a pas de collision concernant les numéros de séquence TCP. Si vous activez tcp_timestamps(aka PAWS, pour la protection contre les numéros de séquence encapsulés), il s'assurera que ces collisions ne peuvent pas se produire. Cependant, vous devez activer les horodatages TCP aux deux extrémités (du moins, c'est ce que je comprends). Voir la définition de tcp_twsk_unique pour les détails sanglants.

Lorsque vous activez tcp_tw_recycle, le noyau devient beaucoup plus agressif et fera des hypothèses sur les horodatages utilisés par les hôtes distants. Il suivra le dernier horodatage utilisé par chaque hôte distant ayant une connexion en TIME_WAITétat) et permettra de réutiliser un socket si l'horodatage a correctement augmenté. Cependant, si l'horodatage utilisé par l'hôte change (c'est-à-dire qu'il se déforme dans le temps), le SYNpaquet sera abandonné en silence et la connexion ne s'établira pas (vous verrez une erreur similaire à "délai d'expiration de connexion"). Si vous voulez plonger dans le code du noyau, la définition de tcp_timewait_state_process pourrait être un bon point de départ.

Maintenant, les horodatages ne devraient jamais remonter dans le temps; sauf si:

• l'hôte est redémarré (mais ensuite, au moment où il reviendra, le TIME_WAITsocket aura probablement expiré, donc ce ne sera pas un problème);
• l'adresse IP est rapidement réutilisée par autre chose (les TIME_WAITconnexions resteront un peu, mais d'autres connexions seront probablement supprimées TCP RSTet cela libérera de l'espace);
• la traduction d'adresse réseau (ou un pare-feu smarty-pants) est impliquée au milieu de la connexion.

Dans ce dernier cas, vous pouvez avoir plusieurs hôtes derrière la même adresse IP, et donc, différentes séquences d'horodatages (ou, ces horodateurs sont randomisés à chaque connexion par le pare-feu). Dans ce cas, certains hôtes ne pourront pas se connecter de manière aléatoire, car ils sont mappés sur un port pour lequel le TIME_WAITcompartiment du serveur a un horodatage plus récent. C'est pourquoi les documents vous indiquent que «les périphériques NAT ou les équilibreurs de charge peuvent commencer à supprimer des images en raison du paramètre».

Certaines personnes recommandent de laisser tcp_tw_recycleseul, mais activer tcp_tw_reuseet abaissertcp_timewait_len . Je plussoie :-)

Je viens de me mordre, alors peut-être que quelqu'un pourrait bénéficier de ma douleur et de ma souffrance. Tout d'abord, un lien impliqué avec beaucoup d'informations: http://vincent.bernat.im/en/blog/2014-tcp-time-wait-state-linux.html

En particulier:

Le seul résultat de ce manque de documentation est que nous trouvons de nombreux guides de réglage conseillant de définir ces deux paramètres à 1 pour réduire le nombre d'entrées dans l'état TIME-WAIT. Cependant, comme indiqué par la page de manuel tcp (7), l'option net.ipv4.tcp_tw_recycle est assez problématique pour les serveurs publics car elle ne gère pas les connexions de deux ordinateurs différents derrière le même périphérique NAT, ce qui est un problème difficile à résoudre. détecter et attendre de vous mordre:

J'ai utilisé ces fonctionnalités pour réussir à fournir une connectivité haproxy aussi faible que possible des clients à un cluster NDB MySql. C'était dans un cloud privé, et aucune connexion du tout à aucun n'avait de NAT dans le mélange. Le cas d'utilisation avait du sens, abaissant la latence pour les clients de rayon atteignant NDB via haproxy autant que possible. Il l'a fait.

Je l'ai fait à nouveau sur un système haproxy public, équilibrant la charge du trafic Web, sans vraiment étudier l'impact (stupide, non?!) Et découvert après beaucoup de dépannage et de chasse aux fantômes qui:

• Cela créera un chaos pour les clients se connectant via un NAT.
• Il est presque impossible de l'identifier car il est complètement aléatoire, intermittent, et les symptômes toucheront le client A, à des moments complètement (ou non) différents du client B, etc.

Du côté client, ils verront des périodes de temps où ils n'obtiennent plus de réponses aux paquets SYN, parfois ici et là, et parfois pendant de longues périodes. Encore une fois, au hasard.

La courte histoire ici, dans mon expérience récente et douloureuse, est de les laisser seuls / désactivés sur les serveurs publics, quel que soit leur rôle!

De 'man 7 tcp' Vous verrez ceci:

   tcp_tw_recycle (Boolean; default: disabled; since Linux 2.4)
          Enable fast recycling of TIME_WAIT sockets.  Enabling this option is not recommended since this causes problems when working with NAT
          (Network Address Translation).

   tcp_tw_reuse (Boolean; default: disabled; since Linux 2.4.19/2.6)
          Allow  to  reuse  TIME_WAIT  sockets  for  new connections when it is safe from protocol viewpoint.  It should not be changed without
          advice/request of technical experts.

Pas beaucoup d'aide là-bas. Cette uestion a également une bonne idée:

/programming/6426253/tcp-tw-reuse-vs-tcp-tw-recycle-which-to-use-or-both

Mais pas d'informations spécifiques sur les raisons pour lesquelles la réutilisation est plus sûre que le recyclage. La réponse de base est que tcp_tw_reuse permettra à un utilisateur d'utiliser le même socket s'il y en a déjà un dans TIME_WAIT avec les mêmes paramètres TCP et dans un état où aucun trafic supplémentaire n'est attendu (je pense que c'est quand un FIN a été envoyé ). tcp_tw_recycle, d'autre part, ne fera que réutiliser les sockets qui sont dans TIME_WAIT avec les mêmes paramètres quel que soit l'état, ce qui peut confondre les pare-feu avec état qui peuvent attendre différents paquets.

tcp_tw_reuse peut être fait de manière sélective dans le code en définissant l'option de socket SO_REUSEADDR, documentée man 7 socketcomme suit :

   SO_REUSEADDR
          Indicates that the rules used in validating addresses supplied in a bind(2) call should allow reuse of local addresses.  For  AF_INET
          sockets  this means that a socket may bind, except when there is an active listening socket bound to the address.  When the listening
          socket is bound to INADDR_ANY with a specific port then it is not possible to bind to this port for any local address.   Argument  is
          an integer boolean flag.