这是一个创建于 2026 天前的主题，其中的信息可能已经有所发展或是发生改变。
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
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
 |
1
sean10 2019-05-08 16:51:06 +08:00 via Android
对，NAT 打洞
|
 |
2
dryadent 2019-05-08 16:55:08 +08:00
一般都是 NAT 映射出去的
|
 |
3
ihipop 2019-05-08 17:05:44 +08:00 via Android  1
upnp
|
 |
4
OneNian 2019-05-08 17:08:51 +08:00 via iPhone
你作为客户端先去请求资源的，并不是公网的用户直接给你发数据。
运营商的 nat 是无法穿透的，upnp 也不能传递 |
 |
5
brMu OP @sean10
感谢，我又搜了下，这篇文章讲的太细了，应该就是通过中间服务器来实现 UDP 打洞的。 https://blog.csdn.net/ustcgy/article/details/5655050 |
 |
8
catalina 2019-05-08 17:19:55 +08:00
@brMu bt 的 tracker 只是告诉你这个种子有哪些 ip 在下载、哪些 ip 在上传而已。。。否则怎么能叫 p2p ？
|
|
9
brMu OP |
 |
10
ryd994 2019-05-08 17:39:59 +08:00 via Android 4
这不叫打洞，对方有公网 IP。你发起连接，对方回复。nat 规则会留下双向记录，所以返回包也可以正常通过。
你怎么不想想你怎么上网的？你发起连接，出门的时候被 nat 到公网地址，然后服务器认为是在和这个公网地址会话。返回的包匹配到连接表里的这个条目，执行相反操作。不然你怎么收得到回包？ 打洞是双方都是内网地址，这种情况下是无法由外向内主动发起连接的。只能在打洞服的协调下同时发起连接，这样连接表里各自就有了合法的条目，后续的包就可以通过了。 你看到的永远是对方公网地址，否则这包来源地址你怎么回复？要检查对方是不是内网很简单，使用另一个公网地址发起连接，用 tcpping 或 udpping，如果这样还会有回复那就是公网。反之则无法判断。你不知道是 nat 无法匹配而 drop 还是对方防火墙 drop。 |
 |
11
liuminghao233 2019-05-08 17:46:30 +08:00 via iPhone
你先发了包给服务器
所以它可以 reply |
|
12
ryd994 2019-05-08 17:47:39 +08:00 via Android 4
UDP nat，因为 UDP 无状态，只能依赖四元组来匹配。通过第三方公网节点中转，双方协商要用的四元组，然后使用同样的参数发起连接。各自的出站包会在连接表里增加条目。然后等对方入站包到的时候，连接表里就可以匹配反方向的四元组了。
现实中不可能完全同步，所以总有一方先到的会被弃。但是没关系，继续重试即可。 难点是你不知道出站 nat 会被 nat 成哪个端口，所以需要用 heuristic 猜测。协商只能协商内网端口，但路由器不一定就保持内网端口不变。猜得中就能打动成功。 |
 |
15
shuiyingwuhen 2019-05-09 09:11:15 +08:00
@ryd994，学习到新姿势
|
Select Language