The principle of network punching (communication through the intranet through the peer software)

Http://www.cnblogs.com/gansc23/archive/2010/10/20/1857066.html

First introduce some basic concepts:
NAT Network Address translators: Network address translation is the result of a growing lack of IP addresses, and its primary purpose is to enable address reuse.Nat is divided into two major classes, the basic NAT and Napt (Network address/port Translator).

The first NAT is a functional module that runs on the router.

The first proposed is the basic NAT, which is based on the fact that only a small number of nodes in a private network (domain) need to be connected to an external network (hehe, which was proposed in the middle of the 90 century). Then there are only a few nodes in this subnet that require the world's only IP address, and the IP addresses of the other nodes should be reusable.

Therefore, the basic NAT implementation of the function is very simple, in the subnet using a reserved IP subnet segment, these IP is not visible to the outside. Only a few IP addresses in the subnet can correspond to truly global unique IP addresses. If these nodes require access to an external network, then basic NAT is responsible for translating the subnet IP of the node into a globally unique IP and sending it out. (Basic NAT changes the original IP address in the IP packet, but does not change the port in the IP packet). For basic NAT, refer to RFC 1631.

Another kind of NAT is called NAPT, which we can see from the name.Napt not only changes the IP address of the IP datagram that passes through this NAT device, but also changes the TCP/UDP port of the IP datagram. Basic NAT Device Maybe we don't see much (hehe, I haven't seen it), Napt is the protagonist of our real discussion. See:
Server S1
18.181.0.31:1235
|
^ Session 1 (a-s1) ^ |
| 18.181.0.31:1235 | |
V 155.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 A
10.0.0.1:1234

There is a private network 10.*.*.*,client A is one of the computers, the network gateway (a NAT device) of the external network IP is 155.99.25.11 (there should be an intranet IP address, such as 10.0.0.10). If a process in client a (this process creates a UDP socket, this socket bound 1234 port) wants to access the 1235 port of the extranet host 18.181.0.31, what happens when the packet passes through NAT?

First NAT will change the original IP address of this packet, instead 155.99.25.11. Nat then creates a session for the transfer (the session is an abstract concept, and if it is TCP, perhaps the session is started by a SYN packet and ended with a fin packet.) And UDP, with this IP port of the first UDP start, the end, hehe, maybe a few minutes, maybe a few hours, this depends on the specific implementation of the session and assign a port, such as 62000, and then change the packet source port is 62000. So it was (10.0.0.1:1234->18.181.0.31:1235) that the packet was turned into the internet (155.99.25.11:62000->18.181.0.31:1235).

Once Nat has created a session, Nat remembers that port 62000 corresponds to port 1234 of 10.0.0.1, and data sent from 18.181.0.31:1235 to Port 62000 will be automatically forwarded to 10.0.0.1:1234 by Nat. (Note: This is to say that the data sent to port 62000 will be forwarded, the other IP or other ports on the 18.181.0.31 will be discarded by Nat 18.181.0.31:1235) so that client A is associated with the server S1 was established with a connection.

Hehe, the above basic knowledge may be a lot of people know, then the following is the key part.Take a look at the following scenario:
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 A
10.0.0.1:1234

In the example above, if the original Socket of client A (the UDP socket that is bound to port 1234) then sends a UDP packet to another server S2, what happens when the UDP packet passes through NAT?
There may be two situations where NAT creates a session again and assigns a port number to the session again (for example: 62001). The other is that NAT creates a session again, but does not assign a new port number, but instead uses the originally assigned port number 62000.The former NAT is called symmetric Nat, and the latter is called Cone Nat. We expect that our NAT is the second, hehe, if your NAT happens to be the first one, then there is likely to be a lot of peer software failure. (especially if both sides are symmetric NAT, or if one side is symmetric NAT and the other is restricted Cone NAT, in which case it would be difficult to establish peer-to-peer connections.) For restricted Cone NAT, see Http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt) ( Draft-ford-midcom-p2p-01.zip)

