[tproxy] tproxy4 future

[KOVACS Krisztian]

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