Summary of NAT type and NAT traversal Technology

 

I. Nat encyclopedia content:

NAT (Network Address Translation) is a conversion technology that converts private (retained) addresses into valid IP addresses. It not only perfectly solves the problem of insufficient lpv4 addresses, it can also effectively avoid attacks from outside the network and hide and protect computers inside the network. It is widely used at present.

Nat can be divided into static Nat, pooled Nat, and port multiplexing NAT (Pat port address translation.

 

Ii. Division of NAT types in NAT traversal technology:

In rfc3489/stun [1], UDP-based NAT penetration technology divides hosts into the following seven Nat types: UDP blocked, open Internet, structured Ric firewall, full cone Nat, restricted cone Nat, port restricted cone Nat, and encrypted Ric Nat. The specific explanation is as follows:

(1) open Internet: the host has a public IP address that allows active and passive responses to UDP communication.
(2) UDP blocked: After the firewall, and the firewall blocks UDP communication.
(3) symmetric firewall: the host has a public IP address, but is located behind the firewall, and the firewall blocks the active UDP Communication of the external host.
(4) full cone NAT: When an intranet host creates a UDP socket and sends UDP packets to it for the first time, Nat will allocate a fixed public network {IP: Port }. After that, any UDP packet sent through this socket is sent through this public network {IP: Port}. At the same time, any external host can use this public network {IP: port} sends a UDP packet to the socket. That is to say, Nat maintains a ing table. The intranet {IP: Port} of the Intranet host corresponds to the Internet {IP: Port. Once this ing relationship is established (an internal host sends data to an external host once), any external host can initiate UDP communication directly to this host in the nat, now the NAT is transparent.
(5) restricted cone NAT: When an intranet host creates a UDP socket and sends UDP packets to the host for the first time, Nat will allocate a public network {IP: Port }. Afterwards, any UDP packet sent through this socket is sent through this public network {IP: Port; any external host (identified by an IP) that has received the data sent from this socket can send a UDP packet to this socket through this public network {IP: Port. That is to say, Nat maintains a ing between the Intranet {IP: Port} and the Internet {IP: Port}, and maintains a {external Host IP address, public network {IP: port} ing to intranet {IP: Port. Therefore, to enable the external host to actively initiate communications to the internal host, the internal host must first initiate a communication to the external host.
(6) port restricted cone NAT: When an intranet host creates a UDP socket and sends UDP packets to the host for the first time, Nat will allocate a public network {IP: Port }. After that, any UDP packet sent to the outside through this socket is sent through this public network {IP: Port}; once the external host is at {IP: Port: after receiving data from this socket, the port} can send UDP packets to this socket through this external host {IP: Port. That is, Nat maintains a ing from the Intranet {IP: Port} to the Internet {IP: Port}, and maintains a {IP: Port} from the {external host },
Ing from Internet {IP: Port} to intranet {IP: Port.

(7) Transport rict NAT: When an intranet host creates a UDP socket and sends a UDP packet to external HOST 1 for the first time, Nat assigns it a public network {IP1: Port 1 }, in the future, all UDP packets sent by the Intranet host to external HOST 1 are sent through the Internet {IP1: Port 1}. When the Intranet host sends UDP packets to external host 2 through this socket, nat assigns a public network {ip2: Port 2} to the server. All UDP packets sent from the Intranet host to external host 2 are sent through the public network {ip2: Port 2. The public network {IP1: Port 1} and public network {ip2: Port 2} are certainly not the same (that is, either the IP address is different or the port is different ). In this case, the external host can send data back to the Intranet host only when it receives data from the Intranet host.

 

Iii. Common NAT traversal technologies:

1. UPnP protocol Traversal

The implementation principle is to dynamically create port ing rules, so that you need to connect the client and the NAT device itself to support the UPnP protocol.

2. algs (Application Layer gateways)

Generally, Nat only converts the IP and port information in the header, and does not analyze the fields in the data load of the application layer, after the corresponding packets are identified, the load information other than the IP header is parsed, the address is converted, and the checksum is re-calculated. Specifically, ALG can process the following protocols: DNS, FTP, h323, sip, HTTP, ils, MSN/QQ, NBT, RTSP, PPTP, TFTP, and GRE. To use this traversal technology, you need to upgrade the NAT translation device. Otherwise, it cannot be supported. This technology cannot solve problems for individual protocols, such as the IPSec protocol.

Currently, Linux Firewall supports most common protocols of ALG.

3. Stun Technology (Simple Traversal of user datateprotocol through network address translators)

This traversal technology uses UDP protocol for UDP punching. For the corresponding RFC, refer to RFC 3489 and RFC 5398. It can only be successfully crossed in non-clustered rict Nat scenarios.

Stun Technology: establish a connection with a third-party server through the STUN Protocol to determine the NAT type of the client. further communication. rfc3489/STUN Protocol process [from cr0_3 Baidu space]. the STUN Protocol defines three testing processes to detect Nat types, as described below:

Test1: STUN client sends a binding request to stun server {IP-c1: Port-c1} through port {IP-s1: Port-s1} (no properties set ). After the stun server receives the request, it returns the IP and port {IP-s1: Port-s1} of the stun client it sees to the stun client as the content of the binding response to the stun client.

Test1 #2: STUN client sends a binding request to stun server {IP-c1: Port-c1} through port {IP-s2: Port-s2} (no properties set ). After stun server receives the request, the stun client's IP and port {IP-s2 #2, port-m1 #2} is returned to stun client as the content of binding response.

Test2: STUN client sends a Binding Request (with the change IP and change port properties set) to stun server {IP-c1: Port-c1} through the port {IP-s1: Port-s1 ). After the stun server receives the request, it returns the IP and port {IP-s2: Port-s2} of the stun client it sees to the stun client as the content of the binding response to the stun client.

Test3: STUN client sends a Binding Request (with the change port property set) to the stun server {IP-c1: Port-c1} through the port {IP-s1: Port-s1 ). After the stun server receives the request, it returns the IP and port {IP-s1: Port-s2} of the stun client it sees to the stun client as the content of the binding response to the stun client.

The Nat type check process is as follows:

1. Perform test1. If the stun client cannot receive the response from the stun server (repeated confirmation), it indicates that the stun client is of the UDP blocked type (or it may be that the stun server is not reachable, otherwise, the stun client compares the returned {IP-m1, Port-m1} with the local {IP-c1: Port-c1}, if the same, this indicates that the local machine is directly connected to the public network. Otherwise, the local machine is located after Nat, but you need to further determine the specific type.

1.1. If the local machine is directly connected to the public network, perform Test2. If the stun client cannot receive a response from the stun server (repeated confirmation), it indicates that the stun client is of the structured Ric firewall type; otherwise, the stun client is of the open Internet type.

1.2. If the local machine is located after Nat, perform Test2. If the stun client can receive a response from the stun server, it indicates that the stun client is full cone Nat; otherwise, further testing is required.

1.2.1. Perform test1 #2. Stun client compare whether the IP-m1 and IP-m1 #2 are the same, if not the same, it means that the stun client is the sort Ric Nat type; otherwise, further testing is required.

1.2.1.1 test3. If the stun client can receive a response from the stun server, it indicates that the stun client is of the restricted cone Nat type; otherwise, the stun client is of the port restricted cone Nat type.

4. Other traversal technologies:

SBC [session Boundary Control]
Ice [interactive connection creation]
Midcom [intermediate Box Technology
Turn [relay NAT traversal]

Iv. Linux Nat types:

Because stun can only traverse non-replica rict Nat types, what type of NAT is created by using masquerade in Linux?

Linux Nat "masquerade" is a symmetric Nat.

 
To resolve this issue, you only need to deny that masquerade is a conical Nat.

In Linux, Address Translation follows two principles:

Try not to modify the source port. That is to say, the source port in the disguised IP address remains unchanged as much as possible.
More importantly, the source address/port and target address/port (the so-called socket) must be unique after the IP is disguised.
Assume the following situations (Intranet has host a and D, and Internet has host B and C ):

Establish the following connections:

A (1000) --> NAT (1000) --> B (2000)
D (1000) --> NAT (1000) --> C (2000)
A (1000) --> NAT (1001) --> C (2000)
We can see that the first two connections follow principle 1 and do not violate principle 2.

The third connection changes the source port to avoid the same socket as the second connection.

Compare the first and third connections, and change the source ports from a (1000) to 1000 and 1001 respectively after Nat. Nat in Linux is symmetric Nat.

V. Comparison Between Cone Nat and symmetric NAT:

Conenat requires that data packets with the same original source address and port pass through address translation, the new source address and port are also the same. In other words, the source address and port after conversion of data packets with different original source address and port must be different.

So, is it better for full cone Nat to be able to penetrate than wide Ric Nat, or a connection that can be established through wide Ric Nat, can it be successful if it is changed to full cone Nat?

 
Assume that:

(Intranet hosts A and D, Internet hosts B and C, UDP port 2000, and client source port 1000. )

1) if a uses this Protocol to access B:

A (1000) --> NAT (1000) ---> B (2000)

Since Linux does not change the source port rules as much as possible, the connection can be established normally when port 1000 is not occupied.

If D also needs to access B at this time:

D (1000) --> NAT (1001)-X-> B (2000)

The port must be changed. Otherwise, two identical sockets will appear, and packets sent from B (2000) to NAT (1000) will not be forwarded to A or D.

 

B rejects the connection because the client's source port is incorrect.

 

In this case, the performance of masquerade and conenat is the same.

 

2) if a connects to B, d initiates a connection like C, and then a initiates a connection to C.

① A (1000) --> NAT (1000) ---> B (2000)

If it is masquerade:

② D (1000) --> NAT (1000) ---> C (2000)

③ A (1000) --> NAT (1001)-X-> C (2000)

For conenat:

② D (1000) --> NAT (1001)-X-> C (2000)

③ A (1000) --> NAT (1000) ---> C (2000)

For masquerade, as long as there are no repeated sockets, we always stick to the principle of not changing the source port as much as possible. Therefore, the second connection still uses the source port 1000, the third connection changes the port to avoid repeated sockets.

 

For conenat, to ensure that all data packets from a (1000) are converted to NAT (1000), d initiates a connection to C, even if no repeated socket is generated, but because port 1000 of Nat has been "occupied" by a (1000), you have to use the new port.

 

It can be seen that different targets produce different results. We cannot say absolutely that at any time, the penetration of fully-conical Nat is better than that of symmetric Nat. For example, in the above example, if there are only connections ① and ②, obviously, symmetric Nat is more suitable.

 

Therefore, in addition to considerations of network security and universal penetration, the NAT type is sometimes determined based on specific applications.

6. Further thoughts:

1. How does one traverse the NAT created by masquerade?

2. How can I create Nat in a Linux system to become a cone Nat? At the same time, how can I create three Nat types: Full cone Nat, restricted cone Nat, and port restricted cone Nat?

 

VII. References:

1. http://datatracker.ietf.org/doc/rfc5389

2. http://datatracker.ietf.org/doc/rfc3489

3. http://blog.csdn.net/ojhsky/article/details/6011232

4. http://hi.baidu.com/bobbypollo/item/81023f4555864cee1f19bc3c

5. http://blog.csdn.net/lyd_253261362/article/details/6451935

6. http://blog.csdn.net/dotphoenix/article/details/4420971