这是一个创建于 234 天前的主题，其中的信息可能已经有所发展或是发生改变。
也不是完全不生效，有 90%流量不走 iptables DROP 规则，直接硬件 HNAT 转发出去了，完全拦截不下来。
昨天百思不得其解，tcpdump 也拦截不下来，明明就是有数据通过的。今天发现只要把硬件 IP 包转发关闭，也就是（ Hardware NAT 功能关闭），就恢复正常了。
路由器毕竟不是传统的 LINUX ，吃了经验的亏。
昨天百思不得其解，tcpdump 也拦截不下来，明明就是有数据通过的。今天发现只要把硬件 IP 包转发关闭，也就是（ Hardware NAT 功能关闭），就恢复正常了。
路由器毕竟不是传统的 LINUX ，吃了经验的亏。
9 条回复 • 2024-05-22 23:36:10 +08:00
 |
1
tool2d OP 昨天我试了
iptables -t raw -I PREROUTING 1 -m mac --mac-source fc:aa:14:43:12:23 -j DROP 对 TCP 和 ICMP 立刻生效，对一部分 UDP 不生效。 真是整的怀疑人生，能不能拦截包，全看路由器的心情。 |
 |
2
2kCS5c0b0ITXE5k2 234 天前 via iPhone
Hardware NAT 优先级比 iptables 优先级高
|
 |
3
ranaanna 233 天前
为什么一定要在 raw 表中定义 drop ？是出于 drop early drop fast ，从而减少系统开销的考虑？较早的时候 raw 表唯一的功能是给数据包一个 notrack ，所以也许是你的路由器在设计的时候并没有预料到你会这么早 drop 掉数据包？
何不在缺省的 filter 表中试试，给系统预设的硬件加速一个机会？ |
|
4
tool2d OP @ranaanna 正常来说，也不是一开始对 raw 表下手的。是-t filter FORWARD 没生效后，就死马当活马医。
当时我并不知道硬件加速会跳过一些 UDP 包，用 iptables -vL 看 pkts 数量完全不涨，但又不是 100%复现，所以才迷茫。 |
|
6
tool2d OP @ranaanna 刚试了一下 INPUT ，不行。路由器只是转发包，走 FORWARD ，最终接收才是走 INPUT 。
看 https://zersh01.github.io/iptables_interactive_scheme/ ，INPUT 和 FORWARD 似乎是两条分叉路径，二选一。 |
 |
7
ogodeikhan24k 227 天前
1. 你路由器是哪家平台？比如高通家的一般是 session 首包是走协议栈，后面包是走 fast path 的
2. 你如果过滤 mac ，可以尝试下 ebtables ， 不用 iptables |
|
8
tool2d OP @ogodeikhan24k MTK Arm 的，我看 HNAT 表现和你说的高通很类似，只要 conntrack 没有代表首包，全部拦截下来了。后面 UDP 就是走 fast path 。
|
 |
9
feng0vx 183 天前
硬件转发的 ebtables 也拦不了吧，op 有没有试
|
Select Language