Patchwork [net-next,16/16] Add documentation

login
register
mail settings
Submitter KOVACS Krisztian
Date Oct. 1, 2008, 2:24 p.m.
Message ID <20081001142431.4893.5367.stgit@este>
Download mbox | patch
Permalink /patch/2271/
State Not Applicable
Delegated to: David Miller
Headers show

Comments

KOVACS Krisztian - Oct. 1, 2008, 2:24 p.m.
Add basic usage instructions to Documentation/networking.

Signed-off-by: KOVACS Krisztian <hidden@sch.bme.hu>
---

 Documentation/networking/tproxy.txt |   85 +++++++++++++++++++++++++++++++++++
 1 files changed, 85 insertions(+), 0 deletions(-)



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Randy Dunlap - Oct. 1, 2008, 4:22 p.m.
On Wed, 01 Oct 2008 16:24:31 +0200 KOVACS Krisztian wrote:

> Add basic usage instructions to Documentation/networking.
> 
> Signed-off-by: KOVACS Krisztian <hidden@sch.bme.hu>
> ---
> 
>  Documentation/networking/tproxy.txt |   85 +++++++++++++++++++++++++++++++++++
>  1 files changed, 85 insertions(+), 0 deletions(-)
> 
> diff --git a/Documentation/networking/tproxy.txt b/Documentation/networking/tproxy.txt
> new file mode 100644
> index 0000000..cf79e60
> --- /dev/null
> +++ b/Documentation/networking/tproxy.txt
> @@ -0,0 +1,85 @@
> +Transparent proxy support
> +=========================
> +
> +This feature adds Linux 2.2-like transparent proxy support to current kernels.
> +To use it, enable NETFILTER_TPROXY, the socket match and the TPROXY target in
> +your kernel config. You will need policy routing too, so be sure to enable that
> +as well.
> +
> +
> +1. Making non-local sockets work
> +================================
> +
> +The idea is that you identify packets with destination address matching a local
> +socket your box, set the packet mark to a certain value, and then match on that

          on your box   (?)

> +value using policy routing to have those packets delivered locally:
> +
> +# iptables -t mangle -N DIVERT
> +# iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT
> +# iptables -t mangle -A DIVERT -j MARK --set-mark 1
> +# iptables -t mangle -A DIVERT -j ACCEPT
> +
> +# ip rule add fwmark 1 lookup 100
> +# ip route add local 0.0.0.0/0 dev lo table 100
> +
> +Because of certain restrictions in the IPv4 routing output code you'll have to
> +modify your application to allow it sending datagrams _from_ non-local IP

                                       to send datagrams

> +addresses. All you have to do is to enable the (SOL_IP, IP_TRANSPARENT) socket

                                 is enable the

> +option before calling bind:
> +
> +fd = socket(AF_INET, SOCK_STREAM, 0);
> +/* - 8< -*/
> +int value = 1;
> +setsockopt(fd, SOL_IP, IP_TRANSPARENT, &value, sizeof(value));
> +/* - 8< -*/
> +name.sin_family = AF_INET;
> +name.sin_port = htons(0xCAFE);
> +name.sin_addr.s_addr = htonl(0xDEADBEEF);
> +bind(fd, &name, sizeof(name));
> +
> +A trivial patch for netcat is available here:
> +http://people.netfilter.org/hidden/tproxy/netcat-ip_transparent-support.patch
> +
> +
> +2. Redirecting traffic
> +======================
> +
> +Transparent proxying often involves "intercepting" traffic on a router. This is
> +usually done with the iptables REDIRECT target, however, there are serious

                                           target;

> +limitations of that method. One of the major issues is that it actually
> +modifies the packets to change the destination address -- which might not be
> +acceptable in certain situations. (Think of proxying UDP for example: you won't
> +be able to find out the original destination address. Even in case of TCP
> +getting the original destination address is racy.)
> +
> +The 'TPROXY' target provides similar functionality without relying on NAT. Simply
> +add rules like this to the iptables ruleset above:
> +
> +# iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY \
> +  --tproxy-mark 0x1/0x1 --on-port 50080
> +
> +Note that for this to work you'll have to modify the proxy to enable (SOL_IP,
> +IP_TRANSPARENT) for the listening socket.

