Re: [PATCH 00/13] Transparent Proxying Patches, Take 3

[Patrick McHardy <kaber@trash.net>]

KOVACS Krisztian wrote:
> Hi Patrick,
>
> These patches are our (Balazs, Attila and me) third try at providing Linux
> 2.2-like transparent proxying support for Linux 2.6. During the 5th Netfilter
> Workshop in Karlsruhe, Germany we tried to come up with an even more
> lightweight approach not requiring the modification of the IPv4 routing code at
> all.
>
> The most important changes relative to the previous versions[1,2] 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 (this hopefully makes it possible to
>    implement IPv6 support in the future
>  * 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.
>
> Usage is a bit more complicated compared to the previous approach, but it's
> certainly not rocket science:
>
> # iptables rules necessary:
> # 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
>
> # set up advanced routing rules to deliver our marked packets locally
> ip rule add fwmark 1 lookup 100
> ip route add local 0.0.0.0/0 dev lo table 100
>
> The proxy code needs to be modified as well, but these are really lightweight:
> before binding, the IP_TRANSPARENT sockopt needs to be enabled on the socket.
> This implies IP_FREEBIND, so after enabling this socket option non-local binds
> will work and if you got your iptables/iproute setup right non-local traffic
> will be delivered to/from the socket. A netcat patch demonstrating this is
> available[4] as an example.
>
> Some word about the patches:
>
>  * output path (patches 1-5): these modifications make it possible to
>    output IPv4 datagrams with non-local IP addresses by:
>    - introducing a new flowi flag (FLOWI_FLAG_ANYSRC) which disables the source
>      address check in ip_route_output_slow() [3]
>    - adding the IP_TRANSPARENT socket option (setting this requires CAP_NET_ADMIN)
>    - setting FLOWI_FLAG_ANYSRC if IP_TRANSPARENT is enabled for the originating
>      socket
>    - set FLOWI_FLAG_ANYSRC where appropriate for sending reply packets
>      generated by the kernel; this requires extending the ip_reply_arg
>      structure with a flags field and adding an IP_REPLY_ARG_NOSRCCHECK flag
>
>  * input patch (patches 6-13): these changes implement redirection support for
>    TCP plus the iptables socket match and TPROXY target -- these provide the
>    actual user interface:
>    - split IPv4 defragmentation into a separate module, as this is needed by
>      both our target and match
>    - add a 'socket' match which does a socket lookup based on the destination
>      tuple in the packet and matches is a socket has been found
>    - add a 'TPROXY' target which looks up a socket based on a modified IP/port
>      tuple and stores the socket reference in the skb
>    - modifying the TCP/UDP input paths to use the stored socket reference if
>      present
>
> All kinds of comments welcome. Patrick, I'd like to ask you to review these
> patches and if no issues are found by you or by anyone on the list, please
> consider merging them.
>   

Thanks for posting these patches. I'll gladly review them, but
the patches touching things outside of netfilter need to go
through netdev and Dave for merging.