Principles of P2P TCP Nat penetration (zz)

Note: paste an article about TCP Nat penetration. It seems that the technical implementation of TCP penetration Nat is more complicated than that of UDP, although the principle is similar. However, according to the data, the probability of TCP penetrating Nat is slightly lower than that of UDP. In any case, this is also one of the ways to try.

========================================================== ========================================================== ======

Principles of P2P TCP Nat penetration
Translation: Navy
Original article: http://www.andrew.cmu.edu/user/ggw/WBFD.pdf

Due to work needs, I have searched for P2P materials on the Internet for a long time. It seems that only the principles and implementations of P2P UDP Nat penetration (with Source Code) are of practical significance, it is a pity that UDP is used again, so I had to find an English document and find it useful for reference. I translated a part of the document based on my understanding and shared it with you. Due to the limited level, I am sorry for the mistake. If someone can continue to translate, don't forget to inform me Oh, wanfeng_001@126.com, thank you.

Summary
Firewalls and Network Address Translation (NAT) devices have some problems with traditional P2P protocols. Some intermediate devices suppress TCP requests from external networks to internal networks. The purpose of this article is to find a way to establish a TCP connection between hosts inside the two NAT devices. We have implemented this function under two common hardware conditions.

1. Getting Started
Due to the decrease in 32-bit IP addresses, many devices are connected to the Internet through an Internet address proxy. This is NAT technology. These devices are becoming more and more important to the Internet, but their independent development causes harm to the current Internet Protocol due to the lack of standards.

2. Technology
A typical Nat and firewall device does not allow external addresses to actively request requests to access the internal network. If your program needs to establish a direct connection between the two internal networks, therefore, the two internal devices must be mutually trusted. If both Part A and Part B initialize the TCP connection, the NAT device will think that they are mutually trusted and allow the connection between them.
Figure 1 is an example. The goal is to establish a TCP connection between A and B (after Nata and natb respectively.
We have discussed a variety of TCP connection solutions in a specific NAT device environment.
If our situation is as follows:
1. Predictable na port, predictable Nb port, and specific route of the source IP address
2. Predictable na port, predictable Nb port, cannot specify a specific route of the source IP address
3. Random na port. The Nb port can be predicted. You can specify a specific route for the source IP address.
4. Random na port: The Nb port can be predicted. A specific route from the source IP address cannot be specified.
5. Random na port and random Nb port. You can specify a specific route for the source IP address.
6. Random na port and random Nb port cannot be specified for a specific route of the source IP address

We must make these four assumptions:
1. Both hosts are not restricted by NAT devices;
2. We can configure a network device so that the host cannot see the ICMP packet from the external network (TTL exceeds the limit), because the ICMP packets are interrupted by any party regardless of the received packet. Some solutions we discussed rely on sending a SYN packet with a small initial TTL to establish a TCP connection. Once the SYN packet is discarded by the router, the icmp ttl timeout packet will be transmitted to the NAT device. We do not allow the NAT device to transmit the response packet for the timeout TTL to the internal network, even if Nat delivers the packet to the internal server, you must configure a firewall to restrict the packet from reaching the host;
3. Even if the NAT device sees an ICMP timeout packet, the ing table of the device will not be changed;
4. Other hosts in the internal network will not occupy this port because the port may be invalid if the network is busy.

3.1 first case
We can solve the problem through the sequence shown in Figure 2:
1) A and B can set LSR (an option in the IP header) to send Syn packets through the X route.
2) X can cache their data packets and send spoofed SYN + acks to NA and Nb.
3) A and B can respond to data sent by X.
4) x discards the two ACK packets because it can determine that A and B have responded to each other successfully.

 
 
 
Figure 2 assumes that a and B communicate with each other through the NAT port. A knows that the communication port of B is NB: 5000, and B knows that A is Na: 4000, and requires that X is not behind any NAT device. in reality, the two ports are predicted. The prediction process is 3:
 
 
3.2 case 2
In the first case, the routing is dependent on and freely set. However, many routers limit this and discard such service request packets. Therefore, in practical application, this solution is likely to fail. If the route cannot be set freely, we can use the out-of-band channel (which is a TCP connection established with X in advance) to transmit packets that must be routed to X before they can be seen. Note that step 2 x in Figure 2 already knows the TCP serial numbers Q and P, because X has received these two Syn packets, but it is impossible to receive them if the packets do not pass through X. To initialize this connection, the two hosts send the initial Syn packet, and they both know that it is impossible to reach the target, but they can all remember their own SYN number (in my opinion, obtain the SYN Packet sent by using the hook) and send it to x. x gets their SYN packet, and then it can fool them to send the ACK packet. There are two ways to send data packets that cannot reach the target. The simple method is that each host sends a SYN to the other party and requests that the response packet will not reach the internal network. if NAT (firewall) returns the response packet to the internal network, it usually sends a TCP reset packet (RST). If Nat generates an RST packet, A and B cannot simply send a SYN to each other in Figure 2, because if so, Na and Nb cannot be punched in. If Nat does not send an RST packet, the TCP connection will not be interrupted. Another method for sending Syn packets that cannot reach the target network is to reduce the TTL value so that they cannot reach each other. If the user cannot configure the firewall to discard the ICMP response packet, or the NAT does not continue to send the ICMP packet, the TCP will not be closed immediately. This solution cannot use a simple spoofing method, because we must ensure that the SYN Packet sender of the source address does not receive the icmp rst packet; otherwise, the intermediate device will establish an incorrect route. based on the SYN packet, Nat can establish a route from Internet IP address and port to external IP address and port. because the spoofed Syn packet is a wrong source IP address (not the sender X), this route will not be sent to X but to NA or Nb. In addition, you need to set TTL to small enough for this solution, so that the NAT of the other party will not receive the initial SYN Packet sent by the other party, otherwise the hole cannot be completed. (Figure 4)
 
 
 

3.3 case 3
This is easier than the first two, but X cannot predict the NA or Nb port. B will first send a SYN packet to X so that X knows the port number it chooses, and then x sends this information to a, and a can send SYN to the identified address and port, figure 5 shows the first case of Deformation ::
1) x predicts the port as shown in figure 3, but it cannot predict the next port number of Na. However, it can predict that the next port number of Nb is 5000, you can also notify the node A and Node B that A has established a connection;
2) synchronization nodes A and B X;
3) X can fool A and B;
4) A and B send ACK to each other;
5) x discards the ACK sent to it because it can confirm that they have established a connection.