两次登录检查不等于双因素：VPN 与 RADIUS

在 VPN 网关上再加一个认证后端，感觉像是加了第二个因素。它通常只是增加了第二次检查，而这是另一种对象，失败模式也不同。两者是否都必须成功、各自证明了什么、其中一个不可用时会发生什么，是三个独立的决定。弄错的话，网关在演示时更严格，在故障时却更脆弱。

第二个后端到底证明了什么

本地账户查询证明某个名称存在于数据库中，并且某个密码与之匹配。RADIUS 交换则证明 RADIUS 服务器 为收到的属性返回了 Access-Accept。这两种说法都没有提到因素类型，因为 两者验证的都是知识。而 NIST 的数字身份指南 统计的是不同的因素类型及其认证器，而不是服务器或提示。

有一种合法的设计让两个系统都参与。中央服务可以认证这个人，而网关独立检查该账户是否有权使用这条隧道。这是与认证并列的授权，把它称为双因素会把策略检查与持有证明混为一谈。

当 RADIUS 位于能验证某一因素的东西之前时，它可以承载真正的第二因素，例如推送批准或硬件令牌。信封不会告诉你用户出示了哪些认证器，所以要读后端策略，而不是网关的标签。

AND、OR 与回退是三种不同的产品

在比较实现之前，先确定你的需求里“两者”是什么意思。AND 策略要求每个具名检查都通过，OR 策略接受任意一个成功，回退策略只在声明的失败条件下尝试第二个。这三者在故障时的行为截然相反，而通常只有一个是审查真正想要的。

在配置界面上添加两个后端条目，并不能揭示产品实现的是哪种策略。有些网关按顺序串联插件并在第一次拒绝时停止，只有每个插件都必需时这才是 AND。另一些把本地账户当作覆盖，从而把中心故障变成绕过。可靠的答案是针对你部署的构建，为每条路径运行一个有记录的否定测试。

回退最值得怀疑，因为它的存在就是为了在某物损坏时继续工作。只要 RADIUS 不可达就接受本地密码的回退，已经把中心策略变成了第二扇更弱的门。

OpenVPN 的双重检查是一个具体案例

社区版 OpenVPN 2.6 在两者都启用时，同时要求客户端证书和配置好的 auth-user-pass-verify 脚本。这是证书验证与凭据脚本之间有记录的 AND，确实是两次检查。但它仍然不自动等于两类因素，因为脚本可能只校验密码。

这种组合还把关联问题留在了开放状态。证书通常标识设备，而凭据标识人，默认流程中没有任何东西要求两者指向同一主体。先决定允许哪些配对，然后在验证脚本内部或后续授权步骤中强制执行该映射。

仅证书模式是一次检查，依赖一把可能受 PIN 保护也可能不受保护的密钥。只有当没有 PIN 就无法使用密钥时，PIN 才把同一份凭据变成知识加持有。把密钥以未加密形式留在磁盘上，就把第二部分降格为文件权限。

设备厂商自建管道，通常是在 Web 控制台后面放一个 PAM 模块或 RADIUS 插件。社区行为是双重检查长什么样的参照，而不是设备如何组合它们的说明。

在你的网关上检查这种组合

在信任控制台摘要之前先读配置。决定策略的几行是证书模式、凭据脚本和插件顺序。

grep -E 'verify-client-cert|auth-user-pass-verify|plugin' /etc/openvpn/server.conf
openssl x509 -in /etc/openvpn/pki/issued/client01.crt -noout -subject -serial
radtest alice 'wrong-password' 127.0.0.1 0 testing123

grep 显示是否要求证书以及之后运行哪个脚本，而顺序比名称暗示的更重要。证书转储给出网关将看到的身份，包括建立关联映射所需的 CN 和序列号。RADIUS 测试是否定情形：错误密码必须产生 Access-Reject，正确密码产生 Access-Accept。如果被拒绝的凭据仍然产生会话，那脚本根本不在认证路径上。

然后在实验实例上运行故障情形：停掉必需的后端，用有效凭据连接。预期结果是拒绝，其他任何情况都是没人记录过的回退策略。

把需求写成否定情形

可用的需求会点名证明、被允许出示这些证明的账户，以及验证器缺失时的结果。它还会说明设备身份与人员身份之间允许的配对。这比采购单上的产品名称更精确，而且可以测试。

验收应包含四种拒绝：不合格的本地账户、缺失的必需证明、无效的第二因素，以及不可达的必需后端。每次拒绝都需要一条能把它与其他拒绝区分开的日志行，否则下一次事件只能靠猜。记录每个决定是哪个组件做出的，因为网关、RADIUS 服务器和目录会互相推责。

在任何插件或固件变更之后重新运行这四种拒绝。它们成本很低，而它们所保护的策略正是攻击者最先探查的部分。