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