layer7令人哭笑不得的问题

zyx914

按要求装好了layer7,而且也正常工作了一段时间，今天试验时发现一个奇怪的问题，过程如下：
1）
cd /etc/l7-protocols
cp bittorrent.pat  zyxxyz.pat
2)
修改zyxxyz.pat 把其中的bittorrent 改为 zyxxyz
3)
iptables -t mangle -A POSTROUTING -m layer7 --l7proto bittorrent  -j MARK --set-mark 18
iptables -t mangle -A POSTROUTING -m layer7 --l7proto zyxxyz      -j MARK --set-mark 18
4) 查看结果
iptables -t mangle -vL
结果如下:
42641 24M MARK all -- any any anywhere anywhere LAYER7 l7proto bittorrent MARK set 0x12
    0     0     MARK all -- any any anywhere anywhere LAYER7 l7proto zyxxyz MARK set 0x12

哈哈哈哈，唔唔唔唔！！！
我干了什么？我只是把BT协议的模板改了个名layer7就毫无作用了？
当然，这次是最典型的结果，在很多次试验中都出现了改名还有作用，但检测到的包数远少于原名的，真奇怪！！！！！！！！！

我的 bittorrent.pat 内容如下:
# Bittorrent - P2P filesharing / publishing tool - http://www.bittorrent.com
# Pattern quality: great veryfast
#
# This pattern has been tested and is believed to work well.  If it does not
# work for you, or you believe it could be improved, please post to
# l7-filter-developers@lists.sf.net .  This list may be subscribed to at
# http://lists.sourceforge.net/lists/listinfo/l7-filter-developers
bittorrent

