Sophos Firewall v23：进步、局限与待解问题

我已经在家庭实验室测试 Sophos Firewall v23 近两周。初步感受喜忧参半：我喜欢新版规则视图，也认为 REST API 是正确的方向。但界面仍像一个不同部分在不同年代开发的产品。换一张新表格，并不能让整个管理体验都现代化。

对我而言，这比新功能数量更重要。我希望清晰维护规则、自动处理重复任务，并在各个页面之间切换时，不必重新适应另一套交互方式。v23 有进步，但一些基本诉求仍未解决。这是我的第一份体验报告，也包含对较大变动的技术评价。

Sophos Firewall v23 目前处于 Early Access Program（EAP）。按照往年的发布节奏，我预计正式版会在 2026 年 12 月推出。我在家庭实验室测试固件近两周，尚未用于生产环境。易用性方面是我的亲身观察；HA 和 WAF 的性能数字来自 Sophos。

规则管理：更好的筛选器不能替代所有分组视图

新版规则视图是我在实验室里喜欢的变化之一。连续表格、可调整和固定的列、搜索与筛选，是不错的一步。把目标、服务和保护配置并排显示，比每次比较都打开几条规则更合理。始终显示设备身份与 HA 状态，也有助于管理时保持上下文。

不过，关于分组的争论可以理解。早期反馈批评新版没有复现熟悉的可折叠分组。规则很多时，即使有筛选，长表格仍可能不好浏览。这关系到安全管理，并非单纯的审美偏好。

Sophos 对规则管理的专项解释明确指出，既有分组与规则顺序保留，表格通过一列显示所属分组，目前两种视图可以切换。分组没有被删除。 新版只是换了展示方式。讨论中的标签式组织是可能的后续发展，并非当前构建版本已承诺的功能。

我喜欢新版，但也理解管理庞大规则集的管理员。面对数千条规则，筛选和显示尤其需要保持实际执行顺序清楚。分组并不是脱离全局顺序的独立安全边界。

近两周后，仍让我不满意的是界面不统一。不同页面的设计和功能不一致。克隆之类的操作，并非处处都按同样方式提供；响应式布局也不是每个部分都做得一样好。在配置页面间切换时尤其明显。

我期待类似任务采用类似操作方式。整理规则或创建多份相近配置需要一致的交互。一个做得好的视图，反而让其他地方的差异更突出。我希望 Sophos 跨越模块边界改进整个界面。

WebAdmin 使用 HTTP/2 是好事，但不能解决这些问题。它可能改善页面资源传输，尤其在高延迟连接上；不会改变交互逻辑，也不会自动缩短配置修改时间。本文没有提供受控的前后性能测量。

REST API：进步在于可验证的流程

我认为 REST API 是 v23 最有用的方向之一。不是每项重复管理任务都应该手动点击。API 密钥、OpenAPI 3.0 和内置指南，为自建工具提供基础。密钥、有效期及允许访问的 IP 主机在 Administration > API access 中管理。

对我而言，价值在于可控流程：读取当前状态，找出具体差异，针对性修改，再读取已保存的结果。这可能让跨站点重复操作更容易追踪。这是合理的应用场景，不是我已验证的多站点部署成果。

有 API 并不代表自动化就可靠。无法连接的站点必须显示为失败。重试不能生成重复对象，部分失败需要日志。这些才是我评价集成的标准。

密钥应该放在受控的自动化主机上，限制有效期与网络访问。交互指南能够发出真实请求，因此写入示例就是实际配置修改，需要和界面操作一样审核。

功能覆盖是否完整，仍是我关心的问题。只有具体构建的 OpenAPI 文件描述了全部所需操作，才能替换既有 XML 自动化。Sophos 仍明确把 WAF 变化对应到 XML API，说明应仔细核对。我的判断是方向正确，关键细节在覆盖范围、错误处理和权限。

WAF 更实用，但容量仍有限

Web Application Firewall 增加了按站点路径条目配置动作。这对发布应用有价值，也部分弥补了与 SG/UTM9 的差距。四种动作的安全含义不同：

重定向改变的是客户端目的地址，不是内部切换后端。WebSocket 例外也不是增加一道防护。受保护门户与 WebSocket 通道并存时，应明确决定各处如何检查。连接可用并不能证明流量经过了检查。

每个路径路由条目最多可组合 128 个路径。WAF 规则上限默认是 100 条，可提高至 200 条。指南称既有规则以 Protect 为默认动作迁移。明确支持的是界面与 XML API，并不自动意味着新版 REST API 已提供全部 WAF 流程。

