在不锁定所有设备的情况下轮换 VPN 密码

三台手机、一台路由器和一项监控检查仍在使用旧密码，其中一台每九十秒重连一次。账户密码十分钟前刚改过，因此这些客户端现在提交的都是服务器会拒绝的值。神话就在这时破裂：改密码只作用于账户，不作用于各设备上保存的旧值副本。接下来要做的，是那次改动没有完成的工作。

神话：一次改动，处处同时生效

人们相信改密码会让所有会话退出并强制重新登录。事实并非如此，因为服务器只记录最后接受过哪份凭据，而客户端保留着各自存下的内容。带有已保存密码的设备会按自己的计划重试，并悄无声息地失败，直到有人发现账户被锁定。一旦接受副本活在账户之外，轮换就不再像单一动作。

这一切都不构成反对轮换的理由。它主张把已保存的副本当成改动的一部分，而不是事后才想到的事。锁定通常来自并发重试：每台设备按自己的计划不断提交旧值，直到计数器触发。于是账户看起来像遭到攻击，其实只是被提供了无人替换的凭据。这个区别很重要，因为解决办法是一份设备清单，而不是更严格的锁定策略。

轮换之前先清点副本

在打开密码表单之前写清单。列出所有以此账户身份认证的客户端、脚本、自动化和托管配置文件：自己联网的手机、两年前配置的路由器、只在周一唤醒的笔记本，以及每分钟尝试一次的监控检查。对每一项，记下凭据存在哪里、改动期间能否接触到该设备、以及无法重连时有什么恢复途径。正是这份清单把有风险的改动变成有计划的改动，而且它必须在旧密码失效之前就存在。

离线设备是最经典的遗漏。抽屉里的笔记本三周后才出现，并在最糟的时刻出示过期的值。也要记下它的位置和计划，因为你得去追它，而不是等它。

在 Linux 机群里，搜索是机械的，不是聪明的。先找引用凭据文件的配置，再找凭据文件本身，因为要重写的正是第二份清单。对桌面客户端和手机重复同样的练习，那里存放的是配置或钥匙串条目，而不是路径。目标是能逐项处理的清单，而不是声称能找出每一份副本的扫描。

grep -rl auth-user-pass /etc/openvpn /etc/NetworkManager
grep -rl auth-user-pass ~/.config 2>/dev/null

把副本与拥有它们的人对照。没人认领的设备就是没人会去更新的设备，也最可能继续重试。

你真正在轮换的是哪个秘密

账户密码只是 VPN 部署中的一份凭据。密钥口令、证书身份和可选的同伴秘密各有自己的替换路径和所有者。改账户密码对有证书认证的设备毫无作用，重签证书对持有已保存密码的客户端也毫无作用。先为秘密命名，再为解决办法命名。

如果轮换是出于怀疑而不是政策，事件流程优先于便利计划。撤销证据要求撤销的内容，并接受设备清单上的额外工作。这个决定属于事件负责人，而不是碰巧拿着密码重置表单的人。

在保存值所在之处替换它

通过服务文档所载的机制更改凭据，然后更新已保存的副本，或在每台想保留的设备上走一次登录流程。不要在一个会重写它的管理器背后直接编辑生成的配置，因为管理器下次运行时会恢复旧值，编辑就变成延迟发生的故障。要更新管理器读取的源，或使用客户端自带的凭据库。无论如何，设备最终必须在客户端真正读取的位置拥有新值。

保存密码文件的客户端需要重写该文件，而会询问的客户端需要完成一次登录。NetworkManager 把秘密保存在连接配置里，所以改动通过 nmcli 而不是文本编辑器完成：

nmcli connection modify work vpn.secrets "password=NEW"
nmcli connection up work

读取凭据文件的配置是第三种情况。替换该文件的内容，保持其权限紧闭，并重新加载客户端，而不是编辑指向它的配置。配置没有变，变的只是它读取的秘密。

有意地把每台目标设备各重连一次，看看哪些失败。如果某台设备一直失败，先看它指向的账户和它读取的库，再改第二次密码，因为第二次改动会让需要更新的副本成倍增加。连续失败两次的设备通常指向了错误的账户，或读取了你还没找到的库。把它修好，再重连。

会话和令牌比密码活得更久

改密码并不能证明已有会话或独立证书被撤销。有些服务会让会话一直活到过期或被明确终止，已签发的令牌也有自己的生命周期。要检查服务的实际行为，而不是假定改动是全球性的。如果改动出于怀疑，就明确终止会话并确认结果。

NIST SP 800-63B 中的凭据生命周期指南把认证器和会话分成不同类别，所以改密码和全局注销是两种不同的操作。把它们当成有两套完成标准的两个任务。第一个在新值可用时完成，第二个在旧会话消失时完成。

记录完成情况，但不要把新密码写进记录。含有凭据的轮换日志是共享盘上等待发生的新事件。记下日期、已更新的设备和仍未完成的设备。