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

Chinaunix

標(biāo)題: NAT不支持環(huán)回(Loopback)時(shí),如何進(jìn)行P2P穿透? [打印本頁(yè)]

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

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

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

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

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

NAT_loopback.JPG

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

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

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

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

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

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


因?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過(guò)程,就應(yīng)該可以發(fā)送數(shù)據(jù)了。
作者: 醉臥水云間    時(shí)間: 2007-01-06 12:49
就當(dāng)前這種網(wǎng)絡(luò)結(jié)構(gòu)下,A有沒有什么方法可以知道B在NAT B上對(duì)應(yīng)的Port4,如果可以知道的話,把上面過(guò)程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    時(shí)間: 2007-01-06 13:32
但如果NAT C不支持環(huán)回(Loopback)的話,上面的過(guò)程肯定不能成功。

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

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


S只知道A/B在nat c上的外部地址和端口,由于nat c 不是loopback的,所以在nat c上 A/B不能互相通訊。你先去看看loopback的定義把。
作者: platinum    時(shí)間: 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的定義把。

找到一份資料,不過(guò)好像和樓主說(shuō)的 loopback 不是一個(gè)概念啊
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 編輯 ]
作者: 小丌    時(shí)間: 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