另一项变化是 Apache Event MPM。Sophos 描述了更好的 worker 利用率与并发请求韧性。发布公告里的约 800 个并行请求，指旧架构可能饱和的情况，而不是通用旧上限，也不是新吞吐量保证。

新增路径动作是具体进步。性能承诺则应分开看：更好的队列仍可能让应用慢到不可用。响应时间、错误率和后端延迟，比接受的连接数量更重要。我没有提供同等负载下的 WAF 基准测试。配置更多规则不会让设备性能同比增长。

也不能把 WebAdmin 的 HTTP/2 当成 WAF 协议支持。所链接的 Reddit 讨论把 WAF 的 HTTP/2 当成未来需求。回复表达兴趣，但没有承诺。我不会将其写成 v23 功能，更不会扩展成 HTTP/3 保证。

高可用：300 毫秒不等于应用无中断

HA 变化是我特别感兴趣的部分。Sophos 称对端故障检测窗口从四秒缩短为 300 毫秒，由此给出约 13 倍更快的检测数字。

这个数字描述故障检测。 它不保证通话、VPN 或应用在 300 毫秒后恢复正常。剩余节点接管、邻接设备转发流量、已有会话如何处理，都影响结果。一个 ping 无法充分体现这些。

监控还纳入 SSD 等硬件。节点可能仍回应 HA 链路，但存储已经出问题。用硬件健康作为切换条件很合理。在健康节点上继续运行，并不能替代调查原因与更换故障部件。

HA 心跳通过独立于普通数据流量的路径优先处理，同样重要。Sophos 称优先级随负载调整，减少把心跳延迟误判为故障的风险。指南说的是明显减少漏心跳和意外切换，而非绝对免疫。

这些架构调整有道理。若集群高负载下无故切换，检测再快也帮助有限。生产验收必须同时看两者。我的实验室感受不构成已测量的 HA 中断时间，也不证明生产负载下的稳定性。

DNS 与补丁状态：两种不同的信任

DNS over HTTPS 加密到所选解析器的传输。DNSSEC 验证已签名 DNS 数据的签名链。二者互补：DoH 本身不认证回答真实性，DNSSEC 不隐藏查询。解析器仍知道所查询内容，也不是所有区域都有签名。

Sophos 描述了连接 Sophos 或通用提供商的 DoH，以及更容易启用 DNS Protection。这不意味着所有客户端自动走指定路径。浏览器自带 DoH、内部解析器和私有命名空间都需要规划。我关心内部与外部名称继续正确解析，并且过滤和 DNSSEC 验证决策可理解。

热修复视图不那么抢眼，但实用。Backup and Firmware 显示已应用的安全更新，包括 CVE、说明、日期、严重性和公告链接。指南还提及 Log Viewer、邮件通知与 Central Firewall Reporting。

因此，固件版本号不能完整说明补丁状态。一条热修复记录可帮助证明某项修正已应用；不能证明所有漏洞都修了，也不能证明以前易受攻击的设备从未被入侵。

Sophos Fusion 的周期固件计划增加分批部署与逐设备例外，大版本可选纳入。我倾向先用测试组，核对关键功能，再进入下一组。自动化减少手工劳动，不替代恢复计划。

DHCP、mDNS 与路由需要自己的验收

DHCP 移到新版 Control Plane。Sophos 描述更好的租约处理、更多预留、服务前的防洪泛检查与更多界面设置。这不是纯外观变化。租约、续租、预留和特殊选项都值得关注。网页能打开，不代表 PXE 或很少重启的专用设备拿到了正确配置。

mDNS 反射器可在选定 VLAN 或子网之间发现服务，同时支持 IPv4 和 IPv6，可选接口与服务。它不会自动允许后续数据连接。打印机可能可见，但因缺规则而无法打印。不能因为反射全部最方便，就让访客网络发现内部设备。这里需要反向验证禁止的情况。

Sophos 更新 FRR 并增加统一控制台。BGP 和静态路由的 BFD 明确为独立部署中的实验功能。它检测转发路径故障，不等于 HA 心跳。实验状态让我暂时不把它作为生产依赖。

IPv6 IPoE、含 IPIP/DS-Lite 的 4in6 隧道和理解 VNE 的 DDNS 扩充了连接方式，包括日本 Xpass。端点和 MTU/MSS 改进适用于提供商要求该模式的场景，不解决所有 IPv6 问题。IONOS Cloud 通过 Bring Your Own Image 部署官方镜像，无 Marketplace 条目，生命周期手工管理。

