Ubuntu 18.04重启后NAT转发数分钟失效的排查求助

各位好，我遇到一个非常棘手的问题：2023年5月5日早上，我的Ubuntu 18.04服务器上的LAN突然无法正常访问外网了——所有客户端都被限制在外，因为主服务器的iptables FORWARD规则好像被莫名其妙地忽略了。

服务器刚重启的那1-2分钟一切正常，之后就彻底失效。我确认最近没有安装任何新软件，这个NAT转发配置已经稳定运行了10年，也绝对没有修改过防火墙规则。现在我怀疑是重启后某个进程启动干扰了规则，但完全不知道该从哪里入手排查（真心希望不是被黑客入侵了）。

当前iptables NAT表状态 #

我截取了失效后的iptables统计信息，可以看到PREROUTING、INPUT、POSTROUTING链一开始都有数据包通过，但之后计数器就完全停住了——除了INPUT链，其他链再也没有新的数据包进来：

Chain PREROUTING (policy ACCEPT 642 packets, 43832 bytes)
pkts    bytes target     prot opt in     out     source               destination
208    13747 LOG        all  --  *      *       192.168.3.183        0.0.0.0/0            LOG flags 0 level 4

Chain INPUT (policy ACCEPT 825 packets, 51359 bytes)
pkts    bytes target     prot opt in     out     source               destination
189     9873 LOG        all  --  *      *       192.168.0.18        0.0.0.0/0            LOG flags 0 level 4

Chain OUTPUT (policy ACCEPT 120 packets, 13320 bytes)
pkts    bytes target     prot opt in     out     source               destination
0        0 LOG        all  --  *      *       192.168.0.18        0.0.0.0/0            LOG flags 0 level 4

Chain POSTROUTING (policy ACCEPT 89 packets, 8970 bytes)
pkts    bytes target     prot opt in     out     source               destination
153    10268 LOG        all  --  *      *       192.168.0.18        0.0.0.0/0            LOG flags 0 level 4
153    10268 SNAT       all  --  *      eno1    192.168.0.18        0.0.0.0/0            to:10.0.0.2

我最关注的是POSTROUTING链里的SNAT规则，它一开始处理了153个包，对应我的Windows客户端当时能短暂访问外网，说明重启初期网络配置是完全正常的。另外我还尝试添加了MASQUERADE规则，但因为SNAT优先级更高，它并没有生效，只是死马当活马医的尝试。

已完成的排查工作 #

• 确认IP转发功能正常：

  $ sudo sysctl net.ipv4.ip_forward
  net.ipv4.ip_forward = 1
  

• 确认bridge-nf-call-iptables参数配置正确：

  $ sysctl net.bridge.bridge-nf-call-iptables
  net.bridge.bridge-nf-call-iptables = 1
  

• 检查conntrack状态，只发现一条UNREPLIED的UDP记录，暂时不确定是否和问题相关：

  udp      17 16 src=192.168.0.18 dst=75.75.75.75 sport=56804 dport=53 ...
  ... [UNREPLIED] src=75.75.75.75 dst=192.168.0.18 sport=53 dport=56804 mark=0 use=1
  

• 服务器上有通过snap安装的Docker，虽然守护进程在运行，但当前iptables里没有常见的DOCKER规则链，只有一个未被引用的DOCKER-USER链：

  Chain DOCKER-USER (0 references)
  pkts      bytes target     prot opt in     out     source               destination
  0        0 early_forward  all  --  *      *       0.0.0.0/0            0.0.0.0/0
  

• 局域网内部通信完全正常，客户端和服务器、客户端之间都能正常交互。
• 核对了网卡地址和路由表，配置和之前完全一致：
  网卡地址：

  $ ip -4 -br address
  lo               UNKNOWN        127.0.0.1/8
  eno1             UP             x.x.x.x/30 192.168.1.1/24 10.1.10.2/24
  eno2             UP             192.168.0.45/24 192.168.2.1/24 192.168.3.1/24 172.16.1.1/24 10.0.2.10/24 10.0.3.10/24
  docker0          DOWN           172.17.0.1/16
  

  路由表：

  $ ip route
  default via 96.67.192.226 dev eno1 proto static
  10.0.2.0/24 dev eno2 proto kernel scope link src 10.0.2.10
  10.0.3.0/24 dev eno2 proto kernel scope link src 10.0.3.10
  10.1.10.0/24 dev eno1 proto kernel scope link src 10.1.10.2
  x.x.x.x/30 dev eno1 proto kernel scope link src x.x.x.x
  172.16.1.0/24 dev eno2 proto kernel scope link src 172.16.1.1
  172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
  192.168.0.0/24 dev eno2 proto kernel scope link src 192.168.0.45
  192.168.1.0/24 dev eno1 proto kernel scope link src 192.168.1.1
  192.168.2.0/24 dev eno2 proto kernel scope link src 192.168.2.1
  192.168.3.0/24 dev eno2 proto kernel scope link src 192.168.3.1
  

  注：x.x.x.x是公网静态IP。

最终解决办法 #

折腾了半天实在找不到根源，我最终采取的解决办法是升级到Ubuntu 20.04（接下来会继续升级到22.04）。直到现在我还是搞不懂为什么18.04的iptables会突然出现这种诡异的问题，但升级后目前一切正常。

备注：内容来源于stack exchange，提问作者Alexis Wilke