MFA 服务中断：提前决定 VPN 准入

VPN 准入停在这里，而告警说第二因子服务不可达。是否还有人能连上，是一个本该在故障之前就回答的政策问题，而不是在故障当中。验证器不可用，不是某个因子已通过的证据；被拒绝的挑战与不可达的挑战也不是同一件事。下面的运行手册把这一区分变成可以测试的书面规则。

第 1 步：分别命名三种结果

写下三种状态，并拒绝把它们混为一谈：主认证失败；第二因子挑战被拒绝或超时；MFA 服务从未应答。三者各有不同的负责人、不同的日志行和不同的正确处置。一条笼统的超时提示会掩盖你处在哪一种状态，而正是这种含糊让一次故障变成一场争论。趁还没需要，先在手册里给这些状态命名。

拒绝意味着验证器给出答复并说了不，这是政策结果，而不是可用性问题。尝试过期意味着挑战确实存在，但没有人在时限内完成它。服务不可达意味着问题根本没有得到回答。只有第三种才是故障。

第 2 步：读取代理实际使用的失败模式

找到在无法联系服务时决定行为的那个设置，并从运行中的配置读取，而不是从模板读取。在 Duo 的 RADIUS 代理中，有文档记录的 failmode 取值是 safe 和 secure：safe 只在主认证成功时允许尝试，secure 在该条件下拒绝尝试。

radtest alice '' 127.0.0.1 0 testing123
journalctl -u duo-authproxy -n 50 --no-pager

safe 这个名字描述的是一种可用性取舍，而不是保证每个被放行的会话都有一次新鲜的第二因子。这句话应当写进风险登记册，因为这正是该设置所做的交换。不要把该值推广到其他供应商、其他集成或其他代理模式；要读那个产品自己的文档，找它自己的对应项。在没有这层理解的情况下从厂商示例里复制配置，就是在等下一次故障时给你一个惊喜。

如果没人能说清当前生效的是哪种模式，就停下来。手册余下的部分都取决于这个答案。

第 3 步：让重试与流程匹配

让网关的超时与重试行为与它所驱动的认证流程对齐。不协调的重试会产生多条提示、打乱尝试匹配，并让日志无法说明哪个结果属于哪次登录。极长的超时不是可用性设计，而是对同一个答案更久的等待。

ss -lunp 'sport = :1812'
tail -n 50 /var/log/duo/authproxy.log

代理自身的请求超时是另一条界线：一个已发出却永远不完成的认证请求会被拒绝，而这种拒绝不是可以退回去的故障。把拒绝、未完成的挑战和不可达的服务当作决策表里三种不同的输入。然后把表写明确：哪种状态放行、哪种状态挂起、哪种状态升级给人。

如果两个组件都在重试，先修正重试的归属。重复提示是归属有两个的症状，而不是服务太慢。

第 4 步：单独治理应急访问

如果需要应急访问，就给它单独的范围、身份、授权和审计留痕。悄悄对所有用户关闭 MFA 不是应急程序，而是一次带着事故的永久削弱。安全负责人要事先批准准入规则、可见性和升级路径。

grep -R failmode /etc/duo /etc/radiusclient 2>/dev/null
systemctl status duo-authproxy

在非生产环境中测试整张矩阵：主认证失败、故意拒绝、挑战过期和服务不可用。对每一种，记录准入结果以及被记入日志的理由。不要为了弄清已配置的行为而制造生产故障，也不要在它本就是为之而写的那次事故中第一次测试应急路径。从未跑过的恢复流程只是一份文档，而不是控制措施。

当三种状态被命名、失败模式从运行中的系统读出、重试只有一个归属、应急访问有自己的批准与复核时，手册才算结束。可预期的执行加上已知的恢复路径，才是值得写下来的结果。