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/>
Personne pour m'�clairer ou au moins me donner une piste o� chercher ?
>> 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
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 ?
> 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
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.