[新功能请求] 建议支持nat1做种

fullcone nat 也就是nat1 会在一个固定的内网ip:端口情况下 产生一个固定的公网ip:端口 映射
我不清楚tcp和udp是否是分开的.

只需要程序去使用本地监听的udp端口, 发送一个stun请求去探测下外部端口就可以了.
(如果tcp和udp的映射不一样那就再用监听的tcp端口发送一个探测请求即可. 不过需要搭建服务.)
然后在更新tracker的时候提交这个正确的port.
所有别的nat和公网都可以直接连接回来这个nat1的人的机器.

公共的stun服务器有stun.l.google.com 这个好像多年都很稳定.

探测方法不限于stun. 任何检测客户端出站端口的都可以. 但是stun好像最方便.
探测都需要依赖外部服务, 无法独自完成. stun有公共的机器所以无需额外资源.

具体过程描述.
假如客户端端口是20000 内网wan ip是172.0.0.1 , 本地网卡192.168.1.10
程序使用udp 192.168.1.10:20000 去发送探测请求即可.
如果需要探测tcp 就用tcp 192.168.1.10:20000, 但是这样需要自建服务.
探测的封包必须使用程序监听的端口. 这样才可以获得机房那边nat开的端口.
然后根据stun回显, 提取正确数据即可. 他里面数据大概就是一个公网ip和一个端口.
(stun检测nat类型是发送很多个请求, 然后对比回来的包是否都一样. 或者不一样.
单纯检测端口的话应该只发送一个请求就够了.)
获得了正确的端口 比如端口是1234
那么程序在announce的时候, 端口就要用1234, 而不是20000.

至于dht announce是否需要改, 我就不清楚了. 如果报文里面有本地端口号的话那都得改.
//比如假如是这样, announce里面有自己的dht id , 种子hash , bt程序监听端口号.
那么那个监听的端口是必须改的, 否则连不上.

这个模式不依赖端口映射.

1個讚

其实已经有类似的建议了

1個讚

如果程序支持命令行设置向tracker回报的端口 和 程序监听端口, 就可以使用外部程序来处理这个问题.

没那么简单, 光向tracker报端口不行, dht也要报. 我试过了.
否则dht那边接不过来.

现有版本已经支持,只需启用utp即可实现nat1打洞做种上传,启用utp打洞后会自动向dht pex汇报打洞后的udp端口,用于被远程访问连接peer