Principles and implementation of P2P udp nat penetration

From the DELPHI box http://www.2ccc.com/article.asp? Articleid = 2048 Principles and implementation of P2P udp nat penetration 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 describe UDP The principle of NAT traversal. First, we will introduce some basic concepts: Network Address Translation (NAT) Address reuse. NAT is divided into two categories: Basic NAT and NAPT (Network Address/Port Translator ). NAT is a functional module running on a vro. The first thing we put forward 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. Proposed In The Middle Of 1990s ). 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 The only 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 this NAT device, but also change the TCP/UDP Port. 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 one of the computers. The Internet IP address of the Gateway (a nat device) of this network is 155.99.25.11 (there should be another Intranet For example, 10.0.0.10 ). If A process in Client A (this process creates a udp Socket, this Socket is bound to port 1234) wants to access the Internet host Port 1235 of 18.181.0.31, what will happen when a 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 with a SYN Packet and end with a FIN packet. But UDP, starting with the first UDP of the port of this IP address, is over. Haha, it may be a few minutes, It may be a few hours, depending on the specific implementation) and allocate a port to the Session, such as 62000, and then change the source port of the packet to 62000. So it was (10.0.0.1: 1234-> 18.181.0.31: 1235 ). 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 Dynamic forwarding to 10.0.0.1. (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 .) 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 happens 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 ). The other is NAT. Create a Session again, but do not assign 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, the vast majority of NAT In 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" in the NAT on the Intranet (that is, as we mentioned earlier To create a Session on the NAT. And this hole has a direction, for example, from an internal host (for example: 192.168.0.10) sends a UDP packet to an external IP address (for example, 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 known as UDP Hole Punching Technology) later than 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 Holes ). 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. No one can send connection requests and no one knows who's 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. Then, the address of Client A received by Server S is 202.187.45.3: 60000, This is the Internet address of Client. Similarly, if Client B logs on to Server S and nat B assigns port 40000 to this Session, 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 it can obtain B's Public Network Address 187.34.1.56: 40000, is it possible for Client A to send information to Client B? The answer is no, because if the message is sent in this way, nat B will This information is discarded (because this information is not recommended. For security purposes, most NAT will perform the discard action ). What we need now is to set a direction for NAT B 202.187.45.3 (the Internet address of Client A), Client B can receive the information sent from Client A to 187.34.1.56: 40000. Who will issue this punching command? Well, of course it's Server S. To sum up this process: If Client A wants to send information to Client B, Client A sends the command to Server S and requests Client B to Client Open a hole. Haha, isn't it a great detour, but it doesn't matter. It's very clear to think about it, not to mention 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 A pair of Ric NAT, when Client B has re-allocated the port to Client A, Client B will not Method to know this port (if the port of the NAT gateway is allocated sequentially, we may be able to guess this port number, but because there are too many factors that may cause failure, we will not push 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 (Note: If the two clients run in one NAT, the program may not run normally, depending on whether your NAT supports loopback translation. For details, see Bytes Code is only used to verify the principle, and does not deal with these problems), after the computer to log on, you can obtain the user name to log on to the computer, and then the computer to log on to through the send username Message format. If the message is sent successfully, it indicates that you have successfully connected directly to the other party.