Thoughts on Nat implementation in Linux

DNAT is mainly used to protect the servers inside the NAT. It is used to actively connect to the internal server, while SNAT is the opposite. To protect and limit the internal network client, in Linux, Nat is based on the Connection Tracing module. The Connection Tracing module tries to associate each packet with a connection, the result is that either the data packet belongs to an existing connection or the data packet does not belong to any existing connection. In this case, the Connection Tracing module will create a connection for this data packet, obviously, this data packet is the first data packet of this connection. If a connection exactly matches a NAT rule, the rule will be attached to the structure indicating the connection. in Linux, It is the ip_conntrack structure, and the NAT rule is in this structure, ip_nat_info. the array of ip_nat_info_manip type indicates the NAT conversion rules in every direction of each hook point. We know that Nat in Linux has four hook points in total, post-routing and local-in are SNAT points, while pre-routing and local-out are DNAT points. If a connection hits the above Hook Point, symmetric hook points in the opposite direction are automatically hit. That is to say, if SNAT is executed on post-routing, if data comes in for the same connection, therefore, DNAT must be executed on pre-routing. Therefore, the number of arrays of the ip_nat_info_manip type can be at most 6, which are pre-routing <=> post-Rou Ting, local-in <=> Local-out, local-out-> post-routing, pre-routing-> Local-in, we can see that, the conversion source address or destination address on each hook point is fixed, not because you have changed the SNAT configuration or DNAT configuration. Why do you need to distinguish between SNAT and DNAT? For more information, see RFC. Here is an obvious reason. Because the implementation of NAT is based on a connection, the problem of who initiated the connection is that if there is no direction in Nat, that is to say, if SNAT is set to take effect automatically in the opposite direction, many useless logic will be executed. For example, a host on the external network wants to connect to the internal network, because the SNAT configured for the internal network automatically takes effect for external access to the internal DNAT, the connection management hook finds that a new connection structure will be initialized after the connection is established and then handed over to the NAT hook, because a rule is found, the address is converted and then sent to another filter hook. In general, the internal client host does not allow passive connection, therefore, many such requests for external connections to internal clients are rejected by the firewall, so the previous address translation is meaningless. If you really need external access to the internal server, configure a DNAT, instead of relying on SNAT's response to this implicit DNAT.
There are two other problems with Nat. The first problem is that the internal customer uses a public IP address to access the internal server. In this case, you need to configure a loopback Nat In the gateway, that is to say, SNAT and DNAT are performed for incoming packets through the Intranet interface and access to the Intranet server at the same time. SNAT changes the IP address of the Intranet client to a public IP address, DNAT changes the public network server IP address to the Intranet Server IP address, and the returned packet is used for reverse operations. The reason why the Back-to-loop Nat is set is that if the Back-to-loop Nat is not set, the client requests can still be sent to the server, however, by viewing the source address of the request, the server finds that the request belongs to the same network segment, so it directly sends a reply to the client instead of sending it to the gateway, after receiving a direct reply from the server, the client will discard the reply because the source address is incorrect (the source address of the server should be a public address ); the second problem is why Nat occurs on local-in and local-out. This is specially set for the NAT Gateway process because data packets are generated locally or flow to the local, therefore, pre-routing is actually a local- For the data flowing to the local machine, post-routing is actually a local-in, so why is it really not easy to answer this question by installing a NAT hook on pre/post-routing, you need to find a balance between routes, filters, and Nat. The method to find a balance point is to find different connections based on the flow of multiple data entries. In {route cost, filter cost, nat cost} the smallest cost in the three tuples. for outgoing data, it is a good choice to perform Nat after the route and filter are completed. symmetric speaking, DNAT should be placed before filtering and routing, then, SNAT's response to Uu-SNAT, that is, the coincidence between the location of the DNAT and the location of the original DNAT, is the most simplified design. Finally, to cater to non-foward data packets, the local-in and local-out vertices are symmetric with pre-routing and post-routing over foward. In terms of topology, Nat in Linux is a saddle design, this saddle surface has no extreme points, but has the most balance.
Finally, although the kernel's netfilter provides five hook points, for the iptables utility, these five hook points cannot be combined at will, for example, filters cannot mount hooks on pre-routing and post-routing. They can only mount hooks on local-in, local-Out, And foward, in addition, Nat cannot mount DNAT on post-routing. These restrictions are not impossible, but iptables provides the best combination policies. The rest of the combinations do not make much sense, in addition, this makes it easier to configure the firewall and Nat, and all configuration standards are fully in accordance with the iptables recommendations, just as the above analysis of the Saddle-face Nat, the advice of iptables is a larger saddle surface, while netfilter is just a plane, iptables converts it into a saddle surface.