Principles and implementation of UDP Nat penetration through P2P (source code)

Http://www.cppblog.com/API/archive/2012/08/24/188130.html

Principles and implementation of P2P UDP Nat penetration (with source code)
Original: shootingstars
Reference: http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt

There are often discussions on P2P principles on the Forum, but the discussion is based on the discussion, and there are very few substantive issues (source code ). Haha, here I will use a source code implemented by myself to illustrate the principle of UDP NAT traversal.

First, we will introduce some basic concepts:
Network Address Translation (NAT): Network Address Translation is generated when IP addresses are increasingly lacking. Its main purpose is to reuse addresses. Nat is divided into two categories: Basic Nat and

Address/port translator ).
Nat is a functional module running on a vro.

The first solution is the basic Nat, which is based on the fact that only a few nodes in a private network (domain) need to be connected to the Internet, this was proposed in the 1990s S ). There are actually only a few nodes in this subnet.

A globally unique IP address is required. IP addresses of other nodes can be reused.
Therefore, the basic Nat implementation function is very simple. Using a reserved IP subnet segment in the subnet, these IP addresses are invisible to the outside. Only a few IP addresses in the subnet can correspond to a truly unique IP address in the world. If these nodes need to access the external network,

Then, Nat is responsible for converting the IP address in the subnet of the node into a globally unique IP address and then sending it out. (Basic NAT will change the original IP address in the IP packet, but will not change the port in the IP packet)
For basic Nat information, see RFC 1631.

The other Nat is called napt. We can also see from the name that napt will not only change the IP address of the IP datagram through the NAT device, but also change the TCP/UDP port of the IP datagram. We may not see many basic NAT devices.

), Napt is the main character of our discussion. See:

Server S1
18.181.0.31: 1235
|
^ Session 1 (A-S1) ^ |
| 18.181.0.31: 1235 |
V155.99.25.11: 62000 v |
|
Nat
155.99.25.11
|
^ Session 1 (A-S1) ^ |
| 18.181.0.31: 1235 |
V 10.0.0.1: 1234 v |
|
Client
10.0.0.1: 1234

There is a private network 10. *. *. * Client A is one of the computers. The Internet IP address of the Network Gateway (a NAT device) is 155.99.25.11 (there should be an intranet IP address, such as 10.0.0.10 ). If a process in Client (

This process creates a UDP socket, which is bound to port 1234) to access port 1235 of the Internet host 18.181.0.31. What will happen when the data packet passes through Nat?
First, Nat changes the original IP address of the packet to 155.99.25.11. Next, Nat creates a session for this transmission (session is an abstract concept. If it is TCP, the session may start from a SYN Packet and end with a FIN packet.

For UDP, it starts with the first UDP port of the IP address and ends. Haha, it may be a few minutes, maybe several hours, depending on the specific implementation) and assign a port for this session, such as 62000, and then change the source port of this packet

62000. Therefore, the original data packet (10.0.0.1: 1234-> 18.181.0.31: 1235) is changed to (155.99.25.11: 62000-> 18.181.0.31: 1235) on the Internet ).
Once a session is created, Nat remembers that port 62000 corresponds to port 1234 of 10.0.0.1. data sent from Port 18.181.0.31 to port 62000 will be automatically forwarded to 10.0.0.1 by Nat. (Note: The message is sent at 18.181.0.31.

Data sent to port 62000 is forwarded, and data sent from other IP addresses to this port is discarded by Nat. In this way, client a establishes a connection with server S1.

Well, most people may know the basic knowledge above, so the following is the key part.
Let's take a look at the following situation:
Server S1 server S2
18.181.0.31: 1235 138.76.29.7: 1235
|
|
+ ---------------------- +
|
^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^
| 18.181.0.31: 1235 |||138.76.29.7: 1235 |
V 155.99.25.11: 62000 v | V 155.99.25.11: 62000 v
|
Cone Nat
155.99.25.11
|
^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^
| 18.181.0.31: 1235 |||138.76.29.7: 1235 |
V 10.0.0.1: 1234 v | V 10.0.0.1: 1234 v
|
Client
10.0.0.1: 1234
In the following example, if Client A's original socket (the UDP socket bound with port 1234) then sends a UDP packet to another server S2, what will happen when this UDP packet passes through Nat?
In this case, two conditions may occur. One is that Nat creates a session again and assigns a port number (for example, 62001) to the session again ). In addition, Nat creates a session again, but does not allocate a new port number. Instead

