Complete Nat analysis and complete UDP penetration Solution

Original translated from: http://blog.csdn.net/colinchan/archive/2006/05/08/712773.aspx

I. Basic Terms

Firewall

The firewall limits the communication between the private network and the public network. It mainly discards the packets that are considered unauthorized by the firewall. The firewall only checks the data of the packets, the IP address and TCP/UDP port information in the data packet are not modified.

Network Address Translation (NAT)

When a packet passes, the network address converter not only checks the packet information, but also modifies the IP address and port information in the packet header. In this way, the machine that is in Nat can share several public IP addresses (usually one ). There are two main types of network address converters.

P2PApplicationProgram

P2P applications refer to establishing an end-to-end session communication based on an existing public server and using its own private address or public address (or both.

P2PFirewall

P2P Firewall is a P2P proxy that provides firewall functions, but does not perform address conversion.

P2P-NAT

P2P-NAT is a P2P proxy, provides the function of NAT, also provides the function of firewall, the simplest P2P proxy must have the function of cone Nat to UDP communication support, it also allows applications to establish robust P2P connections using UDP hole-hitting technology.

Loop Conversion

When the NAT Intranet Machine wants to access the machine in the same LAN through a public address, the NAT device is equivalent to doing Nat twice, before the package arrives at the target machine, convert the private address to the public address, and then convert the public address back to the private address. We call a NAT device with the upstream translation function a "loop translation" device.

Ii. Nat Classification

Can be dividedBasic NatAndNetwork address and port conversion (napt)Two categories

(1): Basic Nat

Basic Nat converts the private IP address of a private network host to a public IP address, but does not convert the TCP/UDP port information. Basic Nat is generally used when Nat has many public IP addresses, it binds the public IP address with the internal host, so that the external can use the public IP address to access the internal host. (In fact, only the IP address is converted, 192.168.0.23 <-> 210.42.106.35, which is different from directly setting the IP address to a public IP address, especially for enterprises, all external information must pass through the unified firewall before it can reach the internal, but the internal host can use the public ip)

(2) network address and port conversion (napt)

This is the most common situation. The network address/port converter checks and modifies the packet IP address and TCP/UDP port information, so that more internal hosts can use a public IP address at the same time.

For more information about Nat categories and terms, see [rfc1631], [rfc2993], and [rfc2663. In addition, [rfc2663] has made more definitions about napt classification and terminology. When an intranet host opens an out-of-office TCP or UDP session through NAT, napt assigns this session a public IP address and port to receive packets from the Internet, and the host is notified through conversion. In this way, napt establishes a port binding between [private IP: Private Port] and [Public IP: public port.

Port binding specifies that napt will perform address translation tasks during the lifetime of this session. There is a problem in the middle. If a P2P application sends multiple sessions to different Internet hosts from a [private IP Address: Port] on the internal network, what Will Nat do? This can be dividedConical Nat(Cone Nat) andSymmetric NAT (symmtric Nat)) To consider:

A.Conical Nat

(Why is it a cone? Please refer to the form. Both the terminal and external server send information through the bound address pair assigned by Nat, just like a funnel, filtering and passing information)

After a [private IP: Port]-[Public IP: Port] port is bound, for a session from the same [private IP: Port, the conical Nat server allows the application that initiates the session to repeat the port binding until the session ends (Port binding ).

For example, if Client A (as shown in the IP address information) initiates two outgoing connections simultaneously through a conical Nat, it uses the same internal port (10.0.0.1: 1234) for two different servers on the public network, S1 and S2. Only one public IP address and port (155.99.25.11: 62000) are allocated to the two sessions, address translation ensures that the client uses the port "same" (that is, this client only uses this port ). However, the basic NATs and firewall cannot modify the port number of the data packet. They can be seen as the simplified version of the conical Nat.

For further analysisCone NatRestricted conical NAT (restrict cone)AndPort restricted conical NAT (Port restrict cone)Three categories:DividedFull-duplex conical Nat (Full cone),

1.Full-duplex conical Nat

When an internal host sends out a connection session, a public/private address is created. Once this address pair is created, full-duplex conical Nat receives the communication from any external port that is subsequently passed in to this public port address. Therefore, full-duplex conical Nat is sometimes called "hybrid" nat.

2.Restricted conical Nat

Restricted conical Nat filters incoming packets. When an internal host sends an "out" session, Nat records the IP address of the external host, only these recorded external IP addresses can pass information into the nat, the restricted conical Nat effectively refines the packet filtering principle for the firewall-that is, only the known external addresses are allowed to "pass" the information to the nat.

3.Limited-port conical Nat

The restricted conical Nat port, which is different from the restricted conical NAT: it records the IP address and port information of the external host at the same time, the restricted conical NAT provides the same level of protection for internal nodes. When the port is "same", the information returned by Symmetric Nat is discarded.

B.Symmetric Nat

Symmetric Nat is very different from cone Nat. Instead of binding ports to sessions, a new public port is allocated to each new session.

In the preceding example, if Client A (10.0.0.1: 1234) initiates two "outbound" sessions and sends them to S1 and S2 respectively. Symmetric NAT will assign the public address 155.99.25.11: 62000 to session1, and then assign another different public address 155.99.25.11: 62001 to session2. Symmetric Nat can distinguish two different sessions and perform address translation, because the external addresses in session1 and session2 are different because, the client-side application gets lost in this address translation boundary line, because each session sent by this application uses a new port, and it cannot be guaranteed that only the same port is used.

In TCP and UDP Communication (whether to use the same port or assign different ports to the same application), there are different reasons for conical Nat and symmetric Nat. Of course, conical NAT provides more categories for connecting Nat accepted connections to a created address based on fair conditions. This classification is generally applied to UDP Communication (rather than TCP communication), because NATs and firewall prevent TCP connections that attempt to pass in unconditionally, unless Nat is explicitly set.

Iii. Nat session Processing

The following analyzes the policies that napt uses to determine whether to establish a session for a UDP packet sent by a request. There are several policies:

A. the source address (intranet IP address) is different. If you ignore other factors, the napt must correspond to different sessions.

B. If the source address (intranet IP address) is the same and the source port is different and other factors are ignored, the napt must correspond to different sessions.

C. If the source address (intranet IP address) is the same, the source port is the same, the destination address (Public IP address) is the same, and the destination port is different, the napt must correspond to the same session.

D. The source address (intranet IP address) is the same, the source port is the same, and the destination address (Public IP address) is different. If the destination port is ignored, how does one process the session on the napt?

A, B, and C are simple and easy to implement. D is complicated. so D is what we should focus on and discuss.

Iv. Complete Solution

The following is a complete solution for four kinds of sessions and four types of NAT. The following abbreviations are used for convenience:

C stands for Cone Nat

S stands for symmetric Nat,

FC stands for full cone Nat,

RC stands for restrict cone Nat,

PC stands for port restrict cone Nat.

The number of clients after Nat can be divided into two categories:

Type one:One is after Nat and the other is in the public network..

In this case, it can be divided into two categories:

A.SVSPublic Network:In this case, because the public network address remains unchanged in a session, it can be successful.

B.CVSPublic Network:Similar to the above, this kind of situation can be successful.

Type two:Both customers are behind Nat.

In this case, it can be subdivided into two categories:

A.One Nat isS (elastic Ric Nat)Type, Namely:SVSCOrSVSS.

The following example shows that this kind of logging is not feasible. In the conventional logging, all customers first log on to a server. the server records the [Public IP: Port] of each customer, and then uses the record value during the punching process. However, for the S-type Nat, it is not bound to the [private IP: port] and [Public IP: Port] ing. therefore, in different sessions, Nat will re-allocate a pair of [Public IP: Port]. in this way, for S-type Nat, the [Public IP: Port] is different from the [Public IP: Port] registered on the server. there is also no way to notify another client that is located under Nat of the [Public IP: Port. however, if the other client is in the public network, it is possible to create a hole. we have already demonstrated this situation.

In this case, the solution can only be implemented through port prediction. The specific solution is as follows: for example, (take two S-type instances as examples) Nat a allocates its own UDP port 62000, it is used to maintain the communication sessions between Client A and server s, and Nat B is also allocated with port 31000 to maintain the communication sessions between client B and server S. Through the conversation with server s, Client A and client B both know the real IP address and port mapped by the other party.

Client A sends a UDP message to 138.76.29.7: 31001 (Please note that the port number is increased), and client B sends a UDP message to 155.99.25.11: 62001. If Nat A and Nat B continue to assign a port to a new session, and the session time from the A-S and B-S is not much consumed, A two-way session channel is established between Client A and client B.

The message sent by Client A to client B causes Nat a to open a new session, and we want Nat a to assign port 62001 to the new session, because 62001 is followed by 62000, Nat will automatically assign the port number for the new session from server s to Client A; similarly, the message sent by client B to a causes Nat B to open a new session, and we hope that Nat B will assign port 31001 to the new session; if both clients correctly guess the port number assigned to the new session of the peer, the two-way connection of the client a-client B will be connected. The result is shown in:

Obviously, many factors may cause this method to fail: If the predicted new ports (62001 and 31001) are used by an unrelated session, the Nat will skip this port number, and the connection will fail. If two Nat addresses sometimes or do not generate new port numbers in order, this method will not work.

If a different client X (or after Nat B) after Nata opens a new "outbound" UDP connection, regardless of the purpose of the connection; as long as this action occurs after Client A establishes a connection with server s, before client a establishes a connection with client B; then this unrelated client X will "steal" the port we are eager to allocate without preparation. Therefore, this method becomes so fragile and vulnerable. As long as any Nat party includes the above problems, this method will not work.

This method is still practical in the network environment of the cone Nat series; if one party is cone Nat and the other party is symmetric Nat, then the application should first discover the type of Nat on the other side, and then make the correct action to handle the communication, which increasesAlgorithmAnd reduce the universality in the real network environment.

Finally, if the peer-to-peer network is under two or more Nat levels and these NATs are nearing this client as nat-based NAT, the port number prediction is invalid!

Therefore, it is not recommended to use this method to write new P2P applications. This is also a historical experience and lesson!

B.TwoAll are cone NatOf.

In this case, there are six types:

A: Fc + FC

B: Fc + RC

C: Fc + PC

D: PC + RC

E: PC + PC

F: RC + RC

Although there are many situations, it is still easy to handle due to the characteristics of cone Nat, because for Cone Nat, it will bind a pair of [private IP Address: port] and [Public IP: Port] ing, so the [Public IP: Port] They use is consistent with the [Public IP: Port] registered on the server, therefore, it is okay to punch holes.

To sum up, we have completely summarized the possible communication between all types of NAT and provided feasible solutions.

V. Summary of the previous stage

1. the method used in the previous stage is flawed. It only appliesFull cone NatClient (client). The following arguments do not applyBoth are the cone Nat type.In

B: Fc + RC

C: Fc + PC

D: PC + RC

E: PC + PC

F: RC + RC

These five situations.

For restricted Nat, it registers the [IP address & Port] of the outgoing packet. It only accepts the packets sent from these registered addresses, therefore, they report that the server port can only accept packets from the server. cannot accept packages from another client. therefore, the method of punching in the previous stage is not feasible.

Vi. Existing Problems

According to theory. nat will disable a UDP ing after a certain period of time. To maintain continuous communication with the server, the server must send a UDP heartbeat packet to ensure that the ing is not disabled. this requires a suitable time value.