[iptables] ip_conntrack: table full, dropping packet

Recherche :

Dernière réponse
Sujet : [iptables] ip_conntrack: table full, dropping packet
Zzozo	Petite question à tous ceux qui ont eu des pbs récemment : Est ce que l'option "IP: TCP Syncookies support" (CONFIG_SYN_COOKIES) est activée à la compil du noyau ? Et ensuite, est ce que cette option est activée au boot ? (via un echo 1 > /proc/sys/net/ipv4/tcp_syncookies ) Cette option permet de combattre ce que l'on appelle le SYN Flooding ... on sait jamais, ca peut aider ... :D

Votre réponse

Nom d'utilisateur

Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !

Le ton de votre message

Votre réponse

Smilies

Liste des smilies perso
Wiki smilies
Chercher un smiley

Options

Activer votre signature
Désactiver les smilies
Activer la notification par email du sujet

Aperçu

Vous avez perdu votre mot de passe ?

Vue Rapide de la discussion

Zzozo

Petite question à tous ceux qui ont eu des pbs récemment :
Est ce que l'option "IP: TCP Syncookies support" (CONFIG_SYN_COOKIES) est activée à la compil du noyau ?
Et ensuite, est ce que cette option est activée au boot ? (via un echo 1 > /proc/sys/net/ipv4/tcp_syncookies )
Cette option permet de combattre ce que l'on appelle le SYN Flooding ... on sait jamais, ca peut aider ... :D

Zzozo

e_esprit a écrit :

<reponse naive> parce que MLdonkey ouvre de plus en plus de connexion vers l'exterieur, et donc le suivi de connexion commence a etre "embouteille" si certaines d'entre elles ne se termine pas correctement</reponse naive>

Moi je dis ca, mais je suis pas expert iptables alors je sais pas comment ca fonctionne le ip_conntrack, mais bon ca m'etonnerais pas que ce soir u truc du genre.

A tester : relancer le firewall (je parle pas de la machine juste du script iptables)

Normalement, il y a un timeout ... sauf que si la connexion est tojours maintenue, le timeout ne se produit jamais et ne libère pas la connexion donc ... en clair, ca veut dire que tu as de plus en plus de connectés via ML Donkey ... ou en tout cas, de plus en plus de connexions volotairement maintenues ...

911GT3

cat /proc/net/ip_conntrack |wc -l
4124

[:totoz]

911GT3

j'y avais pensé (elle étais à 4096) mais je m'interrogais sur les conséquences et sur l'efficacité du remède à long terme.
de plus, en faisant un
cat /proc/net/ip_conntrack |wc -l
des paquets commencaient à être oubliés alors que la table ne contenait 'que' 3800 entrées et des brouettes, du coup je me suis également demandé s'il s'agissait bien de la même chose.

J'ai passé la valeur à 8192, je teste...

kadreg

Tu peux aussi augmenter la taille de cette table :

[root@rincevent kadreg]# cat /proc/sys/net/ipv4/ip_conntrack_max
2048
[root@rincevent kadreg]# echo 8192 > /proc/sys/net/ipv4/ip_conntrack_max
[root@rincevent kadreg]# cat /proc/sys/net/ipv4/ip_conntrack_max
8192
[root@rincevent kadreg]#

911GT3

déjà fait pour le firewall. j'aurais bien décharger/recharger les ip_conntract mais il est en hard dans le noyau :/
j'y connais rien en iptables mais dans la série question naïve: y a pas moyen de la flusher cette table ? [je sors ?]

e_esprit

911GT3

up.
j'ai ces messages qui me polluent mon /var/log/messages sur mon serveur alors que tout c'est très bien passé jusqu'ici (25 jours d'uptime).
C'est un 2.4.19 qui fait tourner en autres un mldonkey derrière un firewall. Si je stoppe le mldonkey ça s'arrête, mais pourquoi avoir attendu 24 jours (ça le fait depuis hier soir) pour faire chier ?

poser un 2.4.20 servira-t-il à quelque chose ? (puisque d'après bmothekiller c'est une défaut lié au kernel.)

BMOTheKiller

c'est pas du flood :D

mais t'as trouvé la conséquencen...... ;)

mais bon ça ne me l'a jamais fait avant et pourtant ça fait un p'tit moment que j'ai ce firewall, juste le noyal qui a changé

Tux Le Penguin

BMOTheKiller a écrit a écrit :

voilà, j'ai ce message qui "inonde" actuellement le log firewall de ma passerelle, accompagné de "X messages suppressed", après une recherche sur google, j'ai compris que ceci provenait du noyau 2.4.18 (j'avais gardé le noyau 2.4.7-10 de la RH 7.2 et je n'avais jamais eu ce message), bref après 27 heures d'uptime sur cette machine, je rencontre ce problème... que faut-il faire dans ce cas au niveau du firewall ? (à part virer le logging :D)

moi j'ai eu ça une fois, en poussant un peu trop mldonkey
donc soit tu as un prog qui bouffe méchament de ressources, soit qq'un te flood par je ne sais quelle technique

BMOTheKiller

voilà, j'ai ce message qui "inonde" actuellement le log firewall de ma passerelle, accompagné de "X messages suppressed", après une recherche sur google, j'ai compris que ceci provenait du noyau 2.4.18 (j'avais gardé le noyau 2.4.7-10 de la RH 7.2 et je n'avais jamais eu ce message), bref après 27 heures d'uptime sur cette machine, je rencontre ce problème... que faut-il faire dans ce cas au niveau du firewall ? (à part virer le logging :D)