Je to tak, avsak ked sa prehladaju stavy, tak vysledkom nemusi byt iba
povol, ale aj zahod. PFko zahadzuje pakety, ktore odpovedaju zaznamu v
stavovej tabulke, ale prijaty paket neodpoveda zaznamenanemu stavu
(neocakavane flagy alebo sekvencne cislo). Spominany pripad je taky, podla
PF ide o uzavrete spojenie a pride paket so SYN flagom - podla PF taky
paket tu nema co robit, tak ho zahodi.
ano, mas pravdu. pozrel som sa do man pfctl/pf.conf. Je celkom nechutne ze
to moze zahodit. Spravnejsie by asi bolo to nezahodit a pozriet sa do
pravidiel.
Ano, ak bol pripojeni niekto iny, tak je to jedno. Ale ked sa pripaja ta
ista IP adresa a pure-ftpd povedal klientovi, ze ma pouzit ten isty port,
tak by to bol problem, ak by sa zvolil este rovnaky zdrojovy port. Nie su
klienti za NATom?
su za NAT. Ak tomu spravne rozumiem, toto sa moze stat ak klient aj server
"priliz skoro" pouziju rovnaku dvojicu portov.
Ale vratme sa k nastaveniu PFka. Ty hovoris, ze riesenim by mohlo byt
nizenie tcp.closed na povadzme 20 sekund z povodnych 90.
Ale podla dokumentacie:
tcp.closed - The state after one endpoint sends an RST.
Tam ale predsa nikto neposiela RST...
Podla mna to funguje takto. Server povie klientovi "vezmi si data na porte
XY" a zacne na porte pocuvat. Klient sa pripoji. Prebehne TCP 3W handshake.
Server v cykle zacne data posielat a klient ich prijimat. Ked server posle
vsetko, zavola close() a urobi tzv. aktivny close tj. posle FIN. Cele sa to
dostane do stavu FIN_WAIT_1. Klient posle ACK pripadne aj s FIN. Tj.
spojenie sa moze zavriet v jednom alebo dvoch krokoch na konci ktorych je
ale TIME_WAIT. Ten by mal trvat 2 krat MSL. MSL je pre FreeBSD defaultne 30
sekund (pozrel som to v sysctl).
Cize 60 sekund by kernel nemal pridelit ten isty port lebo cokolvek co nan
pride z toho isteho paru IP/port (soketu) by mohol byt napr. lost duplicate.
K tomuto stavu by sa mal vztahovat PFkovy limit 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.
Ten je ale 45 sekund tj. menej nez 2 krat 30.
Jedine co ma napadlo je, ze na vine je pure-ftpd, ktory si vybera porty z
rozsahu, ktory som mu povedal a serie na to, ze nesmie priliz rychlo
znovupouzit tie iste.
Jedno zle riesenie, ktore ma napadlo je nastavit "volne porty" na rovnaky
rozsah ako ten, ktory som povedal pure-ftpd, vynut na nich keep state a
nehovorit pure-ftpd, ktore porty ma pouzit. Toto by malo stacit k tomu, aby
tie porty prideloval kernel.
Budem sa ale musiet pozriet do zdrojakov, ako ich prideluje. Resp. ci v
pripade ak mu nepoviem ze chcem porty z tohoto rozsahu, ci necha ich
pridelenie na kerneli.
V kazdom pripade ma celkom serie, ze ked som teraz nastavil debug misc a
pustil tail -f na messages tak vsetko chodi :)
d~
rwi
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
