so many dropped packets, why?

[siril233]

Here is a modified filter queue:

*filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :TTLDROP - [0:0] :TTLTCP - [0:0] :DROPWITHLOG - [0:0] -A DROPWITHLOG -m limit --limit 180/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4 -A DROPWITHLOG -j DROP -A INPUT -m state --state INVALID -j DROP -A INPUT -i ppp0 -p tcp -j TTLTCP -A FORWARD -m state --state INVALID -j DROP -A FORWARD -i ppp0 -p tcp -j TTLTCP -A FORWARD -o ppp0 -p tcp -m connmark ! --mark 0x0/0xff -m u32 --u32 "0x0>>0x16&0x3c@0xa&0xfff=0x11" -j CONNMARK --set-xmark 0x0/0xff -A OUTPUT -o ppp0 -p tcp -m connmark ! --mark 0x0/0xff -m u32 --u32 "0x0>>0x16&0x3c@0xa&0xfff=0x11" -j CONNMARK --set-xmark 0x0/0xff -A TTLDROP -m u32 --u32 "0x5&0x1=0x1" -m connmark ! --mark 0x1/0x1 -j DROPWITHLOG -A TTLDROP -m u32 --u32 "0x5&0x2=0x2" -m connmark ! --mark 0x2/0x2 -j DROPWITHLOG -A TTLDROP -m u32 --u32 "0x5&0x4=0x4" -m connmark ! --mark 0x4/0x4 -j DROPWITHLOG -A TTLDROP -m u32 --u32 "0x5&0x8=0x8" -m connmark ! --mark 0x8/0x8 -j DROPWITHLOG -A TTLDROP -m u32 --u32 "0x5&0x10=0x10" -m connmark ! --mark 0x10/0x10 -j DROPWITHLOG -A TTLDROP -m u32 --u32 "0x5&0x20=0x20" -m connmark ! --mark 0x20/0x20 -j DROPWITHLOG -A TTLDROP -m u32 --u32 "0x5&0x40=0x40" -m connmark ! --mark 0x40/0x40 -j DROPWITHLOG -A TTLDROP -m u32 --u32 "0x5&0x80=0x80" -m connmark ! --mark 0x80/0x80 -j DROPWITHLOG -A TTLDROP -m u32 --u32 "0x5&0x1=0x0" -m connmark ! --mark 0x0/0x1 -j DROPWITHLOG -A TTLDROP -m u32 --u32 "0x5&0x2=0x0" -m connmark ! --mark 0x0/0x2 -j DROPWITHLOG -A TTLDROP -m u32 --u32 "0x5&0x4=0x0" -m connmark ! --mark 0x0/0x4 -j DROPWITHLOG -A TTLDROP -m u32 --u32 "0x5&0x8=0x0" -m connmark ! --mark 0x0/0x8 -j DROPWITHLOG -A TTLDROP -m u32 --u32 "0x5&0x10=0x0" -m connmark ! --mark 0x0/0x10 -j DROPWITHLOG -A TTLDROP -m u32 --u32 "0x5&0x20=0x0" -m connmark ! --mark 0x0/0x20 -j DROPWITHLOG -A TTLDROP -m u32 --u32 "0x5&0x40=0x0" -m connmark ! --mark 0x0/0x40 -j DROPWITHLOG -A TTLDROP -m u32 --u32 "0x5&0x80=0x0" -m connmark ! --mark 0x0/0x80 -j DROPWITHLOG -A TTLTCP -m connmark ! --mark 0x0/0xff -m bpf --bytecode "29,48 0 0 0,84 0 0 240,21 0 25 64,48 0 0 9,21 0 23 6,40 0 0 6,69 21 0 8191,177 0 0 0,80 0 0 12,84 0 0 240,116 0 0 4,2 0 0 3,48 0 0 0,84 0 0 15,7 0 0 6,96 0 0 3,12 0 0 0,36 0 0 4,2 0 0 7,40 0 0 2,7 0 0 9,96 0 0 7,29 0 5 0,177 0 0 0,72 0 0 12,84 0 0 4087,21 0 1 16,6 0 0 262144,6 0 0 0" -m comment --comment "(((tcp[12] & 0xF0) >> 4) + (ip[0] & 0xF))

• 4 = ip[2:2] && (tcp-fin | tcp-syn | tcp-rst | tcp-urg) & tcp[tcpflags] = 0" -j RETURN -A TTLTCP -m connmark ! --mark 0x0/0xff -m mark ! --mark 0x1/0x1 -j TTLDROP -A TTLTCP -m connmark ! --mark 0x0/0xff -m u32 --u32 "0x0>>0x16&0x3c@0xa&0xfff=0x11" -j CONNMARK --set-xmark 0x0/0xff COMMIT

---

based on http://www.thegeekstuff.com/2012/08/iptables-log-packets/?utm_source=feedburner

then, dmesg | grep Drop | tail -30 and check non-http traffic: dmesg | grep Drop | grep -v =80 | tail -30

obviously the ISP(china telecom) needn't hijack every connection.

ISP无必要劫持每个连接吧， 这里一定有误伤。 但是，令人十分惊奇地， 似乎不影响使用？？？

环境： centos 7.3

[siril233]

补充： 并非完全不影响使用， 浏览器打开一些站点无限转圈，总是卡在加载一部分网页内容的域名上。

[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 12 6,40 0 0 6,69 10 0 8191,177 0 0 0,80 0 0 12,84 0 0 240,37 0 6 80,80 0 0 13,7 0 0 8,0 0 0 39,92 0 0 0,21 0 1 0,6 0 0 262144,6 0 0 0" -m comment --comment "tcp[0xC]&0xF0>0x50 && (tcp-fin|tcp-syn|tcp-rst|tcp-urg)&tcp[tcpflags]=0x0" -j TTLSYN 修改为 -A TTLTCP -m connmark ! --mark 0x0/0xff -m u32 --u32 "0x0>>0x16&0x3c@0xa&0xfff=0x18,0x10" -m length --length 0:940 -j TTLSYN 从只接受ack应答改为接受长度小于940的包，但我担心只用长度来区分包会让规则太宽松且没有依据。

[siril233]

赞。

我不太熟悉 bpf， bpf是否足够灵活，可以实现一个学习的机制， 去主动发现相关设备假数据包的ttl？

若不能，考虑把 -j DROP 改为 -j NFQUEUE --queue-num 1 这样搞个程序 借助 libnetfilter_queue 处理漏网之鱼呢？

---

或者干脆拿libnetfilter_queue 重写算了， 或许还有其他特征可以利用，比如延迟 XD

[KCCat]

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

[siril233]

对， 这也是个大问题。 我觉得 识别出假数据包 ->取出其中可读字符串部分log下来 ->据此生成字符串过滤规则 大概是可行之道。 但是不写程序大概搞不定... 有空试试，就是性能影响未知。