Hi, As some of you might know, the 5th Netfilter Developer's Workshop took place last week in Karlsruhe, Germany. Krisztian Kovacs (hidden) and me attended the workshop and tried to merge the somewhat diverged work on tproxy4. The fork of the tproxy code was caused by a change of maintenance, thus some of the latest work of Krisztian was left out from the latest 4.0.x patches released by Panther. (more exactly the "socket" match and the mark based diversion code). On the workshop we merged our efforts again in order to get acceptance of the Linux net/netfilter maintainers. (DaveM and Patrick McHardy). This will again change the way tproxy should be used. Sorry for breaking compatibility again, and the whole confusion, hopefully the results will be a tproxy functionality merged in the Linux kernel. :) The most important changes relative to the current 4.0.x patches are: * the tproxy table is gone, TPROXY targets need to be added to the mangle table instead * the tproxy match is gone, a new "socket" match is introduced * instead of using a separate routing trick to divert packets to the local IP stack inside the TProxy target, we are now using stock routing decisions, and need a bit in the packet MARK field, and perform diversion by using an advanced routing rule. * instead of IP_FREEBIND we are using a setsockopt named IP_TRANSPARENT which requires CAP_NET_ADMIN privilege * in previous patches the output routing decision was commented out, it is now correctly decided whether a packet belongs to a tproxied connection or not. These are the major changes, now here's a script that demonstrates TProxy usage: 1) create advanced routing rules We are using the lowest bit of the packet MARK value to indicate that the packet was diverted by the TProxy code. The exact bit value can be changed. Commands to set this up: ip rule add fwmark 1 lookup 100 ip route add local 0.0.0.0/0 dev lo table 100 2) create TProxy rules in the mangle table # create a chain named DIVERT iptables -t mangle -N DIVERT # everything that matches "-m socket" should go to the local stack iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT # connections to be redirected should use the TPROXY target, which sets # up redirection, and marks the packet according to its 'tproxy-mark' # argument iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 50080 # DIVERT chain: mark packets and accept iptables -t mangle -A DIVERT -j MARK --set-mark 1 iptables -t mangle -A DIVERT -j ACCEPT The ruleset would be much simpler if iptables would support ebtables like multiple targets, which it is going to. In that case the rules would become: iptables -t mangle -A PREROUTING -p tcp -m socket -j MARK --set-mark 1 -j ACCEPT iptables -t mangle -A PREROUTING -p tcp --dport 80 j MARK --set-mark 1 -j TPROXY --on-port 50080 Hopefully this will also be implemented soon. I have done some functionality testing on the patchset, and things like redirection did work. We'll start some more testing this week, however more tests never hurt. We'd appreciate if someone could help us with testing. The latest patchset is available at: http://home.sch.bme.hu/~piglet/netfilter/tproxy/ Some documentation and manual pages are still missing, but we are working on that issue as well. -- Bazsi
On Sep 18 2007 12:01, Balazs Scheidler wrote:
As some of you might know, the 5th Netfilter Developer's Workshop took place last week in Karlsruhe, Germany. Krisztian Kovacs (hidden) and me
Krisztián was not hidden at all ;-) [scnr]
The most important changes relative to the current 4.0.x patches are: * the tproxy table is gone, TPROXY targets need to be added to the mangle table instead * the tproxy match is gone, a new "socket" match is introduced * instead of using a separate routing trick to divert packets to the local IP stack inside the TProxy target, we are now using stock routing decisions, and need a bit in the packet MARK field, and perform diversion by using an advanced routing rule. * instead of IP_FREEBIND we are using a setsockopt named IP_TRANSPARENT which requires CAP_NET_ADMIN privilege
Hm, the working sample code I have here (again, based upon Krisztián's tproxy-4.0_20060722 I was sent) requires both IP_FREEBIND and IP_TRANSPARENT. Does this still hold?
# connections to be redirected should use the TPROXY target, which sets # up redirection, and marks the packet according to its 'tproxy-mark' # argument iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 50080
Is this a mark distinct from the packet mark? I remember being put into the boiling cooking pot when I tried to have chaostables use packet and connection marks for its tricks. I am still unsure what exactly -j TPROXY is supposed to do. Case 1 I can imagine: no squid, hence routing the packet with its original address is a no-problem. Case 2 to imagine: with squid; can use -j REDIRECT instead of -j TPROXY. What did I miss?
Hi, On k, szept 18, 2007 at 12:12:23 +0200, Jan Engelhardt wrote:
The most important changes relative to the current 4.0.x patches are: * the tproxy table is gone, TPROXY targets need to be added to the mangle table instead * the tproxy match is gone, a new "socket" match is introduced * instead of using a separate routing trick to divert packets to the local IP stack inside the TProxy target, we are now using stock routing decisions, and need a bit in the packet MARK field, and perform diversion by using an advanced routing rule. * instead of IP_FREEBIND we are using a setsockopt named IP_TRANSPARENT which requires CAP_NET_ADMIN privilege
Hm, the working sample code I have here (again, based upon Krisztián's tproxy-4.0_20060722 I was sent) requires both IP_FREEBIND and IP_TRANSPARENT. Does this still hold?
Yes, that's required to be able to bind to non-local addresses (and this part of the mainline kernel is not touched in any way). The other option is the ip_nonlocal_bind sysctl, of course.
# connections to be redirected should use the TPROXY target, which sets # up redirection, and marks the packet according to its 'tproxy-mark' # argument iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 50080
Is this a mark distinct from the packet mark? I remember being put into the boiling cooking pot when I tried to have chaostables use packet and connection marks for its tricks.
No, it's the very same mark. Initially we have tried to avoid overloading the skb's mark value, but there is no 'clean' way of doing that. Extending the skb with private fields is not considered particularly elegant, plus you have to be able to do policy routing based on the flag. The mark value you set here or with your rules using the socket match are used only to be able to decide which packets are to be delivered to the local it stack. That is, it's a real mark and no magic is going on inside the kernel which touches it. You just have to make sure that the mark you set in -j TPROXY matches the bit you check in your policy routing rule.
I am still unsure what exactly -j TPROXY is supposed to do. Case 1 I can imagine: no squid, hence routing the packet with its original address is a no-problem.
Yes, you don't need -j TPROXY in this case.
Case 2 to imagine: with squid; can use -j REDIRECT instead of -j TPROXY.
Well, you can, but then you need NAT. TPROXY does not require NAT nor connection tracking. Think of TPROXY as a way of implementing redirection without NAT, that is, without modifying the incoming packets at all. -- KOVACS Krisztian
On Sep 18 2007 14:15, KOVACS Krisztian wrote:
Case 2 to imagine: with squid; can use -j REDIRECT instead of -j TPROXY.
Well, you can, but then you need NAT.
Where do I need NAT? Squid will use setsockopt(IP_FREEBIND/IP_TRANSPARENT) and bind(client_src_addr). Which is why -j TPROXY is so puzzling to me.
Hi, On k, szept 18, 2007 at 02:59:50 +0200, Jan Engelhardt wrote:
Case 2 to imagine: with squid; can use -j REDIRECT instead of -j TPROXY.
Well, you can, but then you need NAT.
Where do I need NAT? Squid will use setsockopt(IP_FREEBIND/IP_TRANSPARENT) and bind(client_src_addr). Which is why -j TPROXY is so puzzling to me.
REDIRECT needs NAT. And you can't implement "intercepting" traffic without some kind of redirection. So it's required for squid & co. -- KOVACS Krisztian
On Sep 18 2007 15:05, KOVACS Krisztian wrote:
On k, szept 18, 2007 at 02:59:50 +0200, Jan Engelhardt wrote:
Case 2 to imagine: with squid; can use -j REDIRECT instead of -j TPROXY.
Well, you can, but then you need NAT.
Where do I need NAT? Squid will use setsockopt(IP_FREEBIND/IP_TRANSPARENT) and bind(client_src_addr). Which is why -j TPROXY is so puzzling to me.
REDIRECT needs NAT. And you can't implement "intercepting" traffic without some kind of redirection. So it's required for squid & co.
Right, except that I do not use REDIRECT actually, but let the clients directly (and knowingly) connect to proxy:3128. Whee :)
Hi, On k, szept 18, 2007 at 03:22:37 +0200, Jan Engelhardt wrote:
REDIRECT needs NAT. And you can't implement "intercepting" traffic without some kind of redirection. So it's required for squid & co.
Right, except that I do not use REDIRECT actually, but let the clients directly (and knowingly) connect to proxy:3128. Whee :)
Yep you're right, but that's a completely different scenario. You don't need the TPROXY target in that case. -- KOVACS Krisztian
participants (3)
-
Balazs Scheidler
-
Jan Engelhardt
-
KOVACS Krisztian