Firebird 3 的线路加密与 VPN 是两道边界

VPN 连上了，客户端打开了会话，于是所有人都以为数据库连接已经安全。这里其实混了三件不同的事。监听器究竟能否被访问、服务器是否接受了该用户、Firebird 是否谈成了线路加密，是彼此独立的机制，证据也各不相同。隧道只回答第一个问题，而且只针对你放行的来源。

两道边界，彼此并不重叠

VPN 边界保护客户端与网关之间的数据包。Firebird 的线路加密保护客户端库与服务器进程之间的数据库协议。两者可以同时存在，但谁也替代不了谁。

如果隧道在数据库主机之前就终止了，那么隧道之后的流量只由数据库会话谈成的条件来保护。审查往往就在这个缺口里发现意外。隧道示意图止于网关，而承载查询的连接要继续穿过它。后来读到这张图的人，会把这个假设一并继承下来。

第一道边界：谁能打开监听器

确认真正的服务器地址和配置端口（若未修改则为 3050），然后只在主机防火墙和网络防火墙上放行获批的 VPN 来源。要考虑 VPN 网关上的地址转换，如果网关是独立设备，还要给数据库主机一条返回客户端池的路由。

然后证伪。本应被拒绝的外部路径必须仍然被拒绝，因为打开隧道本身并不限制 Firebird 监听器。

第二道边界：Firebird 谈成了什么

Firebird 3 引入了线路加密框架，其服务器策略可以设为禁用、启用或强制。策略只设定下限。实际会话仍取决于应用加载的客户端库，以及双方都支持的插件。

Firebird 3 的发行说明中，Arc4 被列为该版本的默认线路加密插件。Arc4 是历史上的默认值，并不是对现代密码算法的推荐，也与外层的 VPN 保护不是一回事。

身份验证是同一场协商中的第三个变量。服务器接受一组身份验证插件，客户端库提供其中一个子集，两者必须有交集。

Legacy_Auth 的陷阱

要支持 Legacy_Auth，就得放宽服务器默认的强制加密策略。这就是有据可查的兼容性代价，也正因如此，为了压住一条连接错误而下调策略属于安全变更，而不是修复。

如果客户端在服务器升级后突然失败，先比较插件列表，再决定削弱什么。失败通常是协商不匹配，答案则是双方都支持的插件。

检查真正重要的那个连接

在提供该上下文变量的构建上，这条查询会报告当前连接的加密状态：

SELECT RDB$GET_CONTEXT('SYSTEM', 'WIRE_ENCRYPTED')
FROM RDB$DATABASE;

请通过应用自身的连接来执行，而不是通过同一台服务器上的管理员会话。加密的管理员连接说明不了另一个客户端库的会话，而不支持该变量的旧版本也不能证明加密是关着的。

把客户端库版本、服务器构建和结果一起记录下来，因为单看其中任何一项都读不出结论。

授权与升级路径

限制来源、加密传输，都不能取代身份验证或最小权限授权。要检查普通数据库用户在其真正触及的对象上拥有哪些权限。

最后，把长期运行的系统当作维护问题来看。隧道并不能让过时的客户端库永远安全，而一条受支持的升级路径，比后来发现它需要的插件已被移除要便宜。