Linux NAT implementation

In Linux, NAT is actually a proxy for all machines in NAT. The NAT classification is based on the proxy, whether it is based on the NAT implementation of the connection, the packet-based NAT implementation must handle a ing relationship, that is, how to convert the returned packet of the converted package... in Linux, NAT is actually a proxy for all machines in NAT. The NAT classification is based on "how to proxy", whether it is a connection-based NAT implementation, to implement packet-based NAT, you must handle a ing relationship, that is, how to convert the returned packet of the converted package back to the original one. In Linux, NAT is symmetric instead of conical NAT, although in many cases, Linux NAT looks more like a conical NAT. Www.2cto.com only needs to understand the nature of NAT in Linux, even if it does not understand the NAT classification. The principle of implementing NAT in Linux is simple: Ensure the uniqueness of a tuple quintuple in the quintuple before the conversion and the converted quintuple at the minimum cost.
Note that these two quintuple are stored separately, and they are not associated at the hash linked list layer. In fact, this is the essence of ip_conntrack. ip_conntrack stores connections in two directions. Therefore, a quintuple is required to be unique in two-direction hash tables. Some people say that Linux can implement conical NAT, but this conical NAT is actually very fragile. Consider the following connections: (PC: 1234-> SERVER: 80)
Therefore, the following tuple (quintuple) appears on the NAT: forward direction: (PC1: 1234-> SERVER: 80) reverse direction: (SERVER: 80-> NAT: 1234) if PC2 uses port 1234 to connect to the 80 of SERVER2 at this time, two new tuple pairs will appear in NAT: (PC2: 1234-> SERVER2: 80) in the opposite direction: (SERVER2: 80-> NAT: 1234) at this time, if PC1 also wants to use port 1234 to connect to port 80 of SERVER2, as follows: (PC1: 1234-> SERVER2: 80) reverse direction :? Www.2cto.com
Why is it a "?" What about it? If NAT in Linux is a conical NAT, NAT needs to convert the source group of PC2 to (NAT: 1234-> SERVER2: 80). In this case, the tuple in the opposite direction is (SERVER2: 80-> NAT: 1234), which is in conflict with the tuple in the opposite direction of PC2. this is not acceptable. Linux automatically changes its source port, to (NAT: not 1234-> SERVER2: 80), and then to the reverse direction tuple (SERVER2: 80-> NAT: not 1234), thus solving the uniqueness problem, with the help of a third party, Linux becomes symmetric NAT... as for the Port Restricted Cone, Restricted Cone, and Full Cone in the conical NAT, you don't need to discuss them. the purpose of these three types of cones is to limit the penetration of reverse traffic, A clear classification will make the policy more convenient to implement. the reason why NAT is divided into cone and symmetric, and the cone is divided into three categories, this is completely for the purpose of implementation. Now RFC3489, and this RFC is the cornerstone of the punching technology, that is, classification is to describe the implementation of the punching more convenient and concise. In turn, the reason why NAT can be crossed (successful penetration) is that the RFC describing NAT itself does not specify its implementation method, nor does it specify "not allow traversal ", linux only guarantees the NAT results according to RFC, which is also one of the implementations rather than the only ones.
This article first mentioned that NAT needs to solve a ing problem, and the intersection of all the identification information carried by a packet is a quintuple. Therefore, NAT can be used to limit the connection, the number of connections that a NAT device can open is determined by the public IP address it holds and the number of available ports, such as the following rules: www.2cto.com iptables-t nat-a postrouting-p -- dport 80-j SNAT -- to-source X. x. x. x: 80 then after the entire NAT, only one socket of a machine can be connected to port 80 of the same target. Otherwise, the tuple in the opposite direction will conflict. You can view all subsequent connections in the insert_failed column of the/proc/net/stat/ip_conntrack file to see that the counter increments as it conflicts with the existing reverse direction tuple. Linux does not distinguish between the XX caused by RFC3489, or even the conical NAT and symmetric NAT. only the NAT results are guaranteed. Author dog250