NAT不支持環(huán)回（Loopback）時(shí)，如何進(jìn)行P2P穿透？

小丌

原帖由 platinum 于 2007-1-6 00:12 發(fā)表

這個(gè)我沒有明白，與 loopback 有什么關(guān)系呢？
我只知道圓錐 NAT 和對(duì)稱 NAT，有一種無法 UDP 穿透，netfilter 的 NAT 屬于無法穿透的，你說的 loopback 沒有聽說過

因?yàn)锳發(fā)往NAT C的Port2的數(shù)據(jù)到了NAT C那個(gè)設(shè)備實(shí)際上是NAT C的Port1發(fā)送給NAT C的Port2，例如172.19.20.32:8081----->172.19.20.32:9091，目標(biāo)地址是自己，即Loopback了，如果系統(tǒng)不支持Loopback的話，應(yīng)該就發(fā)送不民數(shù)據(jù)了。

但如果能夠A能夠知道NAT B的Port4的地址，那A直接發(fā)送到NAT B上，就不需要上面的loopback過程，就應(yīng)該可以發(fā)送數(shù)據(jù)了。

醉臥水云間

就當(dāng)前這種網(wǎng)絡(luò)結(jié)構(gòu)下，A有沒有什么方法可以知道B在NAT B上對(duì)應(yīng)的Port4，如果可以知道的話，把上面過程1、2中的Port1和Port2對(duì)應(yīng)的改為Port3和Port4，那么，NAT C即使不支持環(huán)回，也可以通信了。

A怎么可能知道PORT4呢？不可能的！S都不知道，只有上曾路由知道，但不向外提供信息。多層NAT下，需要上面N-1層NAT都支持環(huán)回，內(nèi)部才可以通信。你可以死心了。

platinum

但如果NAT C不支持環(huán)回（Loopback）的話，上面的過程肯定不能成功。

整個(gè)過程與 NAT C 的 loopback 有什么關(guān)系��？
通過 S 知道了 A/B 相互的地址和端口，A/B 互相發(fā) UDP 包就可以穿透了，和 loopback 有何聯(lián)系？
建議 google 一下，找些資料好好看看，你的想法有問題啊
key word: udp穿越

ttvast

原帖由 platinum 于 2007-1-6 13:32 發(fā)表

整個(gè)過程與 NAT C 的 loopback 有什么關(guān)系��？
通過 S 知道了 A/B 相互的地址和端口，A/B 互相發(fā) UDP 包就可以穿透了，和 loopback 有何聯(lián)系？
建議 google 一下，找些資料好好看看，你的想法有問題啊
key w ...

S只知道A/B在nat c上的外部地址和端口，由于nat c 不是loopback的，所以在nat c上 A/B不能互相通訊。你先去看看loopback的定義把。

platinum

原帖由 ttvast 于 2007-1-6 15:48 發(fā)表


S只知道A/B在nat c上的外部地址和端口，由于nat c 不是loopback的，所以在nat c上 A/B不能互相通訊。你先去看看loopback的定義把。

找到一份資料，不過好像和樓主說的 loopback 不是一個(gè)概念啊
http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt

1. 
   
2.    Loopback translation
   
3.       When a host in the private domain of a NAT device attempts to
   
4.       connect with another host behind the same NAT device using
   
5.       the public address of the host, the NAT device performs the
   
6.       equivalent of a "Twice-nat" translation on the packet as
   
7.       follows. The originating host's private endpoint is translated
   
8.       into its assigned public endpoint, and the target host's public
   
9.       endpoint is translated into its private endpoint, before
   
10.       the packet is forwarded to the target host. We refer the above
    
11.       translation performed by a NAT device as "Loopback translation".

復(fù)制代碼

中文版地址
http://www.acejoy.com/Html/Article/p2p/8120061202233117.html

[ 本帖最后由 platinum 于 2007-1-6 17:04 編輯 ]

小丌

非常感謝各位的回復(fù)，要穿越這種結(jié)構(gòu)只能依賴于NAT C的環(huán)回通信。

網(wǎng)址http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt

Peers separated by multiple NATs

   In some topologies involving multiple NAT devices, it is not
   possible for two clients to establish an "optimal" P2P route between
   them without specific knowledge of the topology.  Consider for
   example the following situation.


                                Server S
                            18.181.0.31:1234
                                   |
                                   |
                                 NAT X
                         A-S 155.99.25.11:62000
                         B-S 155.99.25.11:62001
                                   |
                                   |
            +----------------------+----------------------+
            |                                             |
          NAT A                                         NAT B
    192.168.1.1:30000                             192.168.1.2:31000
            |                                             |
            |                                             |
         Client A                                      Client B
      10.0.0.1:1234                                 10.1.1.3:1234

   Suppose NAT X is a large industrial NAT deployed by an internet
   service provider (ISP) to multiplex many customers onto a few public
   IP addresses, and NATs A and B are small consumer NAT gateways
   deployed independently by two of the ISP's customers to multiplex
   their private home networks onto their respective ISP-provided IP
   addresses.  Only server S and NAT X have globally routable IP
   addresses; the "public" IP addresses used by NAT A and NAT B are
   actually private to the ISP's addressing realm, while client A's and
   B's addresses in turn are private to the addressing realms of NAT A
   and B, respectively.  Each client initiates an outgoing connection to
   server S as before, causing NATs A and B each to create a single
   public/private translation, and causing NAT X to establish a
   public/private translation for each session.

   Now suppose clients A and B attempt to establish a direct peer-to-
   peer UDP connection.  The optimal method would be for client A to
   send messages to client B's public address at NAT B,
   192.168.1.2:31000 in the ISP's addressing realm, and for client B to
   send messages to A's public address at NAT B, namely
   192.168.1.1:30000.  Unfortunately, A and B have no way to learn these
   addresses, because server S only sees the "global" public addresses
   of the clients, 155.99.25.11:62000 and 155.99.25.11:62001.  Even if A
   and B had some way to learn these addresses, there is still no
   guarantee that they would be usable because the address assignments
   in the ISP's private addressing realm might conflict with unrelated
   address assignments in the clients' private realms.  The clients
   therefore have no choice but to use their global public addresses as
   seen by S for their P2P communication, and rely on NAT X to provide
   loopback translation.