I really envy myself, special extreme worship, if I pull the erhu like playing with the Linux network as freely as possible, I dare to ask for a one-month unpaid long vacation, to the park every day to pull the erhu ... It's a pity that I haven't been ringing yet.
One months ago, I made an optimization for NetFilter conntrack, and I'm going to conntrack a table with multiple tables in order to improve the efficiency of the search, which is done independently, and I want to have this optimization in the latest kernel version, but no. But there is a similar, conntrack zone support, this feature is not for optimization, it only adds a key value in the Conntrack, that is, zone, so that the same conntrack or NAT rules can be placed in a different zone. What is the use of this feature? On LWN, there is an article on the artical that says:
The attached largish patch adds support for "conntrack zones",
Which is virtual conntrack tables that can is used to seperate
Connections from different zones, allowing to handle multiple
Connections with equal identities in Conntrack and NAT.
A zone is simply a numerical identifier associated with a network
Device that's incorporated into the various hashes and used to
Distinguish entries in addition to the connection tuples. Additionally
It's used to seperate conntrack defragmentation queues. An iptables
Target for the raw table could is used alternatively to the network
Device for assigning Conntrack entries to zones.
This was mainly useful when connecting multiple private networks using
The same addresses (which unfortunately happens occasionally) to pass
The packets through a set of Veth devices and SNAT each network to a
Unique address, after which they can pass through the "main" zone and
Be handled like regular non-clashing packets and/or has NAT applied a
Second time based F.I. On the outgoing interface.
Something like this, with multiple TUNL and veth devices, each pair
Using a unique zone:
<tunl0/zone 1>
|
Prerouting
|
FORWARD
|
Postrouting:snat to Unique Network
|
<veth1/zone 1>
<veth0/zone 0>
|
Prerouting
|
FORWARD
|
Postrouting:snat to eth0 Address
|
<eth0>
As probably everyone have noticed, this is quite similar
The can do using network namespaces. The main reason for not using
Network namespaces is, it an all-or-nothing approach, you can ' t
Virtualize just connection tracking. Beside the difficulties in
Managing different namespaces from F.I. An IKE or PPP daemon running
In the initial namespace, network namespaces has a quite large
Overhead, especially when used with a large conntrack table.
It was a long-ago article, and I didn't notice it before I wondered. Please note that in the middle of the diagram, is not with my "a single machine test OpenVPN encryption tunnel problem and resolution" in this article is consistent with the scene? Too tm like, is almost the same, but the solution is a different problem! Part of the reason for introducing the Conntrack zone is that some veth-like driver xmit do not clear SKB attached conntrack structure, after all, Nic driver and Conntrack are two separate kernel modules, there is no need to linkage, So don't expect every xmit function to erase the extra structure that SKB attaches. This time zone has played a role in the transition, and the gripe behind it is: I can't guarantee you to clear conntrack, but I can replace it myself.
The previous conntrack only corresponds to a tuple, and each net namespace only maintains a conntrack table that relies on tuple as the lookup key, and a SKB if a veth has been attached to one end of the Conntrack, In addition to the Veth drive does not clear it, then at the other end, the SKB will maintain this conntrack, the administrator can not do any intervention except Notrack, completely by the Conntrack module internal automatic maintenance. The introduction of the Conntrack zone allows you to attach a conntrack template with a zone ID to a specific value in the raw table, the zone ID of the template that indicates the zone that is next in the Conntrack lookup, that's all, In the current mainline implementation, the table is still a table, just a key value. In my own implementation, I split into multiple tables.
Once you have a zone key value, the administrator can intervene from outside to SKB Conntrack. Put aside the implementation of the method, you can think you can set a zone ID for a packet in the iptables raw table, the SKB associated conntrack in the zone to find, in the implementation, you can use the zone as only a key value, You can also use it as a table index to introduce multiple tables (why not?). is memory a problem? Isn't there a way to touch highuser? )。
Erhu did not ring, a lot of questions, track or Notrack?
Linux netfilter conntrack Support for zone