Thanks.
---
~Randy
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jan Engelhardt - Oct. 3, 2008, 2:01 p.m.
On Wednesday 2008-10-01 10:24, KOVACS Krisztian wrote:

>+Transparent proxy support
>+=========================
>+
>+This feature adds Linux 2.2-like transparent proxy support to current kernels.
>+To use it, enable NETFILTER_TPROXY, the socket match and the TPROXY target in
>+your kernel config. You will need policy routing too, so be sure to enable that
>+as well.

To use server-side transparent proxying (i.e. using a foreign address
when sending out packets), only tproxy_core is needed.

>+fd = socket(AF_INET, SOCK_STREAM, 0);

You want to be using IPPROTO_TCP here, as I doubt there is a guarantee
that 0 will never choose SCTP.

>+int value = 1;

Const is good:
	static const unsigned int value = 1;

>+setsockopt(fd, SOL_IP, IP_TRANSPARENT, &value, sizeof(value));
>+/* - 8< -*/
>+name.sin_family = AF_INET;
>+name.sin_port = htons(0xCAFE);
>+name.sin_addr.s_addr = htonl(0xDEADBEEF);

Replace last one by
	inet_pton(PF_INET, "192.0.2.37", &name.sin_addr);

(Hacking anything inside sin_addr is, strictly speaking, breaking the
“encapsulation”, as far as that “exists” in C.)

>+bind(fd, &name, sizeof(name));

You will need

	bind(fd, (const void *)&name, sizeof(name));

to avoid a compiler warning ;-)

>+2. Redirecting traffic
>+======================
>+
>+Transparent proxying often involves "intercepting" traffic on a router. This is
>+usually done with the iptables REDIRECT target, however, there are serious
>+limitations of that method. One of the major issues is that it actually
>+modifies the packets to change the destination address -- which might not be
>+acceptable in certain situations. (Think of proxying UDP for example: you won't
>+be able to find out the original destination address. Even in case of TCP
>+getting the original destination address is racy.)

IIRC, you _can_ find out, though I agree it's rather a hack (with 
tproxy, you can just use the address as received via recvmsg):

	getsockopt(fd, SOL_IP, SO_ORIGINAL_DST, &sockaddr, &sizeptr);

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
KOVACS Krisztian - Oct. 7, 2008, 7:01 a.m.
Hi,

On Fri, 2008-10-03 at 10:01 -0400, Jan Engelhardt wrote:
> On Wednesday 2008-10-01 10:24, KOVACS Krisztian wrote:
> 
> >+Transparent proxy support
> >+=========================
> >+
> >+This feature adds Linux 2.2-like transparent proxy support to current kernels.
> >+To use it, enable NETFILTER_TPROXY, the socket match and the TPROXY target in
> >+your kernel config. You will need policy routing too, so be sure to enable that
> >+as well.
> 
> To use server-side transparent proxying (i.e. using a foreign address
> when sending out packets), only tproxy_core is needed.
> 
> >+fd = socket(AF_INET, SOCK_STREAM, 0);
> 
> You want to be using IPPROTO_TCP here, as I doubt there is a guarantee
> that 0 will never choose SCTP.
> 
> >+int value = 1;
> 
> Const is good:
> 	static const unsigned int value = 1;
> 
> >+setsockopt(fd, SOL_IP, IP_TRANSPARENT, &value, sizeof(value));
> >+/* - 8< -*/
> >+name.sin_family = AF_INET;
> >+name.sin_port = htons(0xCAFE);
> >+name.sin_addr.s_addr = htonl(0xDEADBEEF);
> 
> Replace last one by
> 	inet_pton(PF_INET, "192.0.2.37", &name.sin_addr);
> 
> (Hacking anything inside sin_addr is, strictly speaking, breaking the
> “encapsulation”, as far as that “exists” in C.)
> 
> >+bind(fd, &name, sizeof(name));
> 
> You will need
> 
> 	bind(fd, (const void *)&name, sizeof(name));
> 
> to avoid a compiler warning ;-)

