UFW 说它找不到匹配 OpenSSH 的配置文件,而查找原因的思路直接指向 SSH 服务器。这个方向错了:这条消息说的是一个命名的防火墙定义,并没有说明 sshd 是否已安装、正在运行或正在监听。UFW 应用配置文件就是一份带名字的端口和协议清单。读一下定义只需一条命令,通常就能结束排查。

步骤 1:列出 UFW 真正认识的名称

在请防火墙允许某个名称之前,先问它有哪些名称。这份清单来自本机安装的配置文件,所以缺少某个名称是关于这台系统的事实,而不是关于你试图保护的软件。如果名称存在,错误就来自拼写错误或 shell 历史里的旧别名。

ufw app list
ufw app info OpenSSH

默认安装下清单很短,这些名称也不是软件包名。即使已安装 openssh-server 软件包,名为 OpenSSH 的配置也可能不存在,反过来同样可能。请使用清单打印出的确切名称;拼写相近的 VPN 配置名或桌面启动器不是 UFW 应用配置。如果你要的名称不存在,这就是结论,下一步是看应该由什么来提供它。

步骤 2:读定义,而不是读标签

配置文件是 /etc/ufw/applications.d 下的一种 INI 风格文件,包含名称、标题、描述和端口字段。端口字段可以列出多个端口和传输方式,所以标签告诉你的信息比定义少。UFW 手册记录了这些字段以及更新应用的操作。请读文件,而不是假定这个名称只代表一个熟悉的端口。

cat /etc/ufw/applications.d/openssh-server
ufw app info OpenSSH

包含 22/tcp 的定义描述的是 TCP 端口 22,仅此而已。它不能证明本机的守护进程正在那里监听,也不覆盖你后来添加的第二个端口。如果守护进程在别处运行,即使名字与产品相符,这个配置也是错误的放行。在允许其中任何一个之前,先把监听者与定义对照一遍。

ss -ltnp 'sport = :22'

如果定义与监听者不一致,就停下来。放行一个点名了无人监听端口的配置,只会造出一条看起来有进展、实际什么都没保护的规则。

步骤 3:把配置与正在运行的服务分开

放行一个命名配置并不会安装、启动或配置该服务,而正在运行的服务也不需要打包的配置才能被访问。这是不同工具各自负责的独立决定:软件包管理器、服务管理器和防火墙。把它们当成一回事,正是人们为了显示一个符号名字而安装多余服务器的方式。

对 VPN 服务器来说,放行外层监听者之后,分离仍要继续。放行加密传输端口并不会启用内核转发,不会添加 NAT 规则,也不会让隧道用户访问 LAN。每一条都是需要单独审阅的独立策略。以 VPN 产品命名的配置只描述它列出的端口,服务器配置的其余部分仍然要你自己写。

如果配置不存在而你确实需要一个,经过审阅的显式端口规则或 applications.d 下的本地配置都算正当做法。安装一个你并不想要的软件包则不算。

步骤 4:重新加载防火墙之前留好退路

改动任何规则之前,先确认你有第二条进入机器的路径:控制台、带外地址或计划好的回滚。然后读规则集和默认策略,因为默认拒绝加上没有 SSH 规则,正是测试时把自己锁在门外的经典方式。一次只改一条规则,并读 UFW 打印的确认信息。保存的规则、生效的规则和可达的服务是三种不同的观察。

ufw status verbose
ufw allow 22/tcp
ufw app update OpenSSH

改动之后,测试被放行的连接,以及一条仍应被拒绝的路径。拒绝测试和放行测试同样重要,因为范围超出本意的规则会通过第一个测试、在第二个测试上失败。记录配置名称、它包含的端口以及你核对过的监听者。

当名称存在或被有意替换、定义与真实监听者相符、服务被单独管理,并且你在手边留有恢复路径的情况下同时测试了放行与拒绝两条路径,这份检查清单才算结束。清单里有个名字,并不等于以上任何一条。

相关文章