身份：更新固件不会提供全部前提

Entra ID 增强涉及 Sophos Endpoint 配合 Synchronized User ID，不只是给门户登录换名字。指南描述本地 AD 与 Entra 混合环境，通过 UPN 和 sAMAccountName 映射，Windows 支持从所述 Endpoint 2025.1 开始。仅有 Entra 不会提供这种识别。版本、许可和 SSO 配置必须匹配。

Google Workspace 被描述为 Captive Portal、VPN Portal、Sophos Connect 和 WebAdmin 的 OpenID Connect IdP，支持 IdP 强制 MFA。指南指出每组服务使用单一 IdP。认证与授权仍是两项检查：有效 Google 账户不能意外获得管理权限。

MFA 注册 QR 码可以邮件发送。新部署默认这样，既有和迁移部署保留门户方式。未使用码 24 小时后失效。注册码包含认证器的秘密，因此邮箱和重新注册流程都要保护。仅用邮件发送并不等于安全验证身份。

共享服务器方面，SATC 与 XDR Sensor 可与既有 Endpoint 或 AV 并行，让多个会话共用一个 IP 时仍按用户施策。部署前必须核对系统、许可和具体第三方组合。

Chromebook 扩展基于 Manifest V3，面向所有受支持 SFOS，并不是升级 v23 的独家理由。在共享设备上，我更关心退出和换用户后映射是否可靠结束。

AI 与 NDR：决策必须继续可见

Sophos Fusion 的 Firewall Assistant 第一阶段聚焦规则，读取配置并回答问题。刻意保留的例外是创建规则，默认禁用且放在表尾。审核和启用属于管理员。指南称它访问的数据与该管理员通过 Fusion SSO 所见一致。

我喜欢这个边界。草稿仍需核对对象、服务、用户、保护配置和位置。禁用规则已经是保存的配置变动。说得漂亮不是安全证明。

Generative AI 分类和应用过滤器支持 Sophos AI Defense 中批准服务的控制。允许一个域名不能决定哪些数据可放入提示词。网络控制不能完整检查每次上传，也不替代数据分类。额外服务、许可与能力需分别评估。

NDR Essentials 和 NDR Active Threat Intelligence 增加无需自动隔离或红色 Heartbeat 的告警，把可见性与立即封锁分开。这不表示所有 Active Threat Response 动作关闭。没有自动响应的告警需要负责人和升级处理路径。

较小变化包括邮件 Content Control Lists 用 ID 引用、后端 Web 分类定义版本化。虽少受关注，却可能影响更新与恢复时的配置一致性。

升级之前先迁移

最具约束力的变动不在 AI：Sophos 移除原生 eDirectory 服务器类型。v23 认证文档要求先迁移到受支持类型并删除旧配置，否则升级失败。

这是实际迁移项目。替代集成登录成功，不能证明自动识别、组映射及规则全部正确。使用目录 SSO 的人要单独验证映射。我会先完成身份切换再更新固件，以便定位后续问题。

EAP1 也是边界。支持走社区论坛；对我而言适合有恢复计划的受控测试。发布公告不等于批准我的关键基础设施使用它。

早期反馈究竟说明什么

EAP1 反馈讨论除规则批评外，还有 VMware 用户报告：从 22.0.1 升级后，ping 和 SSH 可达，但 30 分钟后 WebAdmin 仍不可用。搜索索引收录的后续回复中，同一用户称约 40 分钟后恢复。

这是单一报告，我没有复现原因。不能作为普遍 VMware 缺陷或正常耗时。它提醒关注管理访问、更新窗口和恢复。早期讨论变化快，后续回复与反例同样重要。

Reddit 发布讨论中的 WAF 问题也显示运维者仍关心的缺口。这是背景，不是基准测试或完整确认缺陷表。

近两周后的第一份结论

我喜欢 v23 的方向，但整体还不够统一。新版规则视图是好的一步，REST API 是可控自动化的正确方向。设计、功能和响应式布局仍有不符合现代管理预期的差异。

HA、WAF 和补丁透明度，比 AI 标签在技术上更重要。宣布的改进值得关注，但初步测试不替代负载对比或生产集群经验。厂商数据与具体环境验收仍决定结果。

我会继续在实验室测试。生产部署对我还太早。正式版前，我希望新版规则视图成为其他页面的标准：操作一致、不同窗口尺寸都能用、类似任务差异减少。这比发布清单再多一项孤立功能更有帮助。

下次见，
Joe

常见问题