# Does not attempt to match the HTTP download of the tracker
# 0x13 is the length of "bittorrent protocol"
# Second two bits match UDP wierdness, commented out until it's tested
# ^(\x13bittorrent protocol|d1:ad2:id20\x08'7P\)[RP])
# ^\x13bittorrent protocol
^(\x13bittorrent protocol|\x08'7P\)[RP]|\x13BitTorrent protocol|d1:ad2:id20d1:rd2:id20

新的 zyxxyz.pat 内容如下:
# zyxxyz - P2P filesharing / publishing tool - http://www.bittorrent.com
# Pattern quality: great veryfast
#
# This pattern has been tested and is believed to work well.  If it does not
# work for you, or you believe it could be improved, please post to
# l7-filter-developers@lists.sf.net .  This list may be subscribed to at
# http://lists.sourceforge.net/lists/listinfo/l7-filter-developers
zyxxyz

# Does not attempt to match the HTTP download of the tracker
# 0x13 is the length of "bittorrent protocol"
# Second two bits match UDP wierdness, commented out until it's tested
# ^(\x13bittorrent protocol|d1:ad2:id20\x08'7P\)[RP])
# ^\x13bittorrent protocol
^(\x13bittorrent protocol|\x08'7P\)[RP]|\x13BitTorrent protocol|d1:ad2:id20d1:rd2:id20








    

platinum

原帖由 "zyx914" 发表：

42641 24M MARK all -- any any anywhere anywhere LAYER7 l7proto bittorrent MARK set 0x12
   0     0     MARK all -- any any anywhere anywhere LAYER7 l7proto zyxxyz MARK set 0x12

逻辑上的问题。。。
两个规则匹配的内容完全一样，顺序有先后，前面的都已经被匹配走了，已经没有数据包能再被后面规则匹配

你的问题也挺令人哭笑不得的 ^_^

zyx914

原帖由 "platinum" 发表：

逻辑上的问题。。。
两个规则匹配的内容完全一样，顺序有先后，前面的都已经被匹配走了，已经没有数据包能再被后面规则匹配

你的问题也挺令人哭笑不得的 ^_^

那好办,我们把这两句的顺序改变一下,
iptables -t mangle -A POSTROUTING -m layer7 --l7proto zyxxyz      -j MARK --set-mark 18
iptables -t mangle -A POSTROUTING -m layer7 --l7proto bittorrent  -j MARK --set-mark 18
我只能告诉你,试验的结果完全一样!!!!!!这是实际试验出来的结果,不是想象的!!!!!!


您所说的"前面的都已经被匹配走了"是错误的, -j MARK 只是做了标记,但数据包并没有离开mangle表也没有离开 POSTROUTING,因此仍然可以被下面一句所匹配,这也是实验所证实的.

platinum

原帖由 "zyx914" 发表：
您所说的"前面的都已经被匹配走了"是错误的, -j MARK 只是做了标记,但数据包并没有离开mangle表也没有离开 POSTROUTING,因此仍然可以被下面一句所匹配

你说的也有道理，如果仅仅是 MARK 的话，packet 确实没有脱离 netfilter
不过我三个疑问

1、你的 MARK 是在 mangle 表的 PREROUTING 链中做的吗？

2、你确保两个链的内容完全一样吗？

1. 
   
2. ^(\x13bittorrent protocol|\x08'7P\)[RP]|\x13BitTorrent protocol|d1:ad2:id20:|d1:rd2:id20:)
   

复制代码

我看到官方并没有这样的正则匹配式

3、你是在启用规则后开始下载 BT 的，还是先下载 BT 后启用的规则？

zyx914

1、你的 MARK 是在 mangle 表的 PREROUTING 链中做的吗？
我是在 POSTROUTING 中作的,我试过,好象是
iptables -t mangle -A POSTROUTING -m layer7 --l7proto bittorrent  -j MARK --set-mark 18
与
iptables -t mangle -A PREROUTING -m layer7 --l7proto bittorrent  -j MARK --set-mark 18
效果是一样的

2、你确保两个链的内容完全一样吗？
代码:
^(\x13bittorrent protocol|\x08'7P\)[RP]|\x13BitTorrent protocol|d1:ad2:id20d1:rd2:id20

我看到官方并没有这样的正则匹配式

a:两个.pat 的内容几乎完全一样,可以看我第一贴中的.
b:既然两个正则表达式一样,那么这个正则表达式的正确与否就是次要的问题,关键是一样的内容为什么不一样的结果.
c:我最新的,附合GNU C的限BT的正则表达式为
^(\x13bittorrent protocol|\x08'7P\)[RP]|d1:[ar]d2:id20
原表达式我认为没错,只是有重复.

3、你是在启用规则后开始下载 BT 的，还是先下载 BT 后启用的规则？
这个问题在测试时无所谓,实际效果是一样的.

(你的回贴我无法引用)

platinum

我认为问题可能出在第三点上
L7 匹配的时候是取一个 connection 的前 2K 字节
如果一个 BT 已经下载，后启用 L7 的话，它将不能匹配到这是 BT 协议，关于这点，我用官方提供的正则测试过

zyx914

原帖由 "platinum" 发表：
我认为问题可能出在第三点上
L7 匹配的时候是取一个 connection 的前 2K 字节
如果一个 BT 已经下载，后启用 L7 的话，它将不能匹配到这是 BT 协议，关于这点，我用官方提供的正则测试过

理论上正确,但实际上BitComet/Azureus等BT程序几乎总是在不停的对外发出联接请求,测试的时间长一点就可以了.
而且这一问题并不影响到同一正则表达式得出不同的结果呀!!
我的正则表达式实际上也是官方的,只是被注释了.

枫影谁用了

原帖由 "platinum" 发表：
我认为问题可能出在第三点上
L7 匹配的时候是取一个 connection 的前 2K 字节
如果一个 BT 已经下载，后启用 L7 的话，它将不能匹配到这是 BT 协议，关于这点，我用官方提供的正则测试过

这个好像是!
很多时候包可以漏过..比如QQ..我在公司是和time一起用.如果先前上线的qq..那么你再禁就不行..很多时候不能巨配到.但如果你是禁止后上线的话..这就可以巨配到.

platinum

我也觉得很奇怪，确实不应该出现这样的情况。。。。

zyx914

platinum大法师,您是否也象我一样只是把bittorrent.pat等改个名,好象是一处新的协议一样让l7处理一下看看结果如何.