[tproxy] tproxy development version 1.1.3

[KOVACS Krisztian]

   Hi,

Jon Nelson wrote:
> I have a few questions.
> First, what are the differences (both from a code standpoint and from an
> application standpoint) between the development and stable versions.
> Specifically, should an application that works with the 'stable' release
> expect to work with the development version?

   Yes, it has the same userspace API as the stable version, so is should 
be perfectly compatible from the userspace standpoint. (You don't have to 
recompile iptables, either.)

   The main difference is a reworked connection tracking entry deletion 
method, which, instead of scanning the conntrack hash table every time a 
conntrack entry related to a tproxy-ed connection is deleted, uses a 
linked list to assign conntrack entries to tproxy's sockrefs (sockets 
which have been assigned). This is in theory much faster under high 
traffic (that is, when your transparent proxying software does a lot of 
assigns, especially for UDP). The stable version using the hash-scanning 
method wastes a lot of CPU time in these cases.

> When is the next 'stable' release expected?

   We're currently testing the 'development' version, and if it works well 
enough for us, it will be released as stable. If this takes too long, or 
we find serious problems with the 'stable' version, those will be fixed, 
of course, but there won't be any serious changes to that branch.

> What tables, other than the tproxy table itself, does the tproxy stuff
> touch /at any time/ throughout a tproxied connection's lifetime?  Does
> the tproxy mechanism touch the NAT table, filter, or other tables?

   It does not touch the tables, so it does not change your ruleset at 
all. However, it applies new NAT mappings to the matching connections, 
just as the 'nat' table does.

> Can you describe the mechanism, at a high level, how this all works from
> the kernel's point of view?

   The 'tproxy' table is very similar to the 'nat' table. For new 
connections, it looks up the sockref hash (sockets which have been 
assigned a foreign IP), and if a match is found, a NAT mapping is applied 
to the connection (based on the values set by setsockopt()). If a matching 
sockref is not found, it evaluates the ruleset in the table (which should 
consist of rules containing TPROXY targets, doing redirection).
   Those NAT mappings are evaluated on the same hooks as NAT mappings 
assigned by DNAT or SNAT targets in the 'nat' table.
   So, from a high level, you should consider the 'tproxy' table as a 
special 'nat' table, which uses a 'dynamic' ruleset assigned by sockopts().

-- 
   Regards,
     Krisztian KOVACS