Benjamin RIOU a écrit :
> > Je peux pas avoir plus de 700 connexions ouvertes vers l'exterieur > Et donc, malgré que j'aie 150 connexions established, j'avais > facilement 750 connexions dans conntrack, ce qui bloquait toute > demande de nouvel accès exterieur... :-) Dans quel état, les 600 autres connexions ?Elles sont soit en ESTABLISHED soit en TIME_WAIT.
Je m'en doutais. L'état TIME_WAIT indique que la connexion s'est terminée récemment. Il permet d'accepter pendant un délai de grâce (2 minutes par défaut) d'éventuels segments retardataires arrivés en désordre après la séquence FIN avant effacement de la connexion de la table de suivi.
Par contre elles sont tous ASSURED
Cet indicateur est positionné quand la connexion a eu suffisamment de trafic dans les deux sens, donc toute connexion TCP qui est ou a été ESTABLISHED reste ASSURED même lorsqu'elle est en cours de fermeture. Son rôle, ainsi que celui de l'état TIME_WAIT, est expliqué là en français (forcer le charset Latin-1 ou 9 pour un affichage correct) : <http://iptables-tutorial.frozentux.net/fr/x1391.html>
Si je comprends bien, ton upstream comptabilise des connexions qui sont considérées comme non ESTABLISHED par ta machine, et donc il arrivequ'il bloque les nouvelles connexions qui ont été autorisées par celle-ci ?Mais dans ce cas je ne vois pas trop en quoi réduire le délai d'expiration des connexions ESTABLISHED sur ta machine aiderait à résoudre le problème.Donc la modification que j'ai fait n'a pas pour but d'éradiquer les TIME_WAIT ?
Ah non, la réduction de ip_conntrack_tcp_timeout_established a pour conséquence de virer plus vite les connexion établies (ESTABLISHED) inactives. Aucun effet a priori sur les connexions récemment terminées (TIME_WAIT). Et inutile de chercher à jouer sur ip_conntrack_tcp_timeout_time_wait, puisque 'connlimit' ne comptabilise pas les connexions dans cet état.
J'avais pourtant l'impression que c'etait efficace ? :-S
Ça efface seulement les connexions établies inactives depuis "trop" longtemps.
Si le protocole applicatif le prévoit ou le permet, il est effectivement préférable de maintenir une connexion inactive "vivante" avec un keepalive géré au niveau applicatif et non au niveau TCP. C'est plus souple dans le choix du délai (réglable par connexion et par application) et ne requiert pas le support du keepalive par la pile TCP/IP. Il y a une option pour ça dans SSH, d'ailleurs.Oui. c'est d'ailleurs tres chiant quand on fait une capture wireshark ;-)
Il y a des filtres dans wireshark pour ne pas capturer ce genre de "signaux parasites".
Dans la mesure où la passerelle sert essentiellement a du surf, et que la majorité de mes clients utilisent IE, c possible que le navigateur ne prenne pas la peine de clore les connexions... Sinon, pourquoi aurais-je autant de connexions pendantes ?
Comme expliqué plus haut, l'état TIME_WAIT signale les connexions qui ont été fermées proprement récemment. Et un navigateur, ça peut générer beaucoup de connexions de courte durée pour charger tous les éléments d'une page web. Chaque connexion dure quelques dixièmes de seconde dans l'état ESTABLISHED puis reste dans l'état TIME_WAIT pendant 2 minutes avant d'être effacée. Ça pourrait expliquer la proportion de connexions dans cet état. Cependant normalement HTTP/1.1 permet de réutiliser une même connexion pour faire plusieurs requêtes HTTP consécutives, à condition que le navigateur et le serveur le supportent. C'est ce qu'on appelle une connexion persistante.
Si les connexions TIME_WAIT sont majoritairement dues à la navigation web, la mise en place d'un proxy HTTP pourrait peut-être améliorer les choses.
Si ton but est de faire en sorte que 'connlimit' comptabilise les connexions en cours à peu près de la même façon que l'upstream, il faudrait modifier ipt_connlimit.c pour qu'il n'exclue pas les connexions dans l'état TIME_WAIT. Ça présenterait au moins l'avantage de ne pénaliser que les clients qui produisent beaucoup de ces connexions et pas les autres.