J'ai une différence trop grande entre les connexions masqueradées et
les ESTABLISHED masqueradées (en gros, celles en attente de timeout et
les established)
Pour réduire le délai de timeout en tcp masquradé, j'ai effectué
l'operation suivante
:~# echo 300 >
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
Avant, il y avait un délai de timeout de 5 jours !
Je l'ai doresénavant mis à ... 5 minutes :-D
Pourquoi un si grand délai avant ?
Vais-je au dela d'ennuis ?
Faut il absolument rebooter pour que cela fonctionne ?
J'ai une différence trop grande entre les connexions masqueradées et
les ESTABLISHED masqueradées (en gros, celles en attente de timeout et
les established)
Pour réduire le délai de timeout en tcp masquradé, j'ai effectué
l'operation suivante
root@scenic500:~# echo 300 >
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
Avant, il y avait un délai de timeout de 5 jours !
Je l'ai doresénavant mis à ... 5 minutes :-D
Pourquoi un si grand délai avant ?
Vais-je au dela d'ennuis ?
Faut il absolument rebooter pour que cela fonctionne ?
J'ai une différence trop grande entre les connexions masqueradées et
les ESTABLISHED masqueradées (en gros, celles en attente de timeout et
les established)
Pour réduire le délai de timeout en tcp masquradé, j'ai effectué
l'operation suivante
:~# echo 300 >
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
Avant, il y avait un délai de timeout de 5 jours !
Je l'ai doresénavant mis à ... 5 minutes :-D
Pourquoi un si grand délai avant ?
Vais-je au dela d'ennuis ?
Faut il absolument rebooter pour que cela fonctionne ?
> Par curiosité, qu'est-ce que le masquerading vient faire là-dedans ? Les
délais sont les mêmes avec et sans NAT.
> Avant, il y avait un délai de timeout de 5 jours !
Et quel est le problème ?
> Je l'ai doresénavant mis à ... 5 minutes :-D
Euh... Tu n'as peur de rien. J'ai déjà vu des connexions TCP établi es
sans aucun trafic pendant plus longtemps que ça.
> Pourquoi un si grand délai avant ?
Parce que la durée d'inactivité d'une connexion TCP peut être éno rme
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ério dicité
par défaut est de 2 heures, soit bien plus que tes 5 minutes.
> Vais-je au dela d'ennuis ?
Possible.
> Faut il absolument rebooter pour que cela fonctionne ?
Pas que je sache, mais le nouveau réglage ne s'appliquera peut-être
qu'aux nouvelles connexions.
> Par curiosité, qu'est-ce que le masquerading vient faire là-dedans ? Les
délais sont les mêmes avec et sans NAT.
> Avant, il y avait un délai de timeout de 5 jours !
Et quel est le problème ?
> Je l'ai doresénavant mis à ... 5 minutes :-D
Euh... Tu n'as peur de rien. J'ai déjà vu des connexions TCP établi es
sans aucun trafic pendant plus longtemps que ça.
> Pourquoi un si grand délai avant ?
Parce que la durée d'inactivité d'une connexion TCP peut être éno rme
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ério dicité
par défaut est de 2 heures, soit bien plus que tes 5 minutes.
> Vais-je au dela d'ennuis ?
Possible.
> Faut il absolument rebooter pour que cela fonctionne ?
Pas que je sache, mais le nouveau réglage ne s'appliquera peut-être
qu'aux nouvelles connexions.
> Par curiosité, qu'est-ce que le masquerading vient faire là-dedans ? Les
délais sont les mêmes avec et sans NAT.
> Avant, il y avait un délai de timeout de 5 jours !
Et quel est le problème ?
> Je l'ai doresénavant mis à ... 5 minutes :-D
Euh... Tu n'as peur de rien. J'ai déjà vu des connexions TCP établi es
sans aucun trafic pendant plus longtemps que ça.
> Pourquoi un si grand délai avant ?
Parce que la durée d'inactivité d'une connexion TCP peut être éno rme
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ério dicité
par défaut est de 2 heures, soit bien plus que tes 5 minutes.
> Vais-je au dela d'ennuis ?
Possible.
> Faut il absolument rebooter pour que cela fonctionne ?
Pas que je sache, mais le nouveau réglage ne s'appliquera peut-être
qu'aux nouvelles connexions.
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.
> 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... :-)
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.
> 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.
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.
> 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...
vider /proc/net/ip_conntrack réinitialise toutes les connexions
NATées, ou cette affirmation est une immense connerie ?
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.
> 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... :-)
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.
> 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.
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.
> 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...
vider /proc/net/ip_conntrack réinitialise toutes les connexions
NATées, ou cette affirmation est une immense connerie ?
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.
> 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... :-)
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.
> 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.
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.
> 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...
vider /proc/net/ip_conntrack réinitialise toutes les connexions
NATées, ou cette affirmation est une immense connerie ?
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?- qu e
> 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 ?
> 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 ce lle-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.
>>
>> Euh... Tu n'as peur de rien. J'ai déjà vu des connexions TCP éta blies
>> 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 foru m
concernait contenait beaucoup d'articles et que la recherche portait sur
un champ non présent dans l'overview.
> 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 secon des.
Si le protocole applicatif le prévoit ou le permet, il est effectivemen t
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.
>> > 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 couc he
>> 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'aut re
part le TCP keepalive n'est utilisé que si l'application le demande.
> 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.
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?- qu e
> 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 ?
> 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 ce lle-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.
>>
>> Euh... Tu n'as peur de rien. J'ai déjà vu des connexions TCP éta blies
>> 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 foru m
concernait contenait beaucoup d'articles et que la recherche portait sur
un champ non présent dans l'overview.
> 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 secon des.
Si le protocole applicatif le prévoit ou le permet, il est effectivemen t
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.
>> > 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 couc he
>> 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'aut re
part le TCP keepalive n'est utilisé que si l'application le demande.
> 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.
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?- qu e
> 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 ?
> 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 ce lle-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.
>>
>> Euh... Tu n'as peur de rien. J'ai déjà vu des connexions TCP éta blies
>> 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 foru m
concernait contenait beaucoup d'articles et que la recherche portait sur
un champ non présent dans l'overview.
> 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 secon des.
Si le protocole applicatif le prévoit ou le permet, il est effectivemen t
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.
>> > 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 couc he
>> 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'aut re
part le TCP keepalive n'est utilisé que si l'application le demande.
> 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 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.
Par contre elles sont tous ASSURED
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
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 ;-)
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 ?
>
> 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.
Par contre elles sont tous ASSURED
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
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 ;-)
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 ?
>
> 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.
Par contre elles sont tous ASSURED
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
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 ;-)
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 ?
> 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âc e (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 son t
>> considérées comme non ESTABLISHED par ta machine, et donc il arriv e
>> 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 ?
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ée s
(TIME_WAIT). Et inutile de chercher à jouer sur
ip_conntrack_tcp_timeout_time_wait, puisque 'connlimit' ne comptabilise
pas les connexions dans cet état.
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émen ts
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 connex ions
dans cet état. Cependant normalement HTTP/1.1 permet de réutiliser un e
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 le s
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, i l
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.
> 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âc e (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 son t
>> considérées comme non ESTABLISHED par ta machine, et donc il arriv e
>> 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 ?
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ée s
(TIME_WAIT). Et inutile de chercher à jouer sur
ip_conntrack_tcp_timeout_time_wait, puisque 'connlimit' ne comptabilise
pas les connexions dans cet état.
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émen ts
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 connex ions
dans cet état. Cependant normalement HTTP/1.1 permet de réutiliser un e
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 le s
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, i l
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.
> 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âc e (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 son t
>> considérées comme non ESTABLISHED par ta machine, et donc il arriv e
>> 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 ?
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ée s
(TIME_WAIT). Et inutile de chercher à jouer sur
ip_conntrack_tcp_timeout_time_wait, puisque 'connlimit' ne comptabilise
pas les connexions dans cet état.
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émen ts
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 connex ions
dans cet état. Cependant normalement HTTP/1.1 permet de réutiliser un e
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 le s
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, i l
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.
L'état TIME_WAIT indique que la connexion s'est terminée récemment.
La connexion vers l'exterieur est elle fermée ou bien encore ouverte,
finalement ?
Parce que si elle a été fermée par l'hôte, j'ai pas envie que ma
passerelle garde (même pour deux minutes), la connexion.
Et inutile de chercher à jouer sur
ip_conntrack_tcp_timeout_time_wait, puisque 'connlimit' ne comptabilise
pas les connexions dans cet état.
Oui, mais si ca me limite le nombre de connexions TIME_WAIT ouvertes,
on va passer de 2 minutes à 20 secondes !
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.
C'est quoi l'upstream ? Le flux montant ?
Bah si les clients peuvent pas ouvrir plus de 20 connections par
periode de 120 secondes, je crois que vais me faire tuer :-)
L'état TIME_WAIT indique que la connexion s'est terminée récemment.
La connexion vers l'exterieur est elle fermée ou bien encore ouverte,
finalement ?
Parce que si elle a été fermée par l'hôte, j'ai pas envie que ma
passerelle garde (même pour deux minutes), la connexion.
Et inutile de chercher à jouer sur
ip_conntrack_tcp_timeout_time_wait, puisque 'connlimit' ne comptabilise
pas les connexions dans cet état.
Oui, mais si ca me limite le nombre de connexions TIME_WAIT ouvertes,
on va passer de 2 minutes à 20 secondes !
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.
C'est quoi l'upstream ? Le flux montant ?
Bah si les clients peuvent pas ouvrir plus de 20 connections par
periode de 120 secondes, je crois que vais me faire tuer :-)
L'état TIME_WAIT indique que la connexion s'est terminée récemment.
La connexion vers l'exterieur est elle fermée ou bien encore ouverte,
finalement ?
Parce que si elle a été fermée par l'hôte, j'ai pas envie que ma
passerelle garde (même pour deux minutes), la connexion.
Et inutile de chercher à jouer sur
ip_conntrack_tcp_timeout_time_wait, puisque 'connlimit' ne comptabilise
pas les connexions dans cet état.
Oui, mais si ca me limite le nombre de connexions TIME_WAIT ouvertes,
on va passer de 2 minutes à 20 secondes !
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.
C'est quoi l'upstream ? Le flux montant ?
Bah si les clients peuvent pas ouvrir plus de 20 connections par
periode de 120 secondes, je crois que vais me faire tuer :-)
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>
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>
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>