[P2P] The Principle and Implementation of UDP penetration through NAT using the Hole Technique (with source code conversion)

First, we will introduce some basic concepts:
NAT (Network Address
Network Address Translation: 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 ). In fact, only a few nodes in this subnet need a unique IP address in the world. The IP addresses of other nodes should be reusable.
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, the basic 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 much about basic NAT devices (Haha, I have never seen it). 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 a computer, and 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 the client
A process in a (this process creates a UDP
Socket, this socket is bound to port 1234) to access port 1235 of the Internet host 18.181.0.31, what will happen when packets pass 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 the session, such as 62000, and then change the source port of the packet to 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: data sent from Port 18.181.0.31 to port 62000 will be forwarded, and data sent from other IP addresses to this port will be discarded by Nat .)
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) is sent to another server
S2 sends a UDP packet. What happens when the 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, it uses the original allocated port number 62000. The previous type of NAT is called symmetric.
Nat, the latter is called cone
Nat. We expect that our Nat is the second type. If your Nat is the first type, many P2P software may fail. (Fortunately, most of NAT now belongs 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. This hole cannot be played by the outside, it can only 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, a "hole" in the direction of 219.237.60.1 is created on the NAT device of the Intranet (this is called UDP
Hole
Punching Technology) Later, 219.237.60.1 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 owns the Internet address. 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.
The address of a is 202.187.45.3: 60000, which is the Internet address of Client. Similarly, client B logs on to server s and Nat
B allocates port 40000 to this session, 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 the client
B, then he can get B's public network address 187.34.1.56: 40000 from server s, is it client?
A can receive the message sent from client B to this address? The answer is no, because if the message is sent in this way, Nat
B will discard this information (because such information is not recommended, for security, most NAT will perform the discard action ). Now what we need is
Create a hole in the direction of 202.187.45.3 (that is, the Internet address of Client A) on B, then the client
Client B can receive the information sent from A to 187.34.1.56: 40000. 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 to request Server
S command client B to client
A. Oh, isn't it easy to get around? It's okay, just think about it. What's more, there is source code. (Mr. Hou said: there is no secret in front of the source code.
(8), 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 the process is structured Nat, when client B
Client B will not be able to know this port if the port of A has been reconfigured
The Nat ports are allocated sequentially, so we may guess the port number, but we do not recommend this method because there are too many factors that may cause failure ).

Next to another article:

The following explains what I think is missing in the above article.
Private address/port and public address/port: We know that most networks now use napt (Network Address/port translator, this interface is used to modify the IP address and port number of an external conversation after Nat, here, the customer considers the IP addresses and port numbers used in a session as private addresses/ports, and the IP addresses and port numbers modified after napt are called public addresses/ports. you can also understand that the private address/port is the nickname of your family, while the Public Address/port is the name you actually make public. it is easy to get the user's private address/port number. To get the public address/port number, it must be expressed by the IP address and port number that the machine sees after connecting to another machine.

If you understand the above, let's go to our code and explain the implementation of the key part here:

The client first obtains its own private address/terminal, and then sends a login request to the server. After receiving the request, the server can know the public address/terminal of the client, the server saves the private address/port and public address/port for each login client.

OK. The following describes the key drilling process. assume that client a wants to talk to client B, but a does not know the address of B, even if it knows the principle of NAT, the conversation will be rejected for the first time, because the NAT of client B considers this as a request from external sources that have never been received. at this time, if a finds that he has not saved the address of B, or the session request sent to B fails, it will ask the server side to ask B to open a hole to, the session meaning of B-> A is that it makes Nat B think that the address/port of A is the address/port that can be passed, in this way, when a sends a dialog to B, it will not be rejected by Nat B. for example, a wants to visit B's house but is rejected by B's manager Nat B for the following reasons: I have never heard my B mention your name. At this time, a finds a friend server that both A and B know and asks the server to send a message to B, let B tell the butler that A is my friend, so B and the butler Nat B said that A is a friend I know, in this way, a's access request will not be rejected by Butler Nat B. in short, UDP holes are a process of directly communicating with each other through the address saved by the server. The server only helps to establish connections and no longer intervene after indirect establishment.

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 run normally, depending on whether your Nat supports loopback
(For details, see logs). Then, you can obtain the username of the computer you are logged on.
Username Message format to send messages. If the message is sent successfully, you have successfully connected directly to the other party.
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)

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 -).
_ 05/04052509317298. rar"
Http://www.ppcn.net/upload/2004_05/04052509317298.rar

 

Another article about the hole-hitting Technology (Supplement)

The UDP plugging technology relies on public firewalls and cone Nat, allowing appropriate and planned end-to-end applications to penetrate through NAT, even if both hosts are behind Nat. This technology is introduced in section 5.1 [Nat Prot] of rfc3027, and informal descriptions are made in Internet [Kegel], and some latest protocols are also applied, for example, in the [Teredo, Ice] Protocol. However, we should note that, as its name is, the reliability of UDP Punching Technology depends on UDP.
Here we will consider two typical scenarios to introduce how applications on both sides of the connection communicate as planned. In the first scenario, we assume that both clients are in different NAT scenarios; in the second scenario, we assume that both clients are in the same Nat, but they do not know each other (they are in the same Nat ).

Client Communication after different NAT

Assume that both client a and client B have their own private IP addresses and are running in different NAT locations. End-to-end programs run between Client A, client B, and S, and they all open UDP port 1234. Client A and client B first establish communication sessions with S. At this time, Nat a allocates its UDP port 62000 to the sessions of Client A and S, nat B also allocates its UDP port 31000 to the sessions between client B and S.

If Client A wants to establish a direct UDP communication connection with client B at this time, if client a simply sends a UDP message to the public address 138.76.29.7: 31000 of client B, nat B will discard this information without consideration (unless Nat B is a full cone Nat), because the address information contained in this UDP information, the address of server s stored in Nat B does not match that of client B and server S. Similarly, if client B does the same thing, UDP messages sent will also be discarded by Nat.

If client a starts to send a UDP message to the public address of client B, and at the same time, he sends an invitation message to client B through S transit, request client B to send a UDP message to the public address of Client. The public IP address (138.76.29.7: 31000) of Client A to client B) as a result, Nat a opens a new communication session between the private address of Client A and the Public Address of client B, nat B also opens a new communication session between the private address of client B and the Public Address of Client A (155.99.25.11: 62000. Once the new UDP session is opened to the other party, the client a and client B can communicate directly without the need for S to bridge the line. (This is the so-called hole-hitting technology )!