Well, we've seen that through NAT, it's easy to connect a computer to a subnet (NAT is equivalent to transparent, and the subnets and extranet computers don't have to know the NAT). But it is difficult for an external computer to access a computer in the subnet (which is what peer-to-peer needs). So what can we do if we want to send a datagram from outside to the intranet computer?

First of all, we have to play a "hole" in the NAT on the intranet (that is, we said in a NAT on a session), this hole can not be played by the outside, can only be played by the host inside the intranet. And this hole has a direction, such as from the inside of a host (such as: 192.168.0.10:11111) to an external IP (such as: 219.237.60.1:22222) to send a UDP packet, Then in this intranet NAT device to play a direction for the 219.237.60.1:22222 "hole" (this is called the UDP Hole punching technology) after 219.237.60.1 : 11111 can be connected with the 192.168.0.10:22222 of the intranet through this hole. (but no other IP or other port on the 219.237.60.1 can take advantage of this hole).

Oh, now it's our turn to peer. With the above theory, the realization of two intranet host communication is the last step: that is the chicken eggs or eggs, the problem of raw chickens,on both sides can not initiate the connection request, no one knows whose public address, then how can we hit this hole? We need an intermediary to contact the two intranet hosts . Now let's take a look at the process of one-peer software, for example:
Server S (219.237.60.1)
|
|
+----------------------+----------------------+
| |
Nat A (External network ip:202.187.45.3) Nat B (extranet 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 of 60000 to the session, so server s receives the address of client a 202.187.45.3:60000, which is the extranet address of client A. Similarly, Client b logon server S,nat B assigns a port of 40000 to this session, then the address of B received by Server S is 187.34.1.56:40000.

At this point, both client A and client B can communicate with server S. If client a wants to send a message directly to client B at this point, then he can get B's public address 187.34.1.56:40000 from server s, is not client A to this address send information to client B can receive it? The answer is no, because if this message is sent, Nat B discards this information (because such information is unsolicited, and for security purposes, most NAT will execute the discard action). Now what we need is a hole in the direction of 202.187.45.3:60000 (that is, client A's extranet address) on Nat B, and client A sends the message to 187.34.1.56:40000, and client B will receive it. Since client A cannot notify client B to hit the hole, we can only forward the command through the server.

Summarize this process: If client A wants to send a message to client B, then client a sends a command to server s, requesting that server S command client B to hole in the direction of client A. Oh, is not very around the mouth, but it doesn't matter, think about it is very clear, not to mention the source code (Hou teacher said: No secret in front of the source code 8)), and then client a can be through the client B's external network address and Client B communication.

This is a general flow of client A and client B to build a peer connection:
(1) Client A->server s (client A sends a request to Server s requesting that the client B be punched in the direction of client a)
(2) Server s->client B (S requires B to punch a hole)
(3) client b->client A (punched in the hole message, the message that Client a will probably not receive, but it doesn't matter, NAT B's Hole has been played)
(4) Client a->client B (send true message)

Note: The above procedure is only suitable for cone NAT, and if it is symmetric NAT, client B will not know the port if the port that client B punched into client A has been reassigned (if symmetric NAT ports are assigned sequentially, so we might be able to guess the port number, but we don't recommend this method of guessing the port because there are too many factors that could lead to failure.

The following is a simulation of the process of peer chat source code, the process is very simple, p2pserver run on a computer with a public IP, p2pclient run after two different NAT (note that if two clients run on a NAT, this program will probably not run properly, Depending on whether your NAT supports loopback translation, see Http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt ( Draft-ford-midcom-p2p-01.zip), of course, this problem can be resolved by both parties to try to connect to each other's intranet IP, but this code only to verify the principle, and did not deal with these problems, after the computer can be logged on to get the user name of the computer first, The post-logon computer sends the message in the format of the Send username message. If sent successfully, you have made a successful connection directly with the other party.
The program now supports three commands: Send, Getu, exit
Send format: Send username message
Function: Send message to Username
Getu format: Getu
function: Get a list of current server users
Exit Format: Exit
Function: Log off the connection to the server (the server does not automatically monitor whether the customer is hanging wire)

Code is very short, I believe it is easy to understand, if there is any problem, you can send me an email [email protected] or CSDN on the short message. At the same time, please forward this article, but want to retain the author Copyright 8-).

Attached: nat/napt module is a record table to record our mapping after the hole, but this mapping relationship is a lifetime (unless you set a static mapping on the gateway), so it does not always exist in the record table, if we need to maintain our mapping after the hole, It may be necessary to have one end in the heartbeat package to keep the Nat/napt module in the mapping relationship after we punched the hole.


reference:http://www.k8w.net/technology/develop/200710/81.html

The principle of network punching (communication through the intranet through the peer software)