KCCat

我是有注意到类似问题，但还没有很好的解决思路。 * 有部分网站在tcp握手时好像用了类似Synproxy的技术，这时没法获得正确的TTL，客户端是在与防火墙在握手，这时要想链接保持正常，只能寄希望于服务器发送纯ack应答，或者大小为mss协商值的最大包。 * 另一部分网站似乎有一种策略，虽然握手阶段是正常的，取得正确的TTL。但之后通信时的纯ACK应答包似乎是由防火墙发出，或者经过了额外的设备，TTL值有很大的变化。这时候这套规则会把ACK应答的TTL记录而把有数据的包都丢弃，这样一部分网站就不能正常访问了。 目前有一个临时的解决方法是把第60行规则： ```-A TTLTCP -m connmark ! --mark 0x0/0xff -m bpf --bytecode "18,48 0 0 0,84 0 0 240,21 0 14 64,48 0 0 9,21 0...

其实一开始我只打算用U32模块的，然而受限于U32没有```变量=变量```这样比较的写法，还没有没有加减运算符，然后才改用bpf的。 延迟我也有考虑过，iptables和TC控流做配合，把疑似劫持包都打上标记送到tc加延迟（例1000ms）这样劫持包就会比正确的包晚到达。而万一误杀正确的包最后也会到达。 然而这样可能会让服务器因为迟迟收不到应答而重传，或者让TCP拥塞算法误以为网络情况糟糕而缩小窗口。并且带有RST或者FIN标记的包延迟到达是不是还会截断连接，我还是对TCP了解太少。

如果现成的固件没有对应的模块，你可能要找找固件作者有没有一同编译ipk包，或者使用官方源的ipk包 如果没有合适的ipk包，那就需要自行编译把模块集成进固件里去了