Re: Delai IDLE trop grand conntrack
Le 15/05/07, Pascal Hambourg<pascal.mail@plouf.fr.eu.org> a écrit :
Benjamin RIOU a écrit :
>> Par curiosité, qu'est-ce que le masquerading vient faire là-dedans ? Les
>> délais sont les mêmes avec et sans NAT.
>
> Hâ. je note.
> Vu que c'etait dans netfilter et conntrack, je croyais -bêtement?- que
> le parametre n'avait rapport qu'avec le masquerading.
Netfilter et conntrack ne servent pas seulement au NAT mais aussi au
suivi des connexions normales, notamment pour le filtrage "stateful" (-m
state ou -m conntrack).
>> > Avant, il y avait un délai de timeout de 5 jours !
>>
>> Et quel est le problème ?
>
> Je peux pas avoir plus de 700 connexions ouvertes vers l'exterieur
> (limitation d'un grand ami qui fournit le net, tu connais l'histoire -
> l'internet Communiste, toussa).
> 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.
Par contre elles sont tous ASSURED (encore heureux qu'il y ait pas
marqué "EN GREVE", hein ? :-))
root@scenic500:~# cat /proc/net/ip_conntrack | grep 192.168.1.121
tcp 6 122337 ESTABLISHED src=192.168.1.121 dst=82.239.5.218
sport=4014 dport=51309 src=82.239.5.218 dst=10.1.140.64 sport=51309
dport=4014 [ASSURED] use=1
tcp 6 50 TIME_WAIT src=192.168.1.121 dst=146.220.84.11 sport=4322
dport=80 src=146.220.84.11 dst=10.1.140.64 sport=80 dport=4322
[ASSURED] use=1
[etc]
> Et le module connlimit, dont nous avions parlé et que des gentils (et
> patients) usagers de la liste m'avaient aidé à installer, ce module
> connlimit, ne se base que sur les connexions ESTABLISHED.
Si je comprends bien, ton upstream comptabilise des connexions qui sont
considérées comme non ESTABLISHED par ta machine, et donc il arrive
qu'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 ?
J'avais pourtant l'impression que c'etait efficace ? :-S
>> > Je l'ai doresénavant mis à ... 5 minutes :-D
>>
>> Euh... Tu n'as peur de rien. J'ai déjà vu des connexions TCP établies
>> sans aucun trafic pendant plus longtemps que ça.
>
> Comme quoi, par exemple ?
> Je me suis posé la question, sans trouver.
Une session SSH (ou autre type de terminal à distance) qu'on laisse
ouverte sans activité, par exemple. Ou bien une bonne grosse requête qui
prend du temps avant que le serveur réponde. A une époque j'envoyais des
commandes 'XPAT' (recherche de motif dans les en-têtes) sur un serveur
NNTP qui mettait parfois 10 bonnes minutes à répondre lorsque le forum
concernait contenait beaucoup d'articles et que la recherche portait sur
un champ non présent dans l'overview.
Muhahaha. Je bloque tous ces ports par défaut ;-)
> Le FTP-COMMAND est souvent régi par un timeout issu du serveur.
> A ce que je vois, MSN envoie un paquet a son serveur toutes les 2 secondes.
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 ;-)
>> > Pourquoi un si grand délai avant ?
>>
>> Parce que la durée d'inactivité d'une connexion TCP peut être énorme
>> sans que ce soit anormal. Il existe un mécanisme optionnel dit "TCP
>> keepalive" qui permet de maintenir une activité au niveau de la couche
>> réseau et de vérifier si la machine en face répond, dont la périodicité
>> par défaut est de 2 heures, soit bien plus que tes 5 minutes.
>
> D'accord.
> C'est ca que j'aurais du baisser en fait , plutot...
Non, parce que les paramètres de keepalive TCP ne concernent que les
connexions établies par ta machine, pas aux connexions routées. D'autre
part le TCP keepalive n'est utilisé que si l'application le demande.
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 ?
> vider /proc/net/ip_conntrack réinitialise toutes les connexions
> NATées, ou cette affirmation est une immense connerie ?
On ne peut pas écrire dans /proc/net/ip_conntrack qui n'est qu'une vue
en lecture seule du contenu de la table de suivi de connexion. Toutefois
il existe des outils pour manipuler la table sur les noyaux >= 2.6.14,
voir les projets 'conntrack' et 'libnetfilter_conntrack' sur le site de
Netfilter.
Je jetterais un coup d'oeil.
Merci pour tous les details que tu me donnes !
Bonne journée :-)
Ben.
Reply to: