The future of tproxy
I was just reading the following post: http://news.gmane.org/find-root.php?message_id=%3c20070103163357.14635.37754... regarding TPROXY Version 4. ie NOT using iptables NAT, but being able to bind to a non-local address. The approach discussed in the post looks and sounds good. How close is it to being ready for production use? Do you consider TPROXY Version 2 (the current TPROXY) safe for production use? What are your future plans for TPROXY? I noticed that there's no plan for NAT in ipv6tables, so are you looking to move away from a NAT approach? Are you considering migrating towards Network Channels? Kind Regards, Nick George
On Fri, 2007-05-25 at 10:45 +0200, Nicholas George wrote:
I was just reading the following post:
http://news.gmane.org/find-root.php?message_id=%3c20070103163357.14635.37754...
regarding TPROXY Version 4. ie NOT using iptables NAT, but being able to bind to a non-local address.
The approach discussed in the post looks and sounds good. How close is it to being ready for production use? Do you consider TPROXY Version 2 (the current TPROXY) safe for production use?
tproxy2 has served us well in production use, so it is safe, however maintaining tproxy2 into the future especially now as ip_conntrack has been replaced with nf_conntrack, is getting more and more difficult. So we think tproxy4 is the only sensible way to go forward. We do not use tproxy4 in production environment yet, but lab testing was performed and functionality-wise it is complete. Patrick McHardy is debating two points in the original patchset: 1) the modification of the routing code, which'd be possible by using marks (which then might conflict with any other use of the marks) 2) a modification of the input path, assigning the socket pointer early As we discussed internally, 2) can be implemented by a another socket lookup, which might be slower but safer (and when using a proxy it does not matter too much anyway), and we'll do what he asked to get tproxy4 merged to mainline. Then, we'll probably maintain the missing bits as a separate patch for our own. A new release of tproxy4 should be expected next week.
What are your future plans for TPROXY? I noticed that there's no plan for NAT in ipv6tables, so are you looking to move away from a NAT approach? Are you considering migrating towards Network Channels?
We definitely want to move away from NAT, and we don't plan to migrate towards network channels. (at least for now). -- Bazsi
On May 26 2007 07:36, Balazs Scheidler wrote:
What are your future plans for TPROXY? I noticed that there's no plan for NAT in ipv6tables, so are you looking to move away from a NAT approach? Are you considering migrating towards Network Channels?
We definitely want to move away from NAT, and we don't plan to migrate towards network channels. (at least for now).
But how is one supposed to fake addresses then? -- most prominent case: squid Jan --
On May 26 2007 22:32, Igmar Palsenberg wrote:
We definitely want to move away from NAT, and we don't plan to migrate towards network channels. (at least for now).
But how is one supposed to fake addresses then?
By bind()'ing to the remote address, like the way it was done in the Linux 2.2 days.
Yeah but you'd still need a local table that lists tproxied sockets, so that for an arbitrary incoming packet it can be decided whether it is to go through the INPUT or FORWARD chain (and subsequently, destination program/host). Jan --
On Sat, 2007-05-26 at 22:45 +0200, Jan Engelhardt wrote:
On May 26 2007 22:32, Igmar Palsenberg wrote:
We definitely want to move away from NAT, and we don't plan to migrate towards network channels. (at least for now).
But how is one supposed to fake addresses then?
By bind()'ing to the remote address, like the way it was done in the Linux 2.2 days.
Yeah but you'd still need a local table that lists tproxied sockets, so that for an arbitrary incoming packet it can be decided whether it is to go through the INPUT or FORWARD chain (and subsequently, destination program/host).
The local table is the "socket hash". We do a socket lookup early in the input path and divert the packet to the local IP stack by changing its dst_entry. -- Bazsi
participants (4)
-
Balazs Scheidler
-
Igmar Palsenberg
-
Jan Engelhardt
-
Nicholas George