P2P Nat penetration technology

A few days ago, I was working on a file point-to-point transmission project involving Nat penetration. I have been debugging and testing since last week. Finally, it seems that I have been defeated!

The following two articles are my technical bases.Article:

Http://blog.csdn.net/ssihc0/archive/2008/10/10/3053395.aspx
Http://hi.baidu.com/wangzhe1945/blog/item/3e72fffe47fc2f365d60080c.html
Http://hi.baidu.com/wangzhe1945/blog/item/5ccd3fa4e3ee67f09152ee38.html

The general technical principles are summarized as follows:
First, we should establish connections between AB and server s respectively, and s records the actual Internet terminals of AB. Then s sends the actual terminal of the Peer to AB respectively. Then, AB asynchronously calls the connect function from the port used by a and B to S to connect to the other terminal (that is, the terminal notified by S). At the same time, both parties are listening for incoming connections on the same local port (you can also listen for connections first, and connect is better ). Since both parties send a CONNECT request to the other party (assuming that their respective Syn packets have passed through their own Nat), when the other party's CONNECT request reaches the local listening port, the router will think that this request is part of the Connect session just now and is licensed, and the local listening port will respond with a SYN-ACK and agree to the connection. In this way, the point-to-point connection through NAT through TCP is successful.

Self-writtenCodePenetration failed. Download someone else P2P TCP penetration code http://download.csdn.net/source/700961, found that if the two machines in the same LAN (the same intranet) is able to transfer files, but different Land Rover (different intranet, penetration failed.

I am not a master, and P2P TCP penetration is defeated.

Unless it is a specific environment, TCP holes are a bit "luck. because we need to constantly try some possible ports to connect to the server. UDP holes can be successful, because UDP does not need to "Connect", only messages can be transmitted, but TCP is different, and three handshakes are required. YourProgramYou can know what the TCP port is bound to the local machine, but after the route is passed, the server does not know which port is used for the route ing. if the UPnP function is enabled for a route, you can perform UPnP ing. However, in some second-level switch networks, this method is equally ineffective. I have seen some TCP holes in software such as music box. Others use UPnP ing. If the UPnP function is not enabled for a route, it can only use UDP holes.

You can consider the following:

If Nat is full cone Nat, the pair (local IP + port + NAT outside IP + port) corresponding to session1 will not change in the following Session2.
To try.
It may succeed.

Local Machine:
(192.168.1.101: 8000) connect to server (10.56.1.182: 80) with NAT (10.56.1.183: 1001) ====> pair (192.168.1.101: 8000 <=> 10.56.1.183: 1001)
192.168.1.101: 8000 release connect but listen at it (reuse ADDR)

Local Machine B:
(192.168.0.101: 8000) connect to server (10.56.1.182: 80) with NAT (10.56.2.13: 1001) ====> pair (192.168.0.101: 8000 <=> 10.56.2.13: 1001)
192.168.0.101: 8000 release connect but listen at it (reuse ADDR)

Server (10.56.1.182: 80)
Server tell machine A (192.168.1.101: 8000 <=> 10.56.1.183: 100) to connect to local machine B (pair (192.168.0.101: 8000 <=> 10.56.2.13: 1001 ))
Server tell machine B (pair (192.168.0.101: 8000 <=> 10.56.2.13: 1001) to connect to local machine A (192.168.1.101: 8000 <=> 10.56.1.183: 100)

Because B (pair (192.168.0.101: 8000 <=> 10.56.2.13: 1001 ))
A (192.168.1.101: 8000 <=> 10.56.1.183: 100)
So Intranet A or B can receive the request to establish a connection.

The above only makes sense for full cone Nat.

TCP traversal Nat is technically possible. The key is to build a correct TCP three-way handshake process, here we need to connect both a, B, must meet the three-way handshake of the correct conditions, and Syn packet, SYN-ACK packet, each serial number and response number in the middle of the ACK package must be correct. During this process, it cannot be reset by the RST package. You can refer to the classic online article natblaster.pdf. Clearly stated.

I have studied it for a while, but I have not finished it yet. Later I read the materials for a while, and I was inspired, but I didn't do it. Now I want to talk about my general ideas, you can try it, but it may not succeed!
First, the connection between a, B, and S is successful. We first determine that the handshake between A, B, and S is correct, no matter how many routers have passed through, the content in the TCP package is fixed.
Second, if we intercept the packet s sends to a at this time, that is to say, if S does not send data like, then, B changes the IP address and port in the packet sent by TCP to the IP address and port of the packet sent by S to A. At this time, a thinks that s has sent data to him, if a TCP packet is returned to S, s receives the packet and determines the serial number of the TCP packet. However, S can indeed receive the packet and finally discard it!
Third, suppose that I only assume that there is no real code implementation or testing. Suppose s does not send any data like A and B at this time, but the IP address of the other party has already been, the port number and TCP serial number are all sent to A and B. Then, a modifies the IP address, port number, and TCP serial number, at the same time, B also changed the IP address and port number in the link of the same s to the IP address and port number of A at the same time. In this way, the B server can cheat itself and receive the data sent by! For machine B, this link cannot be newly created, because the newly created link needs to be re-shaken. What may be really difficult is how machine B changes the IP address and port in the connection with S to the IP address and port in the host and S-link packets.
In fact, the overall idea is to maintain the link between A and B and S to ensure that the link will not be broken, resulting in a new handshake. Then, it is to cheat the other machine and deceive itself, let the two machines think they are talking to S. In fact, the data is transmitted in a and B.