回复platinum
白金兄，你这里的描述，并没有明确提出，打过 mark 的就不需要往下匹配了啊
我刚才 ...
Godbach 发表于 2011-07-15 10:02 http://bbs.chinaunix.net/images/common/back.gif
哈哈，我提前设了一个伏笔，结果被 Godbach 看出来了！
我是故意没有提出这个明确的需求的：）
用法是结合实际需求而来的，没有明确规定。
就这个例子来说，需要 MARK 的和需要 DROP 的数据丝毫没有关系，既然这样，为何不 MARK 之后立刻结束下面丝毫无用的匹配呢？
圈套就在这里 ;P
本帖最后由 Godbach 于 2011-07-15 12:46 编辑
回复 41# platinum
白金兄，这个 -g 的功能，对于 iptables 来说是结束当前表所在的 hook 函数的处理，还是结束了当前 hook 点所有 hook 函数的处理？
个人应该是第一种。第二种其实就是 NF_STOP 的功能。
对，是第一种
个人感觉相当于 -j ACCEPT 了
回复 43# platinum
嗯，应该是的
回复 30# platinum
1、nat 表只匹配一个连接的前几个包（TCP 和 UDP 的实现略有不同），后续数据无法被 nat 表的规则匹配
能否说明一下tcp和udp的具体不同？
回复platinum
能否说明一下tcp和udp的具体不同？
瀚海书香 发表于 2011-07-15 16:03 http://bbs.chinaunix.net/images/common/back.gif
在 conntrack 时，TCP 协议需要分析三次握手，UDP 协议只需要分析有没有 REPLY，就这里有些区别
回复 24# platinum
to 白金兄 & 瀚海兄：
二位的实现在 匹配上用的什么匹配呢。（惭愧，我懒得看代码了）
和 string 匹配（并且指定偏移量）相比，哪个性能更好一些？
回复 47# Godbach
由于dns协议的特点导致，需要使用string的hex-string来进行匹配。
效率的话，感觉要比string快一些，因为根据dns的特点，直接找到存储域名的地方，然后进行匹配的。
回复 48# 瀚海书香
效率的话，感觉要比string快一些，因为根据dns的特点，直接找到存储域名的地方，然后进行匹配的。
对，使用 hex-string。而且我还专门提到了可以指定 --from 和 --to 选项。因为被请求的域名在 DNS 包中的位置也是有规律的。
这种条件下，在效率上是否还比 string 好。如果好的话，请指出具体的方面。
回复platinum
to 白金兄 & 瀚海兄：
二位的实现在 匹配上用的什么匹配呢。（惭愧，我懒得看代码了）
...
Godbach 发表于 2011-07-16 13:25 http://bbs.chinaunix.net/images/common/back.gif
我是之前分析的 DNS 的请求信令，直接找到域名的 offset
在程序里直接从这个 offset 利用 memcmp 比较之前生成好的串