Je gère plusieurs sites miroir (ctan, cpan...) sur une machine
FreeBSD.
Certains utilisateurs distants "indélicats" utilisent des
accélérateurs de download qui créent de multiples connexions sur le
serveur pour capter un maximum de bande passante. Pour bloquer ces
petits malins, j'ai configuré mon pf pour qu'il n'autorise que 4
connexions maximum depuis une même adresse IP vers le serveur
(source-track rule, max-src-states 4). Ça marche bien puisque ça ne
bloque pas les pseudo-accélérateurs tout en les empêchant de bouffer
toute la bande passante.
Ce matin, j'ai utilisé un installeur (celui de TeXLive) qui va
chercher tout un tas de petits fichiers d'archives sur le
miroir. L'installeur les rapatrie un par un en faisant appel à 'wget'
à chaque fois. Le débit était catastrophique (56 heures pour tout
installer !).
En regardant avec 'pftop', je me suis aperçu que pf conservait quatre
connexions dans l'état 'FIN_WAIT_2:FIN_WAIT_2' et qu'il attendait un
timeout de 1m30s avant qu'elles disparaissent.
Comment puis-je faire pour que la règle 'max-src-states' ne
comptabilise pas comme étant actives les connexions qui sont dans
l'état 'FIN_WAIT_2:FIN_WAIT_2' ?
Mais peut-être y a-t-il un autre moyen de gérer ce problème...
Merci pour vos réponses.
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Paul Gaborit
À (at) Fri, 04 Sep 2009 13:50:37 +0200, Paul Gaborit écrivait (wrote):
Je gère plusieurs sites miroir (ctan, cpan...) sur une machine FreeBSD.
Certains utilisateurs distants "indélicats" utilisent des accélérateurs de download qui créent de multiples connexions sur le serveur pour capter un maximum de bande passante. Pour bloquer ces petits malins, j'ai configuré mon pf pour qu'il n'autorise que 4 connexions maximum depuis une même adresse IP vers le serveur (source-track rule, max-src-states 4). Ça marche bien puisque ça ne bloque pas les pseudo-accélérateurs tout en les empêchant de bouffer toute la bande passante.
Ce matin, j'ai utilisé un installeur (celui de TeXLive) qui va chercher tout un tas de petits fichiers d'archives sur le miroir. L'installeur les rapatrie un par un en faisant appel à 'wget' à chaque fois. Le débit était catastrophique (56 heures pour tout installer !).
En regardant avec 'pftop', je me suis aperçu que pf conservait quatre connexions dans l'état 'FIN_WAIT_2:FIN_WAIT_2' et qu'il attendait un timeout de 1m30s avant qu'elles disparaissent.
Comment puis-je faire pour que la règle 'max-src-states' ne comptabilise pas comme étant actives les connexions qui sont dans l'état 'FIN_WAIT_2:FIN_WAIT_2' ?
Mais peut-être y a-t-il un autre moyen de gérer ce problème...
Merci pour vos réponses.
Personne pour m'éclairer ou au moins me donner une piste où chercher ?
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Fri, 04 Sep 2009 13:50:37 +0200,
Paul Gaborit <Paul.Gaborit@invalid.invalid> écrivait (wrote):
Je gère plusieurs sites miroir (ctan, cpan...) sur une machine
FreeBSD.
Certains utilisateurs distants "indélicats" utilisent des
accélérateurs de download qui créent de multiples connexions sur le
serveur pour capter un maximum de bande passante. Pour bloquer ces
petits malins, j'ai configuré mon pf pour qu'il n'autorise que 4
connexions maximum depuis une même adresse IP vers le serveur
(source-track rule, max-src-states 4). Ça marche bien puisque ça ne
bloque pas les pseudo-accélérateurs tout en les empêchant de bouffer
toute la bande passante.
Ce matin, j'ai utilisé un installeur (celui de TeXLive) qui va
chercher tout un tas de petits fichiers d'archives sur le
miroir. L'installeur les rapatrie un par un en faisant appel à 'wget'
à chaque fois. Le débit était catastrophique (56 heures pour tout
installer !).
En regardant avec 'pftop', je me suis aperçu que pf conservait quatre
connexions dans l'état 'FIN_WAIT_2:FIN_WAIT_2' et qu'il attendait un
timeout de 1m30s avant qu'elles disparaissent.
Comment puis-je faire pour que la règle 'max-src-states' ne
comptabilise pas comme étant actives les connexions qui sont dans
l'état 'FIN_WAIT_2:FIN_WAIT_2' ?
Mais peut-être y a-t-il un autre moyen de gérer ce problème...
Merci pour vos réponses.
Personne pour m'éclairer ou au moins me donner une piste où chercher ?
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Fri, 04 Sep 2009 13:50:37 +0200, Paul Gaborit écrivait (wrote):
Je gère plusieurs sites miroir (ctan, cpan...) sur une machine FreeBSD.
Certains utilisateurs distants "indélicats" utilisent des accélérateurs de download qui créent de multiples connexions sur le serveur pour capter un maximum de bande passante. Pour bloquer ces petits malins, j'ai configuré mon pf pour qu'il n'autorise que 4 connexions maximum depuis une même adresse IP vers le serveur (source-track rule, max-src-states 4). Ça marche bien puisque ça ne bloque pas les pseudo-accélérateurs tout en les empêchant de bouffer toute la bande passante.
Ce matin, j'ai utilisé un installeur (celui de TeXLive) qui va chercher tout un tas de petits fichiers d'archives sur le miroir. L'installeur les rapatrie un par un en faisant appel à 'wget' à chaque fois. Le débit était catastrophique (56 heures pour tout installer !).
En regardant avec 'pftop', je me suis aperçu que pf conservait quatre connexions dans l'état 'FIN_WAIT_2:FIN_WAIT_2' et qu'il attendait un timeout de 1m30s avant qu'elles disparaissent.
Comment puis-je faire pour que la règle 'max-src-states' ne comptabilise pas comme étant actives les connexions qui sont dans l'état 'FIN_WAIT_2:FIN_WAIT_2' ?
Mais peut-être y a-t-il un autre moyen de gérer ce problème...
Merci pour vos réponses.
Personne pour m'éclairer ou au moins me donner une piste où chercher ?
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Gabriel Linder
On Mon, 14 Sep 2009 18:29:43 +0200, Paul Gaborit wrote:
En regardant avec 'pftop', je me suis aperçu que pf conservait quatre connexions dans l'état 'FIN_WAIT_2:FIN_WAIT_2' et qu'il attendait un timeout de 1m30s avant qu'elles disparaissent.
Comment puis-je faire pour que la règle 'max-src-states' ne comptabilise pas comme étant actives les connexions qui sont dans l'état 'FIN_WAIT_2:FIN_WAIT_2' ?
Dans pf.conf(5) on trouve diverses informations sur ce genre de timeout dans la section OPTIONS, notamment tcp.closing et tcp.finwait.
-- . Cordialement, ..: Gabriel Linder
On Mon, 14 Sep 2009 18:29:43 +0200, Paul Gaborit wrote:
En regardant avec 'pftop', je me suis aperçu que pf conservait quatre
connexions dans l'état 'FIN_WAIT_2:FIN_WAIT_2' et qu'il attendait un
timeout de 1m30s avant qu'elles disparaissent.
Comment puis-je faire pour que la règle 'max-src-states' ne
comptabilise pas comme étant actives les connexions qui sont dans
l'état 'FIN_WAIT_2:FIN_WAIT_2' ?
Dans pf.conf(5) on trouve diverses informations sur ce genre de timeout
dans la section OPTIONS, notamment tcp.closing et tcp.finwait.
On Mon, 14 Sep 2009 18:29:43 +0200, Paul Gaborit wrote:
En regardant avec 'pftop', je me suis aperçu que pf conservait quatre connexions dans l'état 'FIN_WAIT_2:FIN_WAIT_2' et qu'il attendait un timeout de 1m30s avant qu'elles disparaissent.
Comment puis-je faire pour que la règle 'max-src-states' ne comptabilise pas comme étant actives les connexions qui sont dans l'état 'FIN_WAIT_2:FIN_WAIT_2' ?
Dans pf.conf(5) on trouve diverses informations sur ce genre de timeout dans la section OPTIONS, notamment tcp.closing et tcp.finwait.
-- . Cordialement, ..: Gabriel Linder
Paul Gaborit
À (at) 19 Sep 2009 08:58:40 GMT, Gabriel Linder écrivait (wrote):
On Mon, 14 Sep 2009 18:29:43 +0200, Paul Gaborit wrote:
En regardant avec 'pftop', je me suis aperçu que pf conservait quatre connexions dans l'état 'FIN_WAIT_2:FIN_WAIT_2' et qu'il attendait un timeout de 1m30s avant qu'elles disparaissent.
Comment puis-je faire pour que la règle 'max-src-states' ne comptabilise pas comme étant actives les connexions qui sont dans l'état 'FIN_WAIT_2:FIN_WAIT_2' ?
Dans pf.conf(5) on trouve diverses informations sur ce genre de timeout dans la section OPTIONS, notamment tcp.closing et tcp.finwait.
Merci pour cette réponse.
Effectivement, cela devrait pouvoir m'aider pour régler mon souci. Mais je m'interroge tout de même :
tcp.finwait The state after both FINs have been exchanged and the connec- tion is closed. Some hosts (notably web servers on Solaris) send TCP packets even after closing the connection. Increas- ing tcp.finwait (and possibly tcp.closing) can prevent block- ing of such packets.
Quels sont les risques (de dysfonctionnement) si je diminue cette valeur ?
Autre question : où puis-je trouver les valeurs par défaut de ce genre de paramètres ?
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) 19 Sep 2009 08:58:40 GMT,
Gabriel Linder <g.linder@laposte.net> écrivait (wrote):
On Mon, 14 Sep 2009 18:29:43 +0200, Paul Gaborit wrote:
En regardant avec 'pftop', je me suis aperçu que pf conservait quatre
connexions dans l'état 'FIN_WAIT_2:FIN_WAIT_2' et qu'il attendait un
timeout de 1m30s avant qu'elles disparaissent.
Comment puis-je faire pour que la règle 'max-src-states' ne
comptabilise pas comme étant actives les connexions qui sont dans
l'état 'FIN_WAIT_2:FIN_WAIT_2' ?
Dans pf.conf(5) on trouve diverses informations sur ce genre de timeout
dans la section OPTIONS, notamment tcp.closing et tcp.finwait.
Merci pour cette réponse.
Effectivement, cela devrait pouvoir m'aider pour régler mon
souci. Mais je m'interroge tout de même :
tcp.finwait
The state after both FINs have been exchanged and the connec-
tion is closed. Some hosts (notably web servers on Solaris)
send TCP packets even after closing the connection. Increas-
ing tcp.finwait (and possibly tcp.closing) can prevent block-
ing of such packets.
Quels sont les risques (de dysfonctionnement) si je diminue cette
valeur ?
Autre question : où puis-je trouver les valeurs par défaut de ce genre
de paramètres ?
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) 19 Sep 2009 08:58:40 GMT, Gabriel Linder écrivait (wrote):
On Mon, 14 Sep 2009 18:29:43 +0200, Paul Gaborit wrote:
En regardant avec 'pftop', je me suis aperçu que pf conservait quatre connexions dans l'état 'FIN_WAIT_2:FIN_WAIT_2' et qu'il attendait un timeout de 1m30s avant qu'elles disparaissent.
Comment puis-je faire pour que la règle 'max-src-states' ne comptabilise pas comme étant actives les connexions qui sont dans l'état 'FIN_WAIT_2:FIN_WAIT_2' ?
Dans pf.conf(5) on trouve diverses informations sur ce genre de timeout dans la section OPTIONS, notamment tcp.closing et tcp.finwait.
Merci pour cette réponse.
Effectivement, cela devrait pouvoir m'aider pour régler mon souci. Mais je m'interroge tout de même :
tcp.finwait The state after both FINs have been exchanged and the connec- tion is closed. Some hosts (notably web servers on Solaris) send TCP packets even after closing the connection. Increas- ing tcp.finwait (and possibly tcp.closing) can prevent block- ing of such packets.
Quels sont les risques (de dysfonctionnement) si je diminue cette valeur ?
Autre question : où puis-je trouver les valeurs par défaut de ce genre de paramètres ?
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Gabriel Linder
On Sat, 19 Sep 2009 14:18:14 +0200, Paul Gaborit wrote:
tcp.finwait The state after both FINs have been exchanged and the connec- tion is closed. Some hosts (notably web servers on Solaris) send TCP packets even after closing the connection. Increas- ing tcp.finwait (and possibly tcp.closing) can prevent block- ing of such packets.
Quels sont les risques (de dysfonctionnement) si je diminue cette valeur ?
À peu près nuls, on n'est pas censé envoyer de données après un FIN normalement :)
Autre question : où puis-je trouver les valeurs par défaut de ce genre de paramètres ?
D'après pfctl(8) : pfctl -s timeouts
-- . Cordialement, ..: Gabriel Linder
On Sat, 19 Sep 2009 14:18:14 +0200, Paul Gaborit wrote:
tcp.finwait
The state after both FINs have been exchanged and the connec-
tion is closed. Some hosts (notably web servers on Solaris) send
TCP packets even after closing the connection. Increas- ing
tcp.finwait (and possibly tcp.closing) can prevent block- ing of
such packets.
Quels sont les risques (de dysfonctionnement) si je diminue cette valeur
?
À peu près nuls, on n'est pas censé envoyer de données après un FIN
normalement :)
Autre question : où puis-je trouver les valeurs par défaut de ce genre
de paramètres ?
On Sat, 19 Sep 2009 14:18:14 +0200, Paul Gaborit wrote:
tcp.finwait The state after both FINs have been exchanged and the connec- tion is closed. Some hosts (notably web servers on Solaris) send TCP packets even after closing the connection. Increas- ing tcp.finwait (and possibly tcp.closing) can prevent block- ing of such packets.
Quels sont les risques (de dysfonctionnement) si je diminue cette valeur ?
À peu près nuls, on n'est pas censé envoyer de données après un FIN normalement :)
Autre question : où puis-je trouver les valeurs par défaut de ce genre de paramètres ?
D'après pfctl(8) : pfctl -s timeouts
-- . Cordialement, ..: Gabriel Linder
Paul Gaborit
À (at) 20 Sep 2009 01:15:28 GMT, Gabriel Linder écrivait (wrote):
On Sat, 19 Sep 2009 14:18:14 +0200, Paul Gaborit wrote:
tcp.finwait The state after both FINs have been exchanged and the connec- tion is closed. Some hosts (notably web servers on Solaris) send TCP packets even after closing the connection. Increas- ing tcp.finwait (and possibly tcp.closing) can prevent block- ing of such packets.
Quels sont les risques (de dysfonctionnement) si je diminue cette valeur ?
À peu près nuls, on n'est pas censé envoyer de données après un FIN normalement :)
Ok. ;-)
Autre question : où puis-je trouver les valeurs par défaut de ce genre de paramètres ?
D'après pfctl(8) : pfctl -s timeouts
Merci. Avec ça je vais pouvoir peaufiner mes réglages.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) 20 Sep 2009 01:15:28 GMT,
Gabriel Linder <g.linder@laposte.net> écrivait (wrote):
On Sat, 19 Sep 2009 14:18:14 +0200, Paul Gaborit wrote:
tcp.finwait
The state after both FINs have been exchanged and the connec-
tion is closed. Some hosts (notably web servers on Solaris) send
TCP packets even after closing the connection. Increas- ing
tcp.finwait (and possibly tcp.closing) can prevent block- ing of
such packets.
Quels sont les risques (de dysfonctionnement) si je diminue cette valeur
?
À peu près nuls, on n'est pas censé envoyer de données après un FIN
normalement :)
Ok. ;-)
Autre question : où puis-je trouver les valeurs par défaut de ce genre
de paramètres ?
D'après pfctl(8) : pfctl -s timeouts
Merci. Avec ça je vais pouvoir peaufiner mes réglages.
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) 20 Sep 2009 01:15:28 GMT, Gabriel Linder écrivait (wrote):
On Sat, 19 Sep 2009 14:18:14 +0200, Paul Gaborit wrote:
tcp.finwait The state after both FINs have been exchanged and the connec- tion is closed. Some hosts (notably web servers on Solaris) send TCP packets even after closing the connection. Increas- ing tcp.finwait (and possibly tcp.closing) can prevent block- ing of such packets.
Quels sont les risques (de dysfonctionnement) si je diminue cette valeur ?
À peu près nuls, on n'est pas censé envoyer de données après un FIN normalement :)
Ok. ;-)
Autre question : où puis-je trouver les valeurs par défaut de ce genre de paramètres ?
D'après pfctl(8) : pfctl -s timeouts
Merci. Avec ça je vais pouvoir peaufiner mes réglages.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
