Hi, On Fri, 2007-12-21 at 17:14 +0800, Daniel wrote:
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)
Yep, this is interesting. I'll have a look at how skaidrus handles port numbers. (This problem could be avoided if skaidrus didn't use the original port number of the incoming connection for the outgoing. In a lot of cases faking the exact port number is not important.) -- KOVACS Krisztian