Use the original allocated port number 62000. The previous Nat is called Nat, and the latter is called Nat. We expect that our Nat is the second type. If your Nat is the first type, many P2P software may fail. (Fortunately

Currently, most Nat instances belong to the latter, that is, cone Nat)

Now, we can see that it is easy to connect computers in the subnet to external networks through NAT (NAT is transparent, and computers in the subnet and the Internet do not need to know the NAT situation ).
However, it is difficult for external computers to access computers in the subnet (and this is exactly what P2P needs ).

So what can we do if we want to send a datagram to an intranet computer? First, we must create a "hole" (that is, we mentioned earlier to create a session on Nat) on the Intranet Nat.

It can be played by hosts in the intranet. This hole also has a direction. For example, a UDP packet is sent from an internal host (such as 192.168.0.10) to an external IP address (such as 219.237.60.1, then, the NAT device on the Intranet is directed

219.237.60.1 "hole" (this is called UDP hole Punching Technology) and later 219.237.60.1, you can use this hole to contact 192.168.0.10 on the Intranet. (However, other IP addresses cannot use this hole ).

Now it's our turn to P2P. With the above theory, the last step is to achieve communication between two Intranet hosts: the problem of chicken eggs or eggs, and the two sides cannot actively send connection requests, no one knows who's Internet address, that

How can we make this hole? We need a man in the middle to contact the two Intranet hosts.
Now let's take a look at the process of a P2P software, for example:

Server s (219.237.60.1)
|
|
+ ---------------------- +
|
Nat A (Internet IP: 202.187.45.3) Nat B (Internet IP: 187.34.1.56)
| (Intranet IP: 192.168.0.1) | (intranet IP: 192.168.0.1)
|
Client A (192.168.0.20: 4000) Client B (192.168.0.10: 40000)

First, client a logs on to the server and Nat A assigns a port 60000 for this session. Then, the address of client a received by server s is 202.187.45.3: 60000, this is the Internet address of Client. Similarly, client B logs on to the server

S. The port allocated by Nat B to this session is 40000, so the address of B received by server s is 187.34.1.56: 40000.
In this case, both client a and client B can communicate with server S. If Client A wants to directly send information to client B at this time, then he can obtain the public IP address 187.34.1.56: 40000 from server S. Is it from client?

Can client B receive the message? The answer is no, because if the message is sent in this way, Nat B will discard this information (because this information is not recommended, for security purposes, most NAT will perform the discard action ). Now what we need is

Open a hole in the direction of 202.187.45.3 (that is, the Internet address of client a). Then Client A sends the information sent to 187.34.1.56: 40000, and client B receives the information. Who will issue this logging command? Oh, of course, it's server S.

To sum up this process: If Client A wants to send information to client B, client a sends a command to server s and requests client B to open a hole in Client. Oh, isn't it easy? It's okay. Just think about it.

Chu, let alone the source code (teacher Hou said: there is no secret 8 in front of the source code), and then client a can communicate with client B through the Internet address of client B.

Note: The above process is only applicable to the case of cone Nat. If it is using NAT, when client B holes in Client A, the port has been reassigned, client B will not be able to know this port (if the port of the NAT gateway is allocated sequentially

So we may be able to guess the port number, but because there are too many factors that may cause failure, we do not recommend this method to guess the port ).

The following is the source code for simulating P2P chat. The process is very simple. p2pserver runs on a computer with a public IP address, and p2pclient runs after two different NAT addresses (note, if the two clients run in one Nat, the program may not

It can run normally, depending on whether your Nat supports loopback translation.

But this code is only used to verify the principle and does not solve these problems.) After logon, you can obtain the username of the first logon computer, after logon, the computer sends messages in the format of "Send username message. If the message is sent successfully, it indicates that you have

The connection to the other party is successful.
The program now supports three commands: Send, getu, exit

Send format: Send username message
Function: send information to Username

Getu format: getu
Function: obtains the user list of the current server.

Exit format: Exit
Function: disconnect from the server (the server does not automatically monitor whether the customer is suspended)

The code is very short, I believe it is easy to understand, if there is any problem, you can send me an email zhouhuis22@sina.com or send a short message on csdn. At the same time, you are welcome to forward this article, but you want to retain the author's copyright 8 -).

Finally, I would like to thank csdn netizens piggyxp and seilfer for their help in testing.