iptables/Netfilter 用了快 20 年了，犄角旮旯的细节早就摸烂了，总结一些 tips/tricks 避免后人踩坑，随手记，碰到一个写一个，有人咨询的好问题也会写出来。关于这类问题要不要问 AI，最后会说。

今天说 MASQUERADE，先看 iptables-extensions’s manual ：

Linux Netfilter 在处理 conntrack NAT 时有个细节，如果 conn 与某条 MASQ 规则关联，只要其 out-device 发生改变，conn 即被 destroy，skb 被 drop。

基于此，想象下面的情景并观测：

conntrack -E --event-mask NEW,DESTROY -p tcp -d 10.0.0.100

• 配置 iptables MASQ 的虚拟网卡 tun0-10.0.0.2 正常工作；
• TCP 连接 A：192.168.56.100:1195 - 10.0.0.100:123 经 tun0 建立；
• A 被 MASQ 到 conn m：[192.168.56.100:1195 - 10.0.0.100:123, R 10.0.0.100:123 - 10.0.0.2:1195]，数据正常传输；
• tun0 应用崩溃，tun0 销毁；
• tun0 路由丢失，连接 A 报文 x 欲经 default gw 192.168.56.1 发出；
• 连接 A 报文 x 命中 MASQ 性质的 conn m，经过 NAT 逻辑时被发现 oif 发生改变，m 被销毁，x 被丢弃；
• 连接 A 重传 x 经过 conntrack 逻辑，查不到 conn，新建 NEW conn；
• conntrack 逻辑新建无 MASQ 的 NEW conn m2：[192.168.56.100:1195 - 10.0.0.100:123, R 10.0.0.100:123 - 192.168.56.100:1195];
• x 经 default gw 发出后失踪；
• tun0 应用恢复，tun0 地址恢复，路由恢复；
• 绑定于 m2 的连接 A 重传报文 x 恢复至 tun0 发出，但非 NEW 状态，无法匹配 iptables MASQ 规则；
• 重传报文 x 未经 MASQ 地址转换到达 10.0.0.100:123，携带 192.168.56.100 源，找不到 socket，回 RST；
• 连接 A 被 RST；

也就是说，经过 tun0 的 TCP 连接，当 tun0 应用崩溃并恢复后，TCP 无法恢复。

要解决这个问题，两个方法：

• 在 tun0 应用恢复后，conntrack -F 刷一下 conntrack 表，但时序很难控制，既要在路由生效前，又要在欲恢复连接发送最后一个报文后；
• 用显式 SNAT 替换 MASQ，即 manual 建议那般；

当然，还有一个方法，在 nf_nat_ipv4_fn 函数中将 nf_nat_oif_changed 约束干掉，或在后者中排除对 TCP 的约束。这个修改的合理性存在争议，但 TCP 连接在这情况下被丢弃是合理的：

问题是谁来负责这事，即丢弃 TCP 连接的事情到底应该由 MASQ 负责还是 TCP 自身负责。

但无论如何，MASQ 规则还是因为比 SNAT 更简单而被广泛使用，代价就是遇到上述问题时要折腾好久去排除，只有包括我在内不多见的老师傅对 Netfilter 各模块细节都精细掌握，才能一眼看出问题所在。

AI 最近几年的发展让所有人兴奋，但千万别让这股激情成了又一个手里拿把锤子看什么都是钉子的故事。总有人会说本文描述的这类问题问 AI 就能搞定，其实 AI 真不适合这种非百科类问题。

下面看看它们的胡说八道，原回答太长，好几千字，全在一本正经扯淡，我只截图相关的部分举例：

这种问题看 AI 的一本正经的长篇大论只能让你越来越迷糊，浪费大量时间和精力继续追问，最后纯被 AI 耍得团团转。

AI 擅长百科类知识，同时擅长在你已知且精通的领域针对一些尚无解的问题帮你拓展一些思路，AI 非常不擅长本文描述的这种有解但并不普遍的冷门问题，稀有问题不足以形成有效的训练样本。

AI 虽好，但它不是万能的，AI 能快速搞定常见的范式编程问题，哪怕写一个极其复杂的逻辑，只要范式化，AI 都非常擅长，但这并不意味着它能正确回答该过程中的疑问，特别是冷门疑问。AI 特别擅长组织逻辑和语言，让你觉得它缜密到无懈可击，认为它是对的，这恰恰说明逻辑和语言本身就是一个大范式，正如它名字所展示，大语言模型。

略带讽刺的是，理工人往往看不起文科，认为文史哲只是遣词造句，可大语言模型本身却出自理工背景，它擅长的恰恰是理工人看不起的遣词造句，所以 AI 特别擅长写诗，写散文这类本没有对错的文科之能。

不是 AI 不会本文描述的问题，而是它没见过，但即使它没见过，它也要发挥它遣词造句的能力，长篇大论显得它很精通，因此很容易引起误导，特别是你在学习一个新领域，无力辨别真伪的时候。

再碰到这种 Linux 网络，TCP/IP 设计细节，传输协议优化等问题，直接问我就可以了，比 AI 好使。当然，你们对这类问题感兴趣的概率也不高，不然就成了常见范式，AI 也就自然擅长了。

我已将正确答案告诉 AI，我会经常这么做，希望它接受更多正确样本变得越来越正确可用，而不只是夸夸其谈，抑扬顿挫：

话还是有点多。

浙江温州皮鞋湿，下雨进水不会胖。