老毛子路由器踩坑：取消网络禁用后服务器仍无法联网|颂灬灬

〇、前言

前几天，我在老毛子（Padavan）路由器的网络地图里，禁用了一台 Ubuntu 服务器的网络连接。

禁用之后，服务器似乎还能联网，我就没有继续关注。一天多以后，才发现服务器的 Tailscale 连不上了。

排查之前，我已经在路由器页面取消了对服务器的禁用，但网络仍然没有恢复。最后发现，管理页面显示的状态和路由器实际生效的防火墙规则并不一致。

一、故障现象

服务器出现了几个看起来有些矛盾的现象：

可以通过局域网 SSH 登录服务器。
执行 curl 能访问部分网络地址。
ping 公网地址得不到回应。
Tailscale 无法正常连接。

一开始，我以为服务器能够出站，只是入站连接有问题。继续检查才发现：服务器不经过代理时，连公网都访问不了。

二、排查过程

2.1 检查局域网和公网连接

首先检查服务器的网络配置和默认网关。服务器可以 ping 通路由器，通过局域网 SSH 连接也正常。

随后测试公网访问：发往公网的报文能够到达路由器，但直接连接多个公网地址时均超时。

这说明服务器与路由器之间的局域网通信至少部分正常，问题需要继续从路由器转发和公网访问路径上查找。

2.2 检查代理对测试结果的影响

接下来发现，服务器终端中设置了 HTTP 代理。之前 curl 能成功，是因为请求默认走了代理；Tailscale 后台服务则没有继承终端中的代理环境变量。

要测试 curl 是否能够直接连接，可以使用 --noproxy 显式绕过代理：

curl --noproxy '*' -I --connect-timeout 8 \
  https://controlplane.tailscale.com/derpmap/default

故障期间，这条命令连接超时。之前 curl 的成功结果，掩盖了服务器无法直接访问公网的问题。

排查时，我曾临时给 Tailscale 服务配置代理，以验证它能否连接协调服务器。测试完成后，这个临时配置已经移除。

2.3 检查路由器实际生效的规则

想到之前在网络地图中禁用过这台服务器，我开始检查 Padavan 的访问控制。

在路由器管理页面的 防火墙 → MAC 访问控制中，当前为拒绝模式，但名单显示为空。按照页面上的状态，服务器似乎已经不再被禁止。

接着进入 系统管理 → 控制台，查看路由器实际生效的规则：

iptables -nvL maclist --line-numbers
ip6tables -nvL maclist --line-numbers

结果发现，IPv4 和 IPv6 的 maclist 链中，仍然各有一条针对服务器网卡 MAC 地址的 DROP 规则，而且规则都有大量命中计数。

这就找到了问题：页面显示名单为空，但运行中的防火墙规则仍在丢弃服务器的转发流量。

三、处理与验证

3.1 删除残留的封禁规则

确认规则对应的是服务器，并且管理页面中已经取消禁用后，只删除了这两条残留规则。

下面的命令记录了处理方式。执行前，需要将变量替换成实际服务器的 MAC 地址，并确认规则内容完全匹配：

SERVER_MAC='替换为服务器的MAC地址'

iptables -D maclist -m mac --mac-source "$SERVER_MAC" -j DROP
ip6tables -D maclist -m mac --mac-source "$SERVER_MAC" -j DROP

删除后，再次查看两条链，确认对应规则已经不存在。

如果实际规则中还有时间、接口等匹配条件，删除命令也需要与实际规则相符。不要为了省事直接清空 maclist 或整个防火墙。

3.2 验证网络恢复

删除规则后，服务器的公网访问立即恢复：

公网地址可以 ping 通。
不经过 HTTP 代理访问 Tailscale 协调服务器，返回 HTTP 200。
Tailscale 网络检测显示 UDP 可用。
与一台 Tailscale 设备成功建立直连。
与另一台设备通信成功，该次测试使用了 Tailscale 的 DERP 中继。

DERP 是 Tailscale 用于设备通信的中继方式，和终端中配置的 HTTP 代理不是同一个东西。验证时，Tailscale 服务没有配置之前临时使用的 HTTP 代理。

四、总结

这次排查中，有三个容易误判的地方：

能通过局域网 SSH 登录，不代表服务器能访问公网。
curl 能成功，不代表请求一定是直连；需要检查代理环境变量。
路由器页面显示已取消禁用，不代表运行中的防火墙规则一定已经同步。

这次可以确认的直接原因，是针对服务器 MAC 地址的封禁规则仍在实际防火墙中生效。删除规则后，服务器的无代理出网和 Tailscale 通信随即恢复。

至于为什么禁用后没有立即表现出故障，以及为什么取消禁用后规则仍然残留，目前没有足够证据确定具体机制。这次也没有重启路由器验证规则重建后的状态。