Linux 发行版的防火墙可能拦截你的 VPN 流量

两个过滤管理器、一套规则，以及一条落错区域的隧道。在添加任何规则之前，先确认归属和方向。

隧道已经建立，日志显示已连接，可某个应用仍然什么也访问不到。在 Linux 客户端上，这通常说明发行版的防火墙正在过滤一条 VPN 客户端从未管理过的路径。两个管理器可能同时生效，它们对接口、区域和流量方向各有各的想法。在改动任何东西之前先确认归属，比反复试规则直到碰巧生效要快。

找到管理器和后端

从实际加载的东西入手，而不是从已安装的东西入手。一个发行版可能同时提供 firewalld、ufw 和一个普通的 nftables 服务，而只有其中一个拥有正在运行的规则集。这些软件包和平共处，通过错误前端写入的规则永远到不了内核。先读取活动的服务，再读取它生成的规则集。

后端和前端同样重要。firewalld 的安装可能驱动 nftables，也可能驱动旧的 iptables 后端，取决于版本和配置，两者产生的检查输出并不相同。在把你的系统和任何指南对比之前，先把发行版、版本和后端写进工单。

让方向和接口对应起来

客户端的出站请求、入站的监听进程和被转发的数据包经过不同的钩子，针对其中一种的规则并不覆盖其他几种。允许本地 LAN 的区域往往不包含隧道接口或 VPN 地址池。隧道接口通常落在默认区域，而默认区域常常比物理网卡所在的区域更严格。这种错位正是局域网内浏览正常、隧道一建立就中断的原因。

在选规则之前先问清哪个方向失败了。无法向外连接的应用需要出站路径，而入站服务需要隧道接口上的入站路径。把规则加到错误的链上，只会在表面上生效，实际上什么也没做。

让规则的归属方保持一致

VPN 客户端的钩子、容器运行时和发行版的服务都能修改网络，而且它们彼此并不协调。手工写入的规则会在下次重载时消失，塞进管理器链里的规则可能按你并不期望的顺序被求值。要使用管理器的持久配置，并检查生成的规则集，而不是你写下的那个文件。仅仅因为一个服务不可达就关掉整个防火墙，是用小问题换大问题。

窄口径计数器是找出被拒绝流量的低成本办法。只限定一个目的地址和一个端口的日志规则，能在不抓取他人流量的前提下说明丢包是否发生在本地。调查结束后要删掉这条日志规则，因为它只是诊断手段而不是策略，而 firewalld 的区域文档 说明了接口和服务如何组合。

在不失去封锁的前提下验证修复

用拥有它的管理器检查已生效的状态，命令要与你记录的后端相符。下面的清单假设由 firewalld 负责；请换成 nftables 或 ufw 的等价命令，而不是把它们全都跑一遍。在同一个会话里混用工具，正是机器最后留下两套相互冲突规则的原因。

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=trusted --list-all
sudo nft list ruleset | head -40

第一条命令列出区域以及分配给它们的接口，可以看出隧道实际落在哪里。第二条打印某个区域的规则和服务，这样你能看到 VPN 接口到底有没有被覆盖。nftables 列表是所用后端的基准事实，只存在于配置文件里的规则不会出现在那里。把三份输出跟你添加的规则对照，不一致之处通常会自己报出名字。

然后重放最初的请求和你要求的行为。如果同一改动去掉了客户端的封锁，只是网站重新能打开还不够，所以也要测试一条未受保护的路径。记录管理器、后端、接口和这条规则的用途，否则一次让第二个管理器复活的软件包更新会把这一团乱麻重新搭起来。

相关文章