no sikeresen lefordult hogy hogyan ? velhetoen a probalkozasok soran is valami elkavarodott mivel a modositasok nem okoztak valtozast akkor lecsap majd ujra kitaroltam es akkor lefordult
fut is
viszont itt is elojott hogy mivel a ipchains ftp re meg rosszol van beallitva egy nmap a szerverre es a zorp kiakad ebben az az erdekes hogy ilyenkor a szerver elvileg vedetlen marad
azokat a portokat, ahova transzparens szolgaltatasokat huzol fel es redirectalsz, ipchains-el vedeni kell. tehat, ha a transzparens FTP proxy 50021-es porton fut (hogy ne utkozzon a 21-es porttal), es a kliensek egy redirect rule-lal kerulnek a listenerre, akkor az 50021-es portra nem szabad a tuzfal IP-jen szolgaltatast elfogadni. Ezt leginkabb ket chain-nel erdemes megcsinalni, az egyik akkor hajtodik vegre, ha kozvetlenul a tuzfalat szolitjak, a masik, amikor a kliens tulcimzi azt, pl: ipchains -A input -i eth0 -d 192.168.0.1 -j LOintra (192.168.0.1 a tuzfal IP-je) ipchains -A input -i eth0 -d 0/0 -j INintra (osszes tobbi) # tulcimzo kliensek ipchains -A INintra -d 0/0 21 -j REDIRECT 50021 ipchains -A INintra -l -j DENY # tuzfal altal nyujtott szolgaltatasok (altalaban nativ proxyk) ipchains -A LOintra -l -j DENY ilyen modon a transzparens listeneredre soha nem kerul keres kozvetlenul, es ezert nem kergeti magat vegtelenciklusba a zorp. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1 url: http://www.balabit.hu/pgpkey.txt