路由器重载后 ARP/NAT 冲突。是客户端幽灵还是固件 bug？
2 分•作者: asdem•3 个月前
我有一台 Keenetic Extra DSL 路由器。我配置了一个静态 DHCP 预留，以便我的 ESP32-W5500 设备（MAC 地址：de:ad:be:ef:fe:01）始终获得 IP 地址 192.168.1.114。有一个基于 MAC 地址的端口转发规则指向端口 80，并且一个名为 [subdomain].keenetic.pro 的定义好的子域名也指向此设备。
在软重启后，端口转发到 WAN 的流量会悄无声息地失效。规则在面板中显示为活动状态，但来自外部的入站连接会超时。
这个问题在过去几个月里，在多次软重启事件中反复出现，每次都指向一个不同的“幽灵”IP（.100、.101、.102）。
然而，从本地网络来看，我始终可以不间断地通过其分配的静态 IP 地址（.114）访问该客户端。而且最奇怪的是：如果我只是在路由器的界面上禁用然后重新启用端口转发规则，问题就会立即消失，外部 WAN 访问也会恢复。
奇怪之处在于：在出现故障时，当我查看路由器自身的诊断工具时，ARP 表和 NAT 表完全相互矛盾。
来自路由器系统日志：
DHCP 工作正常
16:34:35 — 客户端请求 .101
16:34:35 — 路由器发送 NAK，拒绝
16:34:35 — 客户端发送 DISCOVER；路由器提供预留的 .114
16:34:35 — 客户端收到 .114 的 ACK
Nginx 代理在 DHCP 后 4 秒连接到错误的 IP
16:34:39 — 激活代理 [subdomain].keenetic.pro 指向 http://192.168.1.101:80
Nginx 在 2 秒内“自我纠正”
16:34:41 — 激活代理 [subdomain].keenetic.pro 指向 http://192.168.1.114:80
但是，正如下面的 CLI 日志所示，Nginx 的自我纠正并不能阻止入站流量仍然被转发到 .101 的幽灵 IP。
19:00:59 — CLI 捕获：
show ip neighbour:
id: 6
via: de:ad:be:ef:fe:01
address: 192.168.1.101
expired: yes ← 无效
id: 7
via: de:ad:be:ef:fe:01
address: 192.168.1.114
expired: no ← 有效
show running-config | grep "ip static":
ip static tcp PPPoE0 80 de:ad:be:ef:fe:01
show ip nat – 入站 WAN 端口 80 流量：
TCP 172.71.102.232 13498 [WANIP] 80 4
192.168.1.101 80 172.71.102.232 13498 4
TCP 172.71.102.232 10776 [WANIP] 80 4
192.168.1.101 80 172.71.102.232 10776 4
在 19:00:59 时，入站流量仍然被转发到 .101 的幽灵 IP。
专家提问：
这是客户端问题，还是路由器存在 bug？
查看原文
I have a Keenetic Extra DSL router. I configured a static DHCP reservation so that my ESP32-W5500 device (MAC: de:ad:be:ef:fe:01) always receives 192.168.1.114. There's a MAC-based port forwarding rule for port 80, and a defined [subdomain].keenetic.pro points to this device as well.<p>After a soft-restart, port forwarding silently breaks for WAN traffic. The rule appears active in the panel, but incoming connections from the outside just time out.<p>This has recurred consistently across multiple soft-reload events over several months, with a different "ghost" IP each time (.100, .101, .102).<p>From the local network, however, I can always reach the client on its assigned static IP (.114) without any interruption. And here's the kicker: if I simply disable and re-enable the port forwarding rule from the router's interface, the problem vanishes instantly and external WAN access comes right back.<p>The weird part: during an outage, when I look at the router's own diagnostic tools, the ARP table and the NAT table completely contradict each other.<p>From the router's system logs:<p>DHCP is working correctly<p>16:34:35 — Client requests .101
16:34:35 — Router sends NAK, rejects it
16:34:35 — Client sends DISCOVER; router offers the reserved .114
16:34:35 — Client receives ACK for .114<p>Nginx proxy connects to the wrong IP 4 seconds after DHCP<p>16:34:39 — activated proxy [subdomain].keenetic.pro to http://192.168.1.101:80<p>Nginx "corrects" itself within 2 seconds<p>16:34:41 — activated proxy [subdomain].keenetic.pro to http://192.168.1.114:80<p>But nginx correcting itself does not stop incoming traffic from still being forwarded to the .101 ghost IP, as the CLI logs below show.<p>19:00:59 — CLI capture:<p>show ip neighbour:<p>id: 6
via: de:ad:be:ef:fe:01
address: 192.168.1.101
expired: yes ← INVALID<p>id: 7
via: de:ad:be:ef:fe:01
address: 192.168.1.114
expired: no ← VALID<p>show running-config | grep "ip static":<p>ip static tcp PPPoE0 80 de:ad:be:ef:fe:01<p>show ip nat – incoming WAN port 80 traffic:<p>TCP 172.71.102.232 13498 [WANIP] 80 4
192.168.1.101 80 172.71.102.232 13498 4<p>TCP 172.71.102.232 10776 [WANIP] 80 4
192.168.1.101 80 172.71.102.232 10776 4<p>At 19:00:59, incoming traffic is still being forwarded to the .101 ghost IP.<p>Question for the experts:
Is this a client-side issue, or does it point to a bug in the router?