Peer-to-Peer (P2P) Communication Across Middleboxes (Translation 3)

xiaoxiao2021-03-06  54

Original copyright: CopyRight (c) The Internet Society (2003) .all Rights Reserved.

Original address: http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt

The translation copyright has declaration: Please refer to the author or website of this article indicate: http://blog.9cbs.net/hxhbluestar to respect the translator's labor results!

3.3.2. Peers Behind The Same Nat client is in the same NAT

Now consider the scenario in which the two clients (probably unknowingly) happen to reside behind the same NAT, and are therefore located in the same private IP address space. Client A has established a UDP session with server S, to which the common NAT has Assigned public port number 62000. Client B Has Similarly Established a session with s, to which the Nat Has Assigned Public Port Number 62001.

Now let's consider two clients (it is very likely that it will be unknowingly), after the same NAT, and is in the same subnet, the session between Client A and S uses NAT. 62000 port, the session between Client B and S uses 62001 port, as shown below:

Suppose that A and B use the UDP hole punching technique as outlined above to establish a communication channel using server S as an introducer. Then A and B will learn each other's public IP addresses and port numbers as observed by server S, and start sending each other messages at those public addresses.The two clients will be able to communicate with each other this way as long as the NAT allows hosts on the internal network to open translated UDP sessions with other internal hosts and not just with external hosts. We refer to this situation as "loopback translation," because packets arriving at the NAT from the private network are translated and then "looped back" to the private network rather than being passed through to the public network. For example, when A sends a UDP packet to B's Public Address, The Packet Initially Has A Source IP Address and Port Number of 10.0.0.1:124 And A Destination of 155.99.25.11:62001. The Nat Receives this Packet, Translates It To Have A Source of 155.99.25.11:62000 (A's public address) and a destination of 10.1.1.3:1234, and then forwards it on to B. Even if loopback translation is supported by the NAT, this translation and forwarding step is obviously unnecessary in this situation And is Likey to Add Latency to the Dialog Between a and b as well as budening the nat.

We assume that Client A and Client B have to use the "UDP Covered Technology" we described in the previous section, and through the "media" "of the server S, the Client A and Client B first get from the server S. The public network IP address and port, then send a message on the other party's public IP address and port. In this case, if the NAT is only allowed to open the UDP session communication channel between the internal network host and other internal network hosts (the network host after the same NAT), the internal network host is not allowed to other external network hosts. Then, Client A and Client B can be called. We call this situation "loopback translation") because the packet first sent from the private IP of the local area network to the NAT conversion, then "winding", return to the local area network, but this is more than these The data is transmitted through the public network. For example, when Client A sends a UDP packet to the public IP address of Client B, there will be a source address 10.0.0.1:124 and a target address 155.99.25.11:62001. After NAT receives this package, it will resolve this package with a public address source address 155.99.25.11:62000 and a target address 10.1.1.3:1234, then send it to b, although NAT support "Loopback Translation", we also found that in this case, this resolution and sending process is excess, and the conversation between the Client A and Client B may potentially add a burden to NAT.

The solution to this problem is straightforward, however. When A and B initially exchange address information through server S, they should include their own IP addresses and port numbers as "observed" by themselves, as well as their addresses as observed by S.The clients then simultaneously start sending packets to each other at each of the alternative addresses they know about, and use the first address that leads to successful communication. If the two clients are behind the same NAT, then the packets directed to their private addresses are likely to arrive first, resulting in a direct communication channel not involving the NAT. If the two clients are behind different NATs, then the packets directed to their private addresses will fail to reach each other at all, but the clients will hopefully establish connectivity using their Respective Public Addresses. it is importnts That these Packets Be Authenticated In Some Way, However, Since In The Case Of Different Nats It Is Entirel Y Possible for a's Messages Directed At B's Private Address To Reach Some Other, Unrelated Node on a's Private Network, or vice versa.

转载请注明原文地址:https://www.9cbs.com/read-116999.html

New Post(0)