IP 过滤匹配特定地址位（可能需要和其他 BT 客户端团队讨论）

比特彗星(BitComet) 建議意見
1

有的吸血 IP 符合特定规律，比如下面的 IP 的规律是：
xxxx:xxxx:xxxx:xxxx:2e0:61ff:fexx:xxxx，
2408:8352:a17:e370:2e0:61ff:fe5f:d456
2408:8352:a17:e370:2e0:61ff:fe60:b26
2408:8352:a17:e380:2e0:61ff:fe5f:dee2
2408:8352:a20:135d:2e0:61ff:fe5f:e20e
2408:8352:a20:135d:2e0:61ff:fe60:1622
2408:8352:a20:1493:2e0:61ff:fe5f:e252

这种情况下，可以选择匹配特定地址位，比如（注意：IP 过滤规则目前不支持这种格式）
02e0:61ff:fe5f/65-112
02e0:61ff:fe60/65-112
这样可以在不需要 PeerBanHelper 的情况下拦截更多的 IP，且列表可以缩减很多。

2

你提供的ip地址不规范，需要使用 CIDR 格式才能屏蔽
例
2408:8352:a17::/48
2408:8352:a20::/48

或者
2408:8352::/32

3

正是因为不符合 CIDR 格式，所以才需要匹配特定地址位。

看了一下 PeerBanHelper 的内置脚本 2e0-61ff-fe.av，目前 PBH 的做法是搜索字符串 :2e0:61ff:fe，而不是匹配地址位。

## @NAME IPV6 2e0:61ff:fe 随机后缀刷流 Peer 特征识别

## @AUTHOR PBH-BTN Community

## @CACHEABLE true

## @VERSION 1.0

## @THREADSAFE true

ipAddress = peer.peerAddress.address;

strIp = toString(ipAddress);

if(string.contains(strIp, ":2e0:61ff:fe")){

return "2e0:61ff:fe 特征段随机后缀 IPv6 识别";

}

return false;
4

意思是说为这个特殊的规律 添加专门的支持？

5

这样做搜索字符串没办法直接调用系统api去处理CIDR，性能损失很大，所以你用的PeerBanHelper软件才这么卡而且内存占用很大

而且后缀是可以自定义的，前缀是永久固定不变的，重新拨号也会在同一个前缀池中，别人换一下后缀你该如何处理？
https://bbs.itzmx.com/thread-99202-1-1.html

6

是啊。当前的 CIDR 格式对过滤 IP 某几位的情况无能为力。

7

不知道 PBH 能不能用使用管道或者 Windows 套接字等 IPC 与 BT 软件通信。现在的下载器应该没有支持这些的。
Windows 套接字可能更好，可以支持不在本地的下载器，又或者是 gRPC 之类的。gRPC 之类的可能更好（跨平台），这样可以管理多个下载器（目前 WebUI 就是这样）。

8

其实 现在用手动IP列表可以解决问题
事实上这种特征是不长久的 其应该只会在一段时间内存在
作为一个功能加入软件 不太现实

更可行的方法依然是使用IP过滤器或者防火墙软件
将IP收集和屏蔽的功能拆分开了

9

楼主说的应该是 IP地址 + 反掩码 匹配后缀

一般说的“掩码”指的是子网掩码
192.168.1.0/255.255.255.0 （192.168.1.0/24）
2400:1234:5678:abcd::/ffff:ffff:ffff:ffff:: (2400:1234:5678:abcd::/64)

而反掩码是
192.168.1.0/0.255.255.255 （对应的地址是 0.168.1.0, 1.168.1.0, 2.168.1.0, 3.168.1.0...）
::1234:1234:5678:abcd/::ffff:ffff:ffff:ffff （也就是IPv6常用的匹配后缀的方法）

在二进制下，子网掩码是前面1，后面0；而反掩码是前面0，后面1

nftables/iptables 支持反掩码是因为可以在规则里面进行位运算
（实际上不止 IP 地址，nft/ipt 任意数值都可以位运算）

根据开发者之前的回复，BC的IP过滤器是用IP范围（192.168.1.0-192.168.1.255）来匹配的
如果要支持这个特性，最好换成位运算，字符串匹配似乎不太优雅

1個讚
10

即使不打算支持这个特性，从算法角度来说，使用位运算来进行 IP 过滤，性能应该也会好一点吧（虽然对于现在的 CPU 来说字符串匹配应该没什么压力）

1個讚