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