Bonjour,
Y'a t'il un nombre max de connections qu'un linux peut suivre, en
conntrack ou en masquerade?
Je m'explique.
J'ai un LAN qui accede a internet par un linux qui masquerade les
connections. J'ai ajoute sur une des stations le programme amule.
Il ouvre pas mal de connections (ca me parait pas enorme, mais bon)
[:~]$ cat /proc/net/ip_conntrack | grep 192.168.1.9 | wc -l
181
J'ai remarque deux chose:
premier probleme, le suivi de connection avec
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
ne fonctionne plus. Je suis oblige de mettre la POLICY de FORWARD
en ACCEPT pour que les retours de connections inities par cette station
passent. J'ai logue, j'ai verifie dans le ip_conntrack, les connections
sont marquees [ASSURED] mais le retour ne passe pas. Je ne comprends
pas. A croire que netfilter n'arrive pas a suivre et que deborde, il
arrive seulement a appliquer la politique par defaut.
Et la, je ne comprends pas. Quid?
Et ensuite, deuxieme probleme:
Le reste du LAN et le firewall lui-meme ont d'enormes problemes de
connectivite. Ce n'est pas un probleme de bande passante, amule doit
stagner vers les 20-30kbit/s et j'ai une liaison megabit/s.
Mais je me prends beaucoup de paquets reset, et l'etablissement des
connections se fait tres lentement. Si j'ai un gros download a
effectuer (par exemples les sources du noyau linux), je vais avoir
des difficultes a me connecter sur n'importe quel ftp (pb de DNS, puis
pb de connections) par contre, une fois le download lance, plus de
problemes, ca telecharge rapidement. Le probleme est le meme que je
lance le download depuis la passerelle ou depuis une station masquee.
Il y a une limite de connections ouvertes simultanement? Si oui,
comment l'augmenter?
Est-ce que les deux problemes sont lies? (il semblerait, mais je vois
pas le rapport a premiere vue entre le ip_conntrack et le nombre de
connections ouvertes)
le firewall est sous slackware 7, noyau 2.4.22, iptables version 1.2.8
Une idee?
Merci
--
Kevin
Je crois que vous allez tous pouvoir rentrer tot, aujourd'hui ...
-+- Les 100 choses que vous n'aimez pas entendre de la part du sysadmin -+-
Bonjour,
Y'a t'il un nombre max de connections qu'un linux peut suivre, en
conntrack ou en masquerade?
Je m'explique.
J'ai un LAN qui accede a internet par un linux qui masquerade les
connections. J'ai ajoute sur une des stations le programme amule.
Il ouvre pas mal de connections (ca me parait pas enorme, mais bon)
[kevin@slackware:~]$ cat /proc/net/ip_conntrack | grep 192.168.1.9 | wc -l
181
J'ai remarque deux chose:
premier probleme, le suivi de connection avec
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
ne fonctionne plus. Je suis oblige de mettre la POLICY de FORWARD
en ACCEPT pour que les retours de connections inities par cette station
passent. J'ai logue, j'ai verifie dans le ip_conntrack, les connections
sont marquees [ASSURED] mais le retour ne passe pas. Je ne comprends
pas. A croire que netfilter n'arrive pas a suivre et que deborde, il
arrive seulement a appliquer la politique par defaut.
Et la, je ne comprends pas. Quid?
Et ensuite, deuxieme probleme:
Le reste du LAN et le firewall lui-meme ont d'enormes problemes de
connectivite. Ce n'est pas un probleme de bande passante, amule doit
stagner vers les 20-30kbit/s et j'ai une liaison megabit/s.
Mais je me prends beaucoup de paquets reset, et l'etablissement des
connections se fait tres lentement. Si j'ai un gros download a
effectuer (par exemples les sources du noyau linux), je vais avoir
des difficultes a me connecter sur n'importe quel ftp (pb de DNS, puis
pb de connections) par contre, une fois le download lance, plus de
problemes, ca telecharge rapidement. Le probleme est le meme que je
lance le download depuis la passerelle ou depuis une station masquee.
Il y a une limite de connections ouvertes simultanement? Si oui,
comment l'augmenter?
Est-ce que les deux problemes sont lies? (il semblerait, mais je vois
pas le rapport a premiere vue entre le ip_conntrack et le nombre de
connections ouvertes)
le firewall est sous slackware 7, noyau 2.4.22, iptables version 1.2.8
Une idee?
Merci
--
Kevin
Je crois que vous allez tous pouvoir rentrer tot, aujourd'hui ...
-+- Les 100 choses que vous n'aimez pas entendre de la part du sysadmin -+-
Bonjour,
Y'a t'il un nombre max de connections qu'un linux peut suivre, en
conntrack ou en masquerade?
Je m'explique.
J'ai un LAN qui accede a internet par un linux qui masquerade les
connections. J'ai ajoute sur une des stations le programme amule.
Il ouvre pas mal de connections (ca me parait pas enorme, mais bon)
[:~]$ cat /proc/net/ip_conntrack | grep 192.168.1.9 | wc -l
181
J'ai remarque deux chose:
premier probleme, le suivi de connection avec
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
ne fonctionne plus. Je suis oblige de mettre la POLICY de FORWARD
en ACCEPT pour que les retours de connections inities par cette station
passent. J'ai logue, j'ai verifie dans le ip_conntrack, les connections
sont marquees [ASSURED] mais le retour ne passe pas. Je ne comprends
pas. A croire que netfilter n'arrive pas a suivre et que deborde, il
arrive seulement a appliquer la politique par defaut.
Et la, je ne comprends pas. Quid?
Et ensuite, deuxieme probleme:
Le reste du LAN et le firewall lui-meme ont d'enormes problemes de
connectivite. Ce n'est pas un probleme de bande passante, amule doit
stagner vers les 20-30kbit/s et j'ai une liaison megabit/s.
Mais je me prends beaucoup de paquets reset, et l'etablissement des
connections se fait tres lentement. Si j'ai un gros download a
effectuer (par exemples les sources du noyau linux), je vais avoir
des difficultes a me connecter sur n'importe quel ftp (pb de DNS, puis
pb de connections) par contre, une fois le download lance, plus de
problemes, ca telecharge rapidement. Le probleme est le meme que je
lance le download depuis la passerelle ou depuis une station masquee.
Il y a une limite de connections ouvertes simultanement? Si oui,
comment l'augmenter?
Est-ce que les deux problemes sont lies? (il semblerait, mais je vois
pas le rapport a premiere vue entre le ip_conntrack et le nombre de
connections ouvertes)
le firewall est sous slackware 7, noyau 2.4.22, iptables version 1.2.8
Une idee?
Merci
--
Kevin
Je crois que vous allez tous pouvoir rentrer tot, aujourd'hui ...
-+- Les 100 choses que vous n'aimez pas entendre de la part du sysadmin -+-
Le 04 Nov 2003 13:41:45 GMT, Julien Salgado a ecrit:
| En effet, elle est de plus modifiable dans
| /proc/sys/net/ipv4/ip_conntrack_max
| ou
| /proc/sys/net/ipv4/netfilter/ip_conntrack_max
| suivant le type de noyau 2.4.22.
|
bon, par defaut j'en ai plus de 8000, le probleme vient d'ailleurs
|> [:~]$ cat /proc/net/ip_conntrack | grep 192.168.1.9 | wc -l
|> 181
|
| C'est très petit (et il y a un UUOC ;))
|
meme sans UUOC, je monte rarement a plus de 500. J'ai regarde, en
journee, je peux deja monter a +300, et le linux suit sans soucis. (Le
contraire m'aurait etonne). mais des que je lance l'appli, boum, l'acces
internet part aux fraises.
|> Et la, je ne comprends pas. Quid?
|
| Fais-tu du MASQUERADING ou de la SNAT. Car dans le premier cas, si ton
| interface est tombée, toute la table a été réinitialisée, ce qui peut
| expliquer ton problème. Si tu as des statistiques sur l'état de ton
| interface cela pourrait expliquer pas mal de chose.
|
hein? mon interface ne tombe pas. J'ai une IP fixe.
| Le mieux étant d'utiliser de la SNAT (il faut bien sûr récupérer son IP
| pour le faire, mais c'est pas trop dur) qui n'a pas le mauvais goût
| d'effacer la table de conntrack.
|
bon, j'ai essaye en SNAT-tant la machine amule, mais le probleme
persiste. Je l'allume, et cinq minutes apres, mon acces internet
devient hasardeux.
|> Et ensuite, deuxieme probleme:
|> Il y a une limite de connections ouvertes simultanement? Si oui,
|> comment l'augmenter?
|
| Oui, mais il me semble qu'elle n'est pas modifiable directement, elle
| est liée au nombre d'inode qui est quand même assez élevé. Et 180
| session, c'est très petit.
|
effectivement, d'ou ma perplexite grandissante (?)
|> Est-ce que les deux problemes sont lies? (il semblerait, mais je vois
|> pas le rapport a premiere vue entre le ip_conntrack et le nombre de
|> connections ouvertes)
|
| C'est assez bizarre, par contre il est possible que le noyau passe un
| peu de temps à faire du calcul de port si il y a des collisions
| fréquente des port source en UDP et TCP. Il est possible de jouer sur les
| ports destinés aux connexion locales initiées depuis le firewall via :
| /proc/sys/net/ipv4/ip_local_port_range
|
j'ai de 1024 a 4999, ca me parait plus que suffisant. Et puis:
[:~]$ netstat -n -a --inet | wc -l
35
| Il me semble aussi que c'est surtout un problème d'initialisation de
| connexion, que donne une capture de paquet ?
|
Bon, j'ai mis deux trois traces ici:
J'ai fait la trace, amule allume, un seul autre client derriere le LAN:
trace de eth1 (interface externe), generee avec:
tcpdump -n -l -i eth1 'tcp[13] & 3 != 0 ' or udp | tee logeth1.tcpdump
et en (presque) simultane, le trace de l'interface eth0 (interne)
tcpdump -n -l -i eth0 'tcp[13] & 3 != 0 ' or udp | tee logeth0.tcpdump
Dispos sur:
http://dkevin.dyndns.org/logeth1.tcpdump
http://dkevin.dyndns.org/logeth0.tcpdump
10.0.0.9 est la station amule, 192.168.1.115 est une station qui surfe.
192.168.1.4 est le DNS et le firewall.
(la carte eth0 est triplement aliasee, au passage). Le test a ete fait
alors que mes regles iptables SNAT-tent amule.
D'ailleurs, la j'ai carrement mon interface eth0 qui est partie en
vrille trois minutes apres avoir fait ce test
La regle FORWARD qui autorisait amule a sortir a disparue (?) mes logs
ont exploses, et:
Nov 4 23:30:17 slackware kernel: NETDEV WATCHDOG: eth0: transmit timed out
Nov 4 23:30:17 slackware kernel: eth0: Transmit timed out, status e4660000,
CSR12 45e1d0cc, resetting...
J'ai du la descendre, la remonter et recharger mes regles iptables pour
que la connection reparte.
Je comprends pas. Ou est ce que ca coince? La machine me parait
surdimensionnee pour le travail demande (2 carte 100Mbit/s, 128Mo RAM, PIII
a 600MHz).
Mais ou est-ce que je dois chercher? Quel trafic dois-je surveiller?
Quel indicateurs je pourrais mettre en place pour suivre tout ca de
pres?
Le 04 Nov 2003 13:41:45 GMT, Julien Salgado a ecrit:
| En effet, elle est de plus modifiable dans
| /proc/sys/net/ipv4/ip_conntrack_max
| ou
| /proc/sys/net/ipv4/netfilter/ip_conntrack_max
| suivant le type de noyau 2.4.22.
|
bon, par defaut j'en ai plus de 8000, le probleme vient d'ailleurs
|> [kevin@slackware:~]$ cat /proc/net/ip_conntrack | grep 192.168.1.9 | wc -l
|> 181
|
| C'est très petit (et il y a un UUOC ;))
|
meme sans UUOC, je monte rarement a plus de 500. J'ai regarde, en
journee, je peux deja monter a +300, et le linux suit sans soucis. (Le
contraire m'aurait etonne). mais des que je lance l'appli, boum, l'acces
internet part aux fraises.
|> Et la, je ne comprends pas. Quid?
|
| Fais-tu du MASQUERADING ou de la SNAT. Car dans le premier cas, si ton
| interface est tombée, toute la table a été réinitialisée, ce qui peut
| expliquer ton problème. Si tu as des statistiques sur l'état de ton
| interface cela pourrait expliquer pas mal de chose.
|
hein? mon interface ne tombe pas. J'ai une IP fixe.
| Le mieux étant d'utiliser de la SNAT (il faut bien sûr récupérer son IP
| pour le faire, mais c'est pas trop dur) qui n'a pas le mauvais goût
| d'effacer la table de conntrack.
|
bon, j'ai essaye en SNAT-tant la machine amule, mais le probleme
persiste. Je l'allume, et cinq minutes apres, mon acces internet
devient hasardeux.
|> Et ensuite, deuxieme probleme:
|> Il y a une limite de connections ouvertes simultanement? Si oui,
|> comment l'augmenter?
|
| Oui, mais il me semble qu'elle n'est pas modifiable directement, elle
| est liée au nombre d'inode qui est quand même assez élevé. Et 180
| session, c'est très petit.
|
effectivement, d'ou ma perplexite grandissante (?)
|> Est-ce que les deux problemes sont lies? (il semblerait, mais je vois
|> pas le rapport a premiere vue entre le ip_conntrack et le nombre de
|> connections ouvertes)
|
| C'est assez bizarre, par contre il est possible que le noyau passe un
| peu de temps à faire du calcul de port si il y a des collisions
| fréquente des port source en UDP et TCP. Il est possible de jouer sur les
| ports destinés aux connexion locales initiées depuis le firewall via :
| /proc/sys/net/ipv4/ip_local_port_range
|
j'ai de 1024 a 4999, ca me parait plus que suffisant. Et puis:
[kevin@slackware:~]$ netstat -n -a --inet | wc -l
35
| Il me semble aussi que c'est surtout un problème d'initialisation de
| connexion, que donne une capture de paquet ?
|
Bon, j'ai mis deux trois traces ici:
J'ai fait la trace, amule allume, un seul autre client derriere le LAN:
trace de eth1 (interface externe), generee avec:
tcpdump -n -l -i eth1 'tcp[13] & 3 != 0 ' or udp | tee logeth1.tcpdump
et en (presque) simultane, le trace de l'interface eth0 (interne)
tcpdump -n -l -i eth0 'tcp[13] & 3 != 0 ' or udp | tee logeth0.tcpdump
Dispos sur:
http://dkevin.dyndns.org/logeth1.tcpdump
http://dkevin.dyndns.org/logeth0.tcpdump
10.0.0.9 est la station amule, 192.168.1.115 est une station qui surfe.
192.168.1.4 est le DNS et le firewall.
(la carte eth0 est triplement aliasee, au passage). Le test a ete fait
alors que mes regles iptables SNAT-tent amule.
D'ailleurs, la j'ai carrement mon interface eth0 qui est partie en
vrille trois minutes apres avoir fait ce test
La regle FORWARD qui autorisait amule a sortir a disparue (?) mes logs
ont exploses, et:
Nov 4 23:30:17 slackware kernel: NETDEV WATCHDOG: eth0: transmit timed out
Nov 4 23:30:17 slackware kernel: eth0: Transmit timed out, status e4660000,
CSR12 45e1d0cc, resetting...
J'ai du la descendre, la remonter et recharger mes regles iptables pour
que la connection reparte.
Je comprends pas. Ou est ce que ca coince? La machine me parait
surdimensionnee pour le travail demande (2 carte 100Mbit/s, 128Mo RAM, PIII
a 600MHz).
Mais ou est-ce que je dois chercher? Quel trafic dois-je surveiller?
Quel indicateurs je pourrais mettre en place pour suivre tout ca de
pres?
Le 04 Nov 2003 13:41:45 GMT, Julien Salgado a ecrit:
| En effet, elle est de plus modifiable dans
| /proc/sys/net/ipv4/ip_conntrack_max
| ou
| /proc/sys/net/ipv4/netfilter/ip_conntrack_max
| suivant le type de noyau 2.4.22.
|
bon, par defaut j'en ai plus de 8000, le probleme vient d'ailleurs
|> [:~]$ cat /proc/net/ip_conntrack | grep 192.168.1.9 | wc -l
|> 181
|
| C'est très petit (et il y a un UUOC ;))
|
meme sans UUOC, je monte rarement a plus de 500. J'ai regarde, en
journee, je peux deja monter a +300, et le linux suit sans soucis. (Le
contraire m'aurait etonne). mais des que je lance l'appli, boum, l'acces
internet part aux fraises.
|> Et la, je ne comprends pas. Quid?
|
| Fais-tu du MASQUERADING ou de la SNAT. Car dans le premier cas, si ton
| interface est tombée, toute la table a été réinitialisée, ce qui peut
| expliquer ton problème. Si tu as des statistiques sur l'état de ton
| interface cela pourrait expliquer pas mal de chose.
|
hein? mon interface ne tombe pas. J'ai une IP fixe.
| Le mieux étant d'utiliser de la SNAT (il faut bien sûr récupérer son IP
| pour le faire, mais c'est pas trop dur) qui n'a pas le mauvais goût
| d'effacer la table de conntrack.
|
bon, j'ai essaye en SNAT-tant la machine amule, mais le probleme
persiste. Je l'allume, et cinq minutes apres, mon acces internet
devient hasardeux.
|> Et ensuite, deuxieme probleme:
|> Il y a une limite de connections ouvertes simultanement? Si oui,
|> comment l'augmenter?
|
| Oui, mais il me semble qu'elle n'est pas modifiable directement, elle
| est liée au nombre d'inode qui est quand même assez élevé. Et 180
| session, c'est très petit.
|
effectivement, d'ou ma perplexite grandissante (?)
|> Est-ce que les deux problemes sont lies? (il semblerait, mais je vois
|> pas le rapport a premiere vue entre le ip_conntrack et le nombre de
|> connections ouvertes)
|
| C'est assez bizarre, par contre il est possible que le noyau passe un
| peu de temps à faire du calcul de port si il y a des collisions
| fréquente des port source en UDP et TCP. Il est possible de jouer sur les
| ports destinés aux connexion locales initiées depuis le firewall via :
| /proc/sys/net/ipv4/ip_local_port_range
|
j'ai de 1024 a 4999, ca me parait plus que suffisant. Et puis:
[:~]$ netstat -n -a --inet | wc -l
35
| Il me semble aussi que c'est surtout un problème d'initialisation de
| connexion, que donne une capture de paquet ?
|
Bon, j'ai mis deux trois traces ici:
J'ai fait la trace, amule allume, un seul autre client derriere le LAN:
trace de eth1 (interface externe), generee avec:
tcpdump -n -l -i eth1 'tcp[13] & 3 != 0 ' or udp | tee logeth1.tcpdump
et en (presque) simultane, le trace de l'interface eth0 (interne)
tcpdump -n -l -i eth0 'tcp[13] & 3 != 0 ' or udp | tee logeth0.tcpdump
Dispos sur:
http://dkevin.dyndns.org/logeth1.tcpdump
http://dkevin.dyndns.org/logeth0.tcpdump
10.0.0.9 est la station amule, 192.168.1.115 est une station qui surfe.
192.168.1.4 est le DNS et le firewall.
(la carte eth0 est triplement aliasee, au passage). Le test a ete fait
alors que mes regles iptables SNAT-tent amule.
D'ailleurs, la j'ai carrement mon interface eth0 qui est partie en
vrille trois minutes apres avoir fait ce test
La regle FORWARD qui autorisait amule a sortir a disparue (?) mes logs
ont exploses, et:
Nov 4 23:30:17 slackware kernel: NETDEV WATCHDOG: eth0: transmit timed out
Nov 4 23:30:17 slackware kernel: eth0: Transmit timed out, status e4660000,
CSR12 45e1d0cc, resetting...
J'ai du la descendre, la remonter et recharger mes regles iptables pour
que la connection reparte.
Je comprends pas. Ou est ce que ca coince? La machine me parait
surdimensionnee pour le travail demande (2 carte 100Mbit/s, 128Mo RAM, PIII
a 600MHz).
Mais ou est-ce que je dois chercher? Quel trafic dois-je surveiller?
Quel indicateurs je pourrais mettre en place pour suivre tout ca de
pres?
> Bin _tout_. A croire qu'il y a un bottleneck qui me ralentit tout.
Si je lance amule, je dois attendre 5-6mn pour sentir les realentissements.
si je le coupe, je dois attendre 5-6mn pour que ca revienne a la normale.
Comme si une queue se remplissait plus vite qu'elle ne se vidait. Ca
explique les DNs qui mettent 10s a repondre, les sites qui me ferment la
connection, etc.. Mais *ou* serait situee cette file?
Je vais essayer des tests en modifiant le champ TOS des paquets, voir si ca
peut arranger quelquechose :/
> Bin _tout_. A croire qu'il y a un bottleneck qui me ralentit tout.
Si je lance amule, je dois attendre 5-6mn pour sentir les realentissements.
si je le coupe, je dois attendre 5-6mn pour que ca revienne a la normale.
Comme si une queue se remplissait plus vite qu'elle ne se vidait. Ca
explique les DNs qui mettent 10s a repondre, les sites qui me ferment la
connection, etc.. Mais *ou* serait situee cette file?
Je vais essayer des tests en modifiant le champ TOS des paquets, voir si ca
peut arranger quelquechose :/
> Bin _tout_. A croire qu'il y a un bottleneck qui me ralentit tout.
Si je lance amule, je dois attendre 5-6mn pour sentir les realentissements.
si je le coupe, je dois attendre 5-6mn pour que ca revienne a la normale.
Comme si une queue se remplissait plus vite qu'elle ne se vidait. Ca
explique les DNs qui mettent 10s a repondre, les sites qui me ferment la
connection, etc.. Mais *ou* serait situee cette file?
Je vais essayer des tests en modifiant le champ TOS des paquets, voir si ca
peut arranger quelquechose :/
