Another Linux two-way stateless Nat

If you look at the help of iproute2, you will find that there is a NAT action in the route section, where the via Parameter provides the conversion address. I will not mention the specific configuration. I only propose two points. First, the stateless Nat of iproute2 requires the participation of policy routing. Second, it is removed from the 2.6 kernel. For more information, see the documentation. In the 2.6 kernel, the kernel protocol stack leaves all extensions to netfilter for implementation, and only implements the Standard Minimal set.
Why should we mention the 2.4 kernel Nat route? Now that Nat has been removed, it has philosophical significance to implement Nat in netfilter. Since I have also implemented a two-way stateless Nat Based on Netfilter, what is the significance of the old issue? I told my wife that there is a set of self-explanatory theories behind everything I say and do. No matter how ridiculous it is, it can be self-circular! So now I want to implement a stateless Nat, which also requires theoretical support: it is reasonable to insert NAT into the routing table, because Nat is affected by the route (whether it is a local route or a remote route), it is better to directly remove it in the route. Because the intermediate point of pre/post-routing is routing, why not merge Nat in the routing? Although this is not in line with the netfilter philosophy, it is too good for pragmatism! 2.4 The reason why the NAT route implemented by the kernel is not good is that there are code reasons in addition to philosophical reasons. The implementation code is too messy!
If Nat route is implemented based on the above ideas, there is no need to use policy routing, no need to configure IP rule, and no need to configure two rules. Its flowchart is as follows, and the code is better modified:

We can see that this implementation uses recursive route query, which is not implemented in Linux at all. Therefore, you need to modify some code of Route insertion. I use several flags to identify that this route is used for Nat. Because it is a two-way Nat of stateless, therefore, when you insert a NAT route, it must be automatically generated in another direction. For example, if you insert the following route:
IP Route add dnat x via y
Indicates that all the target X is converted to Y. The following routes must be automatically generated:
IP Route add SNAT y via x
Indicates that all sources whose IP addresses are y must be converted to X. Of course, the following items should not be manually configured. The auto label should be used to name them automatically generated.
The above needs to be explained as SNAT. In principle, SNAT is implemented after the route, otherwise it may be useless. Why is the flowchart SNAT before the route? This is to minimize the number of queries. Otherwise, a lot of useless queries will be performed to check whether all data packets require SNAT, one technique used here is that route query is based on the longest prefix match. If SNAT is required, a detailed 32-bit prefix SNAT route is provided. If no, that means no SNAT is required. Of course, the above flowchart can be optimized, because we realize that because it is a two-way Nat, as long as there is a DNAT, there will be an SNAT, and in turn the same, it will appear in pairs, can we optimize it based on this?
When it comes to recursive queries, I have to say that since the SNAT and DNAT labels have been introduced, can we introduce another recursion mark to indicate regular recursive routes? I think so. Recursive routing is easier to implement, and everything is determined during insertion. because Nat is a recursive route, it can be defined as follows:
# Define rtn_recu rtn_snat | rtn_dnat | rtn_xxx
The insert algorithm of recursive routing is as follows:
 
2.4 The Nat route still running on the kernel is no longer available now. If you want to implement one, you have to re-compile the kernel. But fortunately, it is still done! This Nat route does not require the support of Netfilter, and does not need to introduce other maps in the kernel. It is a route table item and does not need to match each data packet in the non-route lookup layer, it can be optimized by using various routing search algorithms in the kernel. However, according to Cisco's official CCIE tutorial, recursive route lookup requires a balance and a specific name. Recursive queries will undoubtedly consume more CPU resources!
However, the NAT implemented based on Recursive route query is simple and symmetrical. Although it is controversial to insert NAT into the route table, the result is good after trying it. Linux has been gradually tried out, and there is no philosophy behind it. Compared with the BSD of the academic school, isn't Linux's characteristics and advantages just Eclectic?