亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

Chinaunix

標題: NAT不支持環(huán)回(Loopback)時,如何進行P2P穿透? [打印本頁]

作者: 小丌    時間: 2007-01-04 10:48
標題: NAT不支持環(huán)回(Loopback)時,如何進行P2P穿透?
網(wǎng)絡(luò)結(jié)構(gòu)如附件所示,首先如果S在NAT C的位置的話,可以穿透,但現(xiàn)在兩個客戶端都在NAT C的后面(并且NAT C不支持環(huán)回(Loopback))的情況下,有沒有辦法進行穿透,望各位大蛺指點一下,謝謝了先。

通信建立的過程:
Client A打算和Client B通訊,但苦于A和B都不知道對方的地址,所以A和B就都先登錄到服務(wù)器S上,這樣A就可以從服務(wù)器上獲得B對應(yīng)到NAT C上的Port2,現(xiàn)在A要發(fā)送信息給B的話,就做如下過程:
1、A發(fā)送信息給S,告訴S發(fā)信息給B讓B給NAT C的Port1(即A對應(yīng)的地址)地址發(fā)送一個信息,這個過程是必要的,因為A直接發(fā)送信息到NAT C的Port2上的話會被丟棄;
2、A往NAT C的Port2(即B對應(yīng)的地址)發(fā)送信息。
但如果NAT C不支持環(huán)回(Loopback)的話,上面的過程肯定不能成功。

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

[ 本帖最后由 小丌 于 2007-1-5 21:50 編輯 ]

NAT_loopback.JPG (12.04 KB, 下載次數(shù): 75)

網(wǎng)絡(luò)結(jié)構(gòu)

網(wǎng)絡(luò)結(jié)構(gòu)

作者: sharkconi    時間: 2007-01-05 16:07
哪位高手指點下,小弟也迷茫中
作者: platinum    時間: 2007-01-05 16:24
什么叫“環(huán)回”?不是 loopback 吧?
作者: 小丌    時間: 2007-01-05 17:48
原帖由 platinum 于 2007-1-5 16:24 發(fā)表
什么叫“環(huán)回”?不是 loopback 吧?

是loopback
作者: Jobs.AE@    時間: 2007-01-05 17:52
這樣的問題最好你先寫寫整個通信建立過程,拋個磚出來,肯定有玉給你,呵呵~~~
作者: dayan_he    時間: 2007-01-05 17:53
兩個客戶端都在NAT C的后面? ?? 老實說看不懂你說!! 既然都在C后面,要搞什么穿透
作者: 小丌    時間: 2007-01-05 21:51
原帖由 Jobs.AE@ 于 2007-1-5 17:52 發(fā)表
這樣的問題最好你先寫寫整個通信建立過程,拋個磚出來,肯定有玉給你,呵呵~~~

謝謝提醒,帖子編輯過了。
作者: 小丌    時間: 2007-01-05 21:53
原帖由 dayan_he 于 2007-1-5 17:53 發(fā)表
兩個客戶端都在NAT C的后面? ?? 老實說看不懂你說。! 既然都在C后面,要搞什么穿透

非常感謝你的回復(fù)。
Client A和Client B都不知道對方的地址,沒法通信!
作者: platinum    時間: 2007-01-06 00:12
2、A往NAT C的Port2(即B對應(yīng)的地址)發(fā)送信息。
但如果NAT C不支持環(huán)回(Loopback)的話,上面的過程肯定不能成功。

這個我沒有明白,與 loopback 有什么關(guān)系呢?
我只知道圓錐 NAT 和對稱 NAT,有一種無法 UDP 穿透,netfilter 的 NAT 屬于無法穿透的,你說的 loopback 沒有聽說過
作者: yd0412    時間: 2007-01-06 08:56
linux的nat模塊接近對稱性nat,并不支持loopback,對于nat穿透也有很大阻礙!
你可以試著將你的nat改成cone nat,或者添加alg試試!如果將nat改成full cone nat的話,
支持不支持loopback都應(yīng)該可以解決了!
理解的可能不太準確,希望各位指點!
作者: 小丌    時間: 2007-01-06 09:45
原帖由 platinum 于 2007-1-6 00:12 發(fā)表

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


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

但如果能夠A能夠知道NAT B的Port4的地址,那A直接發(fā)送到NAT B上,就不需要上面的loopback過程,就應(yīng)該可以發(fā)送數(shù)據(jù)了。
作者: 醉臥水云間    時間: 2007-01-06 12:49
就當前這種網(wǎng)絡(luò)結(jié)構(gòu)下,A有沒有什么方法可以知道B在NAT B上對應(yīng)的Port4,如果可以知道的話,把上面過程1、2中的Port1和Port2對應(yīng)的改為Port3和Port4,那么,NAT C即使不支持環(huán)回,也可以通信了。


A怎么可能知道PORT4呢?不可能的!S都不知道,只有上曾路由知道,但不向外提供信息。多層NAT下,需要上面N-1層NAT都支持環(huán)回,內(nèi)部才可以通信。你可以死心了。
作者: platinum    時間: 2007-01-06 13:32
但如果NAT C不支持環(huán)回(Loopback)的話,上面的過程肯定不能成功。

整個過程與 NAT C 的 loopback 有什么關(guān)系?
通過 S 知道了 A/B 相互的地址和端口,A/B 互相發(fā) UDP 包就可以穿透了,和 loopback 有何聯(lián)系?
建議 google 一下,找些資料好好看看,你的想法有問題啊
key word: udp穿越
作者: ttvast    時間: 2007-01-06 15:48
原帖由 platinum 于 2007-1-6 13:32 發(fā)表

整個過程與 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    時間: 2007-01-06 16:56
原帖由 ttvast 于 2007-1-6 15:48 發(fā)表


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

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

  1.    Loopback translation
  2.       When a host in the private domain of a NAT device attempts to
  3.       connect with another host behind the same NAT device using
  4.       the public address of the host, the NAT device performs the
  5.       equivalent of a "Twice-nat" translation on the packet as
  6.       follows. The originating host's private endpoint is translated
  7.       into its assigned public endpoint, and the target host's public
  8.       endpoint is translated into its private endpoint, before
  9.       the packet is forwarded to the target host. We refer the above
  10.       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 編輯 ]
作者: 小丌    時間: 2007-01-07 14:31
非常感謝各位的回復(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.





歡迎光臨 Chinaunix (http://72891.cn/) Powered by Discuz! X3.2