Jan, while you're right I think the point of the aim of the example is
to show you that you only need to set the IP_TRANSPARENT flag before
being able to bind to a non-local address.

I'm not opposed to the changes, though, so could you please send a patch
on top of Dave's current net-next tree? Thanks.

> 
> >+2. Redirecting traffic
> >+======================
> >+
> >+Transparent proxying often involves "intercepting" traffic on a router. This is
> >+usually done with the iptables REDIRECT target, however, there are serious
> >+limitations of that method. One of the major issues is that it actually
> >+modifies the packets to change the destination address -- which might not be
> >+acceptable in certain situations. (Think of proxying UDP for example: you won't
> >+be able to find out the original destination address. Even in case of TCP
> >+getting the original destination address is racy.)
> 
> IIRC, you _can_ find out, though I agree it's rather a hack (with 
> tproxy, you can just use the address as received via recvmsg):
> 
> 	getsockopt(fd, SOL_IP, SO_ORIGINAL_DST, &sockaddr, &sizeptr);

This is true only if you have connection tracking loaded while the new
tproxy can be used without conntrack.
David Miller - Oct. 7, 2008, 7:50 p.m.
Randy Dunlap asked for some corrections to this documentation patch,
and I also think that Patrick should take this one since it only
makes sense once the netfilter side of this patch set is present.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
KOVACS Krisztian - Oct. 7, 2008, 8:02 p.m.
Hi,

On k, okt 07, 2008 at 12:50:51 -0700, David Miller wrote:
> Randy Dunlap asked for some corrections to this documentation patch,
> and I also think that Patrick should take this one since it only
> makes sense once the netfilter side of this patch set is present.

Sure, thanks a lot. The corrections from Randy Dunlap are already in
Patrick's tree.
Patrick McHardy - Oct. 7, 2008, 8:47 p.m.
KOVACS Krisztian wrote:
> Hi,
>
> On k, okt 07, 2008 at 12:50:51 -0700, David Miller wrote:
>   
>> Randy Dunlap asked for some corrections to this documentation patch,
>> and I also think that Patrick should take this one since it only
>> makes sense once the netfilter side of this patch set is present.
>>     
>
> Sure, thanks a lot. The corrections from Randy Dunlap are already in
> Patrick's tree.al
>   

Just FYI: I hope to finally get all the netfilter patches out
by tommorrow.


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Miller - Oct. 7, 2008, 8:53 p.m.
From: Patrick McHardy <kaber@trash.net>
Date: Tue, 07 Oct 2008 22:47:30 +0200

> KOVACS Krisztian wrote:
> > Hi,
> >
> > On k, okt 07, 2008 at 12:50:51 -0700, David Miller wrote:
> >   
> >> Randy Dunlap asked for some corrections to this documentation patch,
> >> and I also think that Patrick should take this one since it only
> >> makes sense once the netfilter side of this patch set is present.
> >>     
> >
> > Sure, thanks a lot. The corrections from Randy Dunlap are already in
> > Patrick's tree.al
> >   
> 
> Just FYI: I hope to finally get all the netfilter patches out
> by tommorrow.

I was just about to ping you about this, thanks :-)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Philip Craig - Oct. 8, 2008, 12:32 a.m.
Jan Engelhardt wrote:
>> +2. Redirecting traffic
>> +======================
>> +
>> +Transparent proxying often involves "intercepting" traffic on a router. This is
>> +usually done with the iptables REDIRECT target, however, there are serious
>> +limitations of that method. One of the major issues is that it actually
>> +modifies the packets to change the destination address -- which might not be
>> +acceptable in certain situations. (Think of proxying UDP for example: you won't
>> +be able to find out the original destination address. Even in case of TCP
>> +getting the original destination address is racy.)
> 
> IIRC, you _can_ find out, though I agree it's rather a hack (with 
> tproxy, you can just use the address as received via recvmsg):
> 
> 	getsockopt(fd, SOL_IP, SO_ORIGINAL_DST, &sockaddr, &sizeptr);

