Hi,
On cs, dec 20, 2007 at 02:25:55 +0800, Daniel wrote:
But I have not done the same thing with tproxy-4.0.4, because these two version are totally incompatible. I prefer tproxy-4.1.0 than the old one because it can run on bridge mode without any extra hacking :-)
Have you actually tried running tproxy 4.1.0 on a bridge? That's something I haven't tested at all so this is good news. Does it work the same way as the old tproxy (eg. all you have to do is to force ebtables to route those packets)?
Yes. I have been testing it since last week and it works fine. But as I mentioned in my last mail, I did hack the br_input code to set packets to type PACKET_HOST. I think if we use '-j redirect' instead of '-j DROP', we don't need to do this. I will test it once I have time. I rewrited skaidrus[1] and made it my HTTP proxy, and I can see: * we do not need NAT any more; * we do not need to getsockopt(fd, SOL_IP, SO_ORIGINAL_DST, &addr, &addrlen) to fetch original destination IP (one getpeername syscall is OK); * we get only one conntrack entry for each session and conntrack (interesting) [1]skaidrus is a an example transparent proxy application written by Lennert Buytenhek.
-- KOVACS Krisztian
Regards Daniel 2007-12-21