局域网内部的很多机器可以通过同一个网关与internet上的其它机器联系，局域网内部的机器很有可能没有能在广域网上使用的真实的IP，但是在通过网关的时候，网关会分配给它们不同的端口加以区别，并且作为一个数据代理，使得它们可以和外网正确地通讯。
例如局域网机器A,B通过网关C访问internet网，c的地址记为c.c.c.c, 10001和10002是c给A,B上某程序分别分配的端口，这种情况下外网的机器D与c.c.c.c：10001通讯的时候就约等于和A机器通讯，因为网关c会在A和D之间转发所有的数据包。现在我要问的问题是：B机器能否通过访问c.c.c.c:10001来访问A呢？
确切地说，就是在B机器上运行sendto函数，目标地址设置成c.c.c.c:10001，A机器能否接受到该数据包？
请您留意：我们当然知道A和B可以通过对方的局域网IP和端口来互相访问，但是在系统程序处于某些特殊情况下，如果能够允许A和B通过对方在网关c上面的映射IP和端口来互相访问，将很大减少开发的复杂度。
我做了实际情况下的少量测试，好像结果显示这样的互相访问方式是行不通的。但是由于以上提到的原因，我非常想谋求这样的解决方案。
我想问的是：A和B通过对方在网关c上面的映射IP和端口来互相访问，是因为技术底层的本质原因根本无法实现呢，
还是在我做的实验的时候，由于一些网络配置的原因暂时无法实现？
问题2：如果是技术的本质原因使得无法实现A和B通过对方在网关c上面的映射IP和端口来互相访问，那么离这
个理想的解决方案最近的一个改良方案会是什么？相对于我们不能不让A和B知道对方的局域网IP的一类解决方案而言。
例如局域网机器A,B通过网关C访问internet网，c的地址记为c.c.c.c, 10001和10002是c给A,B上某程序分别分配的端口，这种情况下外网的机器D与c.c.c.c：10001通讯的时候就约等于和A机器通讯，因为网关c会在A和D之间转发所有的数据包。现在我要问的问题是：B机器能否通过访问c.c.c.c:10001来访问A呢？
确切地说，就是在B机器上运行sendto函数，目标地址设置成c.c.c.c:10001，A机器能否接受到该数据包？
请您留意：我们当然知道A和B可以通过对方的局域网IP和端口来互相访问，但是在系统程序处于某些特殊情况下，如果能够允许A和B通过对方在网关c上面的映射IP和端口来互相访问，将很大减少开发的复杂度。
我做了实际情况下的少量测试，好像结果显示这样的互相访问方式是行不通的。但是由于以上提到的原因，我非常想谋求这样的解决方案。
我想问的是：A和B通过对方在网关c上面的映射IP和端口来互相访问，是因为技术底层的本质原因根本无法实现呢，
还是在我做的实验的时候，由于一些网络配置的原因暂时无法实现？
问题2：如果是技术的本质原因使得无法实现A和B通过对方在网关c上面的映射IP和端口来互相访问，那么离这
个理想的解决方案最近的一个改良方案会是什么？相对于我们不能不让A和B知道对方的局域网IP的一类解决方案而言。
关键在于网关的 NAT 的实现上。不幸的是绝大多数的 NAT（硬件例如Router，或软件） 都不允许这样做的。
可以参考出自此处 http://www.pdos.lcs.mit.edu/~baford/nat/draft-ford-natp2p-00.txt 的一段话, 这篇文章看看对于你的问题是非常有帮助的.
2.3.2. Clients Behind 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. Server S
18.181.0.31:1234
|
|
NAT
A-S 155.99.25.11:62000
B-S 155.99.25.11:62001
|
+----------------------+----------------------+
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234 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. 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 supported by the NAT, this translation and forwarding
step is obviously unnecessary in this situation, and is likely to add
latency to the dialog between A and B as well as burdening the NAT.
问题2：如果是技术的本质原因使得无法实现A和B通过对方在网关c上面的映射IP和端口来互相访问，那么离这个理想的解决方案最近的一个改良方案会是什么？相对于我们不能不让A和B知道对方的局域网IP的一类解决方案而言。-------〉〉〉以下为回答〈〈〈---------------------------------------------------
这个问题在 http://www.pdos.lcs.mit.edu/~baford/nat/draft-ford-natp2p-00.txt 也有回答.
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