某路由的NAT环回失效

2025-11-03 作者： Fisherworks

ikuai，遇到一次蛮奇怪的内网通过公网域名+端口映射访问内网服务器失败的情况。简而言之，对内网服务，公网可以访问，反而内网无法访问（呈现包drop状态）。此处猜测是路由器的NAT reflection（NAT环回、NAT回流）失效了。

第一反应肯定是先走内网（LAN）直连目标服务，结果显然OK，毕竟公网访问没问题，那显然目标服务本身正常，没毛病。

现象如此的话，除了在内网目标服务器上来一把  tcpdump 之外，好像并木有更好的办法。

先测试  LAN(USR)1.49 ---> LAN(SRV)1.224 ，抓包结果一目了然。

客户端mac addr 71、ip 1.49请求服务端ip 1.224，发起SYN。

得到服务端的SYN-ACK，没毛病。客户端再返一个ACK就收工了（未截图）。

接下来测试  LAN(USR)1.49 ---> WAN(NAT)1.1 ---> LAN(SRV)1.224 ，这里就开始闹幺蛾子了。

由于客户端ip 1.49请求的是路由器的WAN ip，该包第一站是路由器LAN ip 1.1。路由器LAN口收包后，发现目标ip命中路由器的WAN ip，目的端口也同时命中映射端口中的一个，那么接下来走nat表的prerouting链中的reflection rules中的一条，目的地址转换，DNAT到内网服务器1.224的指定端口。做完forward之后，该包走出LAN口之前，走到nat表postrouting链上再进一条reflection rules，源地址转换，SNAT为路由器本身的LAN ip 1.1，此时包发出。

别忘了，抓包在目标服务器ip 1.224上进行。讲道理，这里收到的包不应该直接来自客户端1.49对吧？这种情况下与目标服务器进行收发包的，理应只有1.1的NAT网关地址。

而如下抓包结果吊诡之处在于，数据包从二层看是从路由器mac addr 20发出的，而三层没有做SNAT，用的客户端ip 1.49 —— 好家伙，伪造src ip了属于是，此时要是做个arp scan应该怎么算？

既然发包就二层/三层对不齐了，那回包也就没法保障了。这边很清晰的看到，服务端ip 1.224把SYN-ACK直接回给了客户端mac 71、ip 1.49。收包的没发，发包的没收，就别指望最后的ACK了。

所以我们再思考一遍，网关LAN口（实际ip 1.1）伪造了1.49的src ip向目标1.224发包，而目标把回包发给了正版1.49，俩人变仨人，自然聊不下去，可耻的失败了。

表层原因找到了，按理要找一下根本原因。但由于爱快路由固件是免费而不开源，控制台只有几个选项，无法直接命令行查看iptables条目，因此也就无从深入调查问题root cause。

讲道理ikuai固件多数时候还是可靠的，用了足有5年了，这么诡异的问题还是第一次遇到。既然问题难以深究，那就只好祭出重启大法。嗯，好在bug并非持久性问题，重启后再测，一切恢复正常。

无论搞NAT还是firewall，无论问题表象看来有多诡异，抓包都是抽丝剥茧的关键工具。tcpdump加上合理的过滤条件，导出后用wireshark细细品评，或多或少总有些蛛丝马迹渐渐显露。

Clear thinking is critical.

文章的脚注信息由WordPress的wp-posturl插件自动生成