[疑问/探讨] 关于透明代理劫持 LAN 侧 DHCP/NTP 单播请求的历史漏洞与当前底层实现机制

[SlippinDylan]

你好，感谢作者提供这么优秀的 Nikki 插件！

我是一名软路由老玩家，最近在排查局域网设备的网络稳定性问题时，深入跟踪了 Nikki 生成的 nftables 规则。现在我有一个关于 “透明代理劫持局域网单播基础服务 (DHCP Renew / NTP)” 的技术疑问，想和作者探讨一下目前的底层实现机制。

1. 历史背景与痛点

在几个月前我使用的旧版本（约 v1.24.4 左右，ImmortalWrt 24.10 环境）中，我遇到了一个极其经典的透明代理幽灵 Bug：
局域网内的手机或 Mac 刚连上 Wi-Fi 时正常（因为 DHCP Discover 是广播包，透明代理不劫持），但使用几个小时后，租期过半触发 DHCP 单播续租（UDP dst port 67） 时，续租包被代理核心劫持进黑洞。最终导致租约到期，设备强制掉线并回退到 169.254.x.x 的 APIPA 地址。
同样的，局域网设备向路由器（10.10.0.1）发起的 NTP 单播同步请求（UDP 123）也会 timeout。

当时我只能写一个脚本，在 router_tun / router_redirect 链执行前，硬插入 udp dport 67/68/123 counter return 的 bypass 规则来解决。

2. 当前版本的观察

今天我重新编译了最新版的 ImmortalWrt 并升级了最新版 Nikki。在没有执行任何自编修复脚本的情况下，我发现：

1. 局域网设备的 DHCP 续租不再断网。
2. Mac 执行 sntp 10.10.0.1 能够秒级同步时间。

我在终端抓取了 nft list chain inet nikki router_tun，发现新版对路由器自身发出的包使用了非常优雅的 skuid 123 和 cgroupv2 "services/dnsmasq" 来做 bypass。但这仅作用于 OUTPUT 链。

3. 探讨的核心疑问

对于从 LAN 侧发起，流向 Router 本身（Inbound -> PREROUTING）的单播包，当前版本并没有看到显式排除 67/68/123 端口的规则。

请问作者：

1. 当前版本能完美避开劫持，是因为强依赖了 reserved_ip（包含了局域网网段）从而在进入劫持链前直接 return 了吗？
2. 如果用户在面板中修改了 reserved_ip 集合（例如删除了 10.0.0.0/8），是否会导致 DHCP 单播续租被劫持的问题死灰复燃？
3. 在之前的旧版本（如 v1.24.4）中，是否存在生成规则顺序的问题，导致内网单播 UDP 流量意外漏进了代理引擎？
4. 目前项目是否有在 fw4 层面利用 fib daddr type local 等更底层的路由判定来免疫 Router 本机流量？

期待作者的技术解惑，这对我们这些在使用自定义网段和自定义白名单策略的用户来说非常重要。再次感谢维护！

[morytyann]

问题4里说的规则是存在的，但是是在nikki表里。

因为问题4里说的规则存在，理论上问题1的保留地址的绕过规则并不需要，所以问题2的答案应该是否，但我测试过发现如果没有保留地址的绕过规则会导致米家设备断网，当时没有深究，就保留了该规则。

问题3中说的旧版本，我使用时没有遇到续租失败的情况，我有空了看看中间的变更，看是不是哪一次“意外”修复了。

[SlippinDylan]

感谢回复！米家设备那个情况确实是个坑，IoT 设备的网络探测有时候就很迷，留着 @reserved_ip 兜底确实是最稳妥的办法。

顺着你的思路，我切回 v1.24.3 和 v1.24.4 翻了一下代码历史，还真就像你说的，是被后来的一次提交“意外”修好的。

其实底层的 fib daddr type local 防劫持规则一直都在，断网是因为解析配置的时候踩坑了，导致规则没加载上：

1. 配置解析报错导致防火墙“裸奔”：
   老版本的 hijack.ut 只认配置顶层的 redir-port 等端口。我当时用了带 listeners 数组的新版 Mihomo 配置格式，脚本读不到端口，生成了类似 redirect to : 这种带语法错误的规则。结果就是 nft -f 报错退出，整个 nikki 表都没写进内核，那条最关键的 fib 规则自然也跟着失效了。
2. TUN 路由盲目接管：
   虽然防火墙规则加载失败了，但 nikki.init 还是按流程建了 TUN 的策略路由（ip rule/route）。没了 fib 规则，局域网发给路由器的 DHCP 单播续租包（UDP 67），被系统其他机制打上 mark 后直接掉进了 TUN 黑洞，导致设备租约到期后拿不到 IP（变成 169.254.x.x）从而断网。

仔细查了下提交记录，这个暗病在 728f4ab (fix: hijack failed when both tun and tun listener were present，随 v1.25.2 发布) 被彻底干掉了。有了对 profile['listeners'] 的深度解析，语法不再报错，防劫持规则终于能稳定生效了。

昨晚全新部署了最新的 ImmortalWrt + Nikki，现在的网络体验非常丝滑。之前淘宝、小红书加载极其缓慢、连接超时的问题彻底没了，基本全是秒开。

感谢作者的解答和持续维护，现在这套底层逻辑用着非常舒服！