BT 下载疑问,公网可以向我的内网发送 UDP 包?打洞洞加持?

2019-05-08 16:48:18 +08:00
 brMu
qbittorrent 4.1.5,装在软路由上,软路由直接拔号,获取了内网 ipv4 和公网 ipv6,BT 下载时,tcpdump 发现对方是通过公网 IP 发送 UDP 包到我的 ipv4 内网地址的,一般 TCP 通过建立连接后这种现象是正常的,UDP 是无连接的,为什么他可以主动发送到我的内网 ipv4 的 BT 端口的?打洞洞?

16:41:19.728597 IP 60.109.50.*.47772 > 10.9.168.*.9982: UDP, length 1426
16:41:19.728601 IP 60.109.50.*.47772 > 10.9.168.*.9982: UDP, length 1426
16:41:19.728605 IP 60.109.50.*.47772 > 10.9.168.*.9982: UDP, length 1426
16:41:19.728609 IP 60.109.50.*.47772 > 10.9.168.*.9982: UDP, length 1426
16:41:19.728613 IP 60.109.50.*.47772 > 10.9.168.*.9982: UDP, length 1426
16:41:19.733553 IP 60.109.50.*.47772 > 10.9.168.*.9982: UDP, length 1426
16:41:19.733559 IP 60.109.50.*.47772 > 10.9.168.*.9982: UDP, length 1426
5331 次点击
所在节点    宽带症候群
15 条回复
sean10
2019-05-08 16:51:06 +08:00
对,NAT 打洞
dryadent
2019-05-08 16:55:08 +08:00
一般都是 NAT 映射出去的
ihipop
2019-05-08 17:05:44 +08:00
upnp
OneNian
2019-05-08 17:08:51 +08:00
你作为客户端先去请求资源的,并不是公网的用户直接给你发数据。

运营商的 nat 是无法穿透的,upnp 也不能传递
brMu
2019-05-08 17:10:50 +08:00
@sean10
感谢,我又搜了下,这篇文章讲的太细了,应该就是通过中间服务器来实现 UDP 打洞的。
https://blog.csdn.net/ustcgy/article/details/5655050
cwbsw
2019-05-08 17:12:59 +08:00
@OneNian
一级运营商都是锥形 NAT,后面的节点之间是可以直连的。
OneNian
2019-05-08 17:13:14 +08:00
@brMu
BT 的 tracker 不是中间服务器
catalina
2019-05-08 17:19:55 +08:00
@brMu bt 的 tracker 只是告诉你这个种子有哪些 ip 在下载、哪些 ip 在上传而已。。。否则怎么能叫 p2p ?
brMu
2019-05-08 17:37:44 +08:00
@OneNian
@catalina
我说的中间服务器不是 tracker 服务器喔,是通过一台外网的节点做为桥接,来实现 2 台内网 IP 之间的 UDP 通讯,通讯建立后,这台中间节点就不再需要了,这个可能是µTP 协议的功能,桥接节点也可能是µTP 协议随机找的一台 DHT 外网节点。
ryd994
2019-05-08 17:39:59 +08:00
这不叫打洞,对方有公网 IP。你发起连接,对方回复。nat 规则会留下双向记录,所以返回包也可以正常通过。
你怎么不想想你怎么上网的?你发起连接,出门的时候被 nat 到公网地址,然后服务器认为是在和这个公网地址会话。返回的包匹配到连接表里的这个条目,执行相反操作。不然你怎么收得到回包?

打洞是双方都是内网地址,这种情况下是无法由外向内主动发起连接的。只能在打洞服的协调下同时发起连接,这样连接表里各自就有了合法的条目,后续的包就可以通过了。


你看到的永远是对方公网地址,否则这包来源地址你怎么回复?要检查对方是不是内网很简单,使用另一个公网地址发起连接,用 tcpping 或 udpping,如果这样还会有回复那就是公网。反之则无法判断。你不知道是 nat 无法匹配而 drop 还是对方防火墙 drop。
liuminghao233
2019-05-08 17:46:30 +08:00
你先发了包给服务器
所以它可以 reply
ryd994
2019-05-08 17:47:39 +08:00
UDP nat,因为 UDP 无状态,只能依赖四元组来匹配。通过第三方公网节点中转,双方协商要用的四元组,然后使用同样的参数发起连接。各自的出站包会在连接表里增加条目。然后等对方入站包到的时候,连接表里就可以匹配反方向的四元组了。
现实中不可能完全同步,所以总有一方先到的会被弃。但是没关系,继续重试即可。

难点是你不知道出站 nat 会被 nat 成哪个端口,所以需要用 heuristic 猜测。协商只能协商内网端口,但路由器不一定就保持内网端口不变。猜得中就能打动成功。
brMu
2019-05-08 18:10:34 +08:00
@ryd994 厉害了我的哥,讲的太好了,给你点赞!👍
OneNian
2019-05-08 21:11:46 +08:00
@brMu
不想想这个打洞的服务器谁提供呢
上面回复的就是我一开始说的
shuiyingwuhen
2019-05-09 09:11:15 +08:00
@ryd994,学习到新姿势

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/562253

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX