NAT_loopback.JPG (12.04 KB, 下載次數(shù): 41)
原帖由 platinum 于 2007-1-5 16:24 發(fā)表
什么叫“環(huán)回”?不是 loopback 吧?
原帖由 Jobs.AE@ 于 2007-1-5 17:52 發(fā)表
這樣的問(wèn)題最好你先寫寫整個(gè)通信建立過(guò)程,拋個(gè)磚出來(lái),肯定有玉給你,呵呵~~~
原帖由 dayan_he 于 2007-1-5 17:53 發(fā)表
兩個(gè)客戶端都在NAT C的后面? ?? 老實(shí)說(shuō)看不懂你說(shuō)。。 既然都在C后面,要搞什么穿透
2、A往NAT C的Port2(即B對(duì)應(yīng)的地址)發(fā)送信息。
但如果NAT C不支持環(huán)回(Loopback)的話,上面的過(guò)程肯定不能成功。
原帖由 platinum 于 2007-1-6 00:12 發(fā)表
這個(gè)我沒有明白,與 loopback 有什么關(guān)系呢?
我只知道圓錐 NAT 和對(duì)稱 NAT,有一種無(wú)法 UDP 穿透,netfilter 的 NAT 屬于無(wú)法穿透的,你說(shuō)的 loopback 沒有聽說(shuō)過(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)回,也可以通信了。
但如果NAT C不支持環(huán)回(Loopback)的話,上面的過(guò)程肯定不能成功。
原帖由 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 ...
原帖由 ttvast 于 2007-1-6 15:48 發(fā)表
S只知道A/B在nat c上的外部地址和端口,由于nat c 不是loopback的,所以在nat c上 A/B不能互相通訊。你先去看看loopback的定義把。
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 |