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.
-
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
