[tproxy] tproxy development version 1.1.3
Fri, 31 Oct 2003 10:45:55 +0100
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().