Ja by som podozrieval PFko. PFko zahadzuje nove spojenia, ktore pouzivaju
rovnaku zdrojovu a cielovu adresu a port ako nejake stare spojenie, ktore
je v stave closed a nevyprsal este timeout tcp.closed - default 90s (+ 0
az interval sekund - default 10s). Vedia s tym byt dost problemy, pretoze
FreeBSD kludne vygeneruje dva rovnake zdrojove porty u dvoch kratkych
bezprostrednych odchodzich spojeni.
musim sa nad tym zamysliet, ale toto by snad nemal byt problem.
on by to nemal zahodit ale prehnat pravidlami. Ak tomu rozumiem spravne, ked
pride spojenie, hlada sa matchnig rule. Ak sa najde, vysledkom je bud povol
alebo zahod. V prvom pripade sa moze este vyrobit stav. Potom pri kazdom
dalsom "pakete" sa prehladaju najprv stavy a ak sa zodpovedajuci stav
nenajde, spracovavaju sa pravidla. A vysledkom je opat bud povol alebo
zahod.
Hovorime o pasivnom mode tj. pure-ftpd povie klientovi "vezmi si data na
porte X". A on sa pripoji. Ale malo by byt jedno, ze pred chvilkou bol
pripojeny niekto iny... Inak by predsa nefungovalo ani nieco taketo:
pass in quick on XY inet from any to XY port 80 keep state flags ...
Neviem, ci je to aj tvoj pripad, ale skus si do pf.conf pridat option "set
debug misc", reloadovat pf.conf a sledovat logy (defaultne
/var/log/messages) ci sa ti tam neobjavuje "BAD state" alebo "loose state
match".
toto urcite vyskusam... este ma napadlo vyhodit z tych pravidiel keep
state, ale to sa mi nezda ako riesenie.
d~
rwi
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
