Regles PF et max-src-states

Le
Paul Gaborit
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/>
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Paul Gaborit
Le #20142071
À (at) Fri, 04 Sep 2009 13:50:37 +0200,
Paul Gaborit
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 -
Gabriel Linder
Le #20179031
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
Le #20180551
À (at) 19 Sep 2009 08:58:40 GMT,
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.



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 -
Gabriel Linder
Le #20185151
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
Le #20186251
À (at) 20 Sep 2009 01:15:28 GMT,
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 :)



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 -
Publicité
Poster une réponse
Anonyme