Cameron Schaus wrotte :-
I think you're not the only one interested in these changes.
Cam, could you post your patch implementing the necessary changes to make bridged tproxy work?
Sure. I'll post them soon. I have to find the code I wrote. I wasn't able to use tproxy4 due to some other issues I wasn't able to solve, so I'm not sure where the code went.
Any luck on this item ? -------------------------------------------- Important Warning! *************************** This electronic communication (including any attached files) may contain confidential and/or legally privileged information and is only intended for the use of the person to whom it is addressed. If you are not the intended recipient, you do not have permission to read, use, disseminate, distribute, copy or retain any part of this communication or its attachments in any form. If this e-mail was sent to you by mistake, please take the time to notify the sender so that they can identify the problem and avoid any more mistakes in sending e-mail to you. The unauthorised use of information contained in this communication or its attachments may result in legal action against any person who uses it.
Cameron Schaus wrotte :-
I think you're not the only one interested in these changes.
Cam, could you post your patch implementing the necessary changes to make bridged tproxy work?
Sure. I'll post them soon. I have to find the code I wrote. I wasn't able to use tproxy4 due to some other issues I wasn't able to solve, so I'm not sure where the code went.
Any luck on this item ?
I built a tproxy upon bridge interface with tproxy-4.1.0, and it works fine. All I need to do is to add two ebtables broute rules below: ebtables -t broute -A BROUTING -i $ETHIN \ -p ipv4 --ip-proto $TCP_PROTO --ip-dport $HTTP_PORT -j DROP ebtables -t broute -A BROUTING -i $ETHOUT \ -p ipv4 --ip-proto $TCP_PROTO --ip-sport $HTTP_PORT -j DROP ebtables will force packets I specify being routed instead of being bridged, then packets will be routed to loopback interface. (Without the two rules, packets will be forwarded, ignoring any route rules) 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 :-) Regards Daniel 2007-12-20
Any luck on this item ?
I built a tproxy upon bridge interface with tproxy-4.1.0, and it works fine. All I need to do is to add two ebtables broute rules below:
ebtables -t broute -A BROUTING -i $ETHIN \ -p ipv4 --ip-proto $TCP_PROTO --ip-dport $HTTP_PORT -j DROP ebtables -t broute -A BROUTING -i $ETHOUT \ -p ipv4 --ip-proto $TCP_PROTO --ip-sport $HTTP_PORT -j DROP
Sorry, I made a mistake here. People should use ebtables redirect target instead of '-j DROP'. otherwise after brouted, packets which passed rules still are type PACKET_OTHERHOST, then they will be dropped by ip_rcv immediately. I actually hacked bridge code to set all brouted packet to type PACKET_HOST because I didn't want to break my IP-MAC binding policy.
ebtables will force packets I specify being routed instead of being bridged, then packets will be routed to loopback interface. (Without the two rules, packets will be forwarded, ignoring any route rules)
Regards Daniel 2007-12-20
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)? -- KOVACS Krisztian
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
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
Daniel wrote:
I built a tproxy upon bridge interface with tproxy-4.1.0, and it works fine.
Where is tproxy-4.1.0 download url ?
All I need to do is to add two ebtables broute rules below:
ebtables -t broute -A BROUTING -i $ETHIN \ -p ipv4 --ip-proto $TCP_PROTO --ip-dport $HTTP_PORT -j DROP ebtables -t broute -A BROUTING -i $ETHOUT \ -p ipv4 --ip-proto $TCP_PROTO --ip-sport $HTTP_PORT -j DROP
I am aware of this. This one is equally applicable to tproxy-4.0.3. For tproxy--4.0.3 ( not sure if it's applicable to tproxy-4.1.0 ), if the $ETHIN and $ETHOUT has no ip address ( ie only br interface has been assigned IP), it will cause a kernel panic due to accessing null pointer. Not sure if that's fixed in tproxy-4.1.0.
ebtables will force packets I specify being routed instead of being bridged, then packets will be routed to loopback interface. (Without the two rules, packets will be forwarded, ignoring any route rules)
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 :-)
Where is tproxy-4.0.4 download url ? :-) Cheers
Daniel wrote:
I built a tproxy upon bridge interface with tproxy-4.1.0, and it works fine.
Where is tproxy-4.1.0 download url ?
The version number hides (by hidden :p) in KOVACS Krisztian's patch.
Where is tproxy-4.0.4 download url ? :-)
I mean 4.0.3 actually. Regards Daniel 2007-12-21
From: "Daniel" <tooldcas@163.com>
Daniel wrote:
I built a tproxy upon bridge interface with tproxy-4.1.0, and it works fine.
Where is tproxy-4.1.0 download url ?
The version number hides (by hidden :p) in KOVACS Krisztian's patch.
OK. The last time I tried the patches by Kovac, I could not find a matching iptables patch. And at this moment I am only interested to use it with kernel 2.6.22 because I have a few other patches which must go into it. Do you know any matching tproxy-4.1.0 together with iptables patch for kernel 2.6.22 ? I don't mind trying it. :-) Regards.
The last time I tried the patches by Kovac, I could not find a matching iptables patch. And at this moment I am only interested to use it with kernel 2.6.22 because I have a few other patches which must go into it.
Do you know any matching tproxy-4.1.0 together with iptables patch for kernel 2.6.22 ? I don't mind trying it. :-)
It's also hidden... http://people.netfilter.org/hidden/tproxy/iptables-tproxy-200710091749.diff I extracted libxt_socket and libxt_TPROXY from lastest iptables-tproxy-200710091749.diff patch and compile them independently. Good luck :-) Regards Daniel 2007-12-21
participants (3)
-
Daniel
-
KOVACS Krisztian
-
Ming-Ching Tiew