Yes, but the problem is that SO_ORIGINAL_DST is only implemented for TCP.
And I guess that the race for TCP is that the conntrack may not exist when you
call getsockopt() (not sure that is something you'll hit in practice though).

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/Documentation/networking/tproxy.txt b/Documentation/networking/tproxy.txt
new file mode 100644
index 0000000..cf79e60
--- /dev/null
+++ b/Documentation/networking/tproxy.txt
@@ -0,0 +1,85 @@ 
+Transparent proxy support
+=========================
+
+This feature adds Linux 2.2-like transparent proxy support to current kernels.
+To use it, enable NETFILTER_TPROXY, the socket match and the TPROXY target in
+your kernel config. You will need policy routing too, so be sure to enable that
+as well.
+
+
+1. Making non-local sockets work
+================================
+
+The idea is that you identify packets with destination address matching a local
+socket your box, set the packet mark to a certain value, and then match on that
+value using policy routing to have those packets delivered locally:
+
+# iptables -t mangle -N DIVERT
+# iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT
+# iptables -t mangle -A DIVERT -j MARK --set-mark 1
+# iptables -t mangle -A DIVERT -j ACCEPT
+
+# ip rule add fwmark 1 lookup 100
+# ip route add local 0.0.0.0/0 dev lo table 100
+
+Because of certain restrictions in the IPv4 routing output code you'll have to
+modify your application to allow it sending datagrams _from_ non-local IP
+addresses. All you have to do is to enable the (SOL_IP, IP_TRANSPARENT) socket
+option before calling bind:
+
+fd = socket(AF_INET, SOCK_STREAM, 0);
+/* - 8< -*/
+int value = 1;
+setsockopt(fd, SOL_IP, IP_TRANSPARENT, &value, sizeof(value));
+/* - 8< -*/
+name.sin_family = AF_INET;
+name.sin_port = htons(0xCAFE);
+name.sin_addr.s_addr = htonl(0xDEADBEEF);
+bind(fd, &name, sizeof(name));
+
+A trivial patch for netcat is available here:
+http://people.netfilter.org/hidden/tproxy/netcat-ip_transparent-support.patch
+
+
+2. Redirecting traffic
+======================
+
+Transparent proxying often involves "intercepting" traffic on a router. This is
+usually done with the iptables REDIRECT target, however, there are serious
+limitations of that method. One of the major issues is that it actually
+modifies the packets to change the destination address -- which might not be
+acceptable in certain situations. (Think of proxying UDP for example: you won't
+be able to find out the original destination address. Even in case of TCP
+getting the original destination address is racy.)
+
+The 'TPROXY' target provides similar functionality without relying on NAT. Simply
+add rules like this to the iptables ruleset above:
+
+# iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY \
+  --tproxy-mark 0x1/0x1 --on-port 50080
+
+Note that for this to work you'll have to modify the proxy to enable (SOL_IP,
+IP_TRANSPARENT) for the listening socket.
+
+
+3. Iptables extensions
+======================
+
+To use tproxy you'll need to have the 'socket' and 'TPROXY' modules
+compiled for iptables. A patched version of iptables is available
+here: http://git.balabit.hu/?p=bazsi/iptables-tproxy.git
+
+
+4. Application support
+======================
+
+4.1. Squid
+----------
+
+Squid 3.HEAD has support built-in. To use it, pass
+'--enable-linux-netfilter' to configure and set the 'tproxy' option on
+the HTTP listener you redirect traffic to with the TPROXY iptables
+target.
+
+For more information please consult the following page on the Squid
+wiki: http://wiki.squid-cache.org/Features/Tproxy4