被 VPN 重试循环锁在门外：先停掉客户端

凌晨 02:40，账户被锁定，而键盘前一个人也没有。搁在架子上的某个客户端一直在提交它上个月保存的密码，网关一直拒绝，锁定背后的计数器在无人参与的情况下不断往上走。这是一次重试循环，而不是攻击；必须先让它停下来，账户才可能被恢复。

把它当成两个问题，按固定顺序处理。先停掉重发的那一端，再恢复访问，因为反过来做，几分钟内循环就会重新开始。

找出是哪个进程在提交失败

从身份系统里的时间戳入手，把它们和每一个持有该账户的客户端对照。一个受管理的配置文件、一个无人值守的服务、一部躺在抽屉里的手机、一台还存着旧凭据的备用笔记本，都可能以同一个人的身份通过认证。每隔几秒就失败一次的那个是循环，每天只失败一次的那个通常只是忘了密码的人。两者喂的是同一个计数器，而这正是陷阱所在。

查找的时候要区分「被拒绝」和「网关不可达」。超时、域名解析失败或端口关闭通常不会增加失败计数，而一次走完认证交换、返回凭据错误的请求会。把两者混在一起就会开出错误的药方，因为一个需要停掉客户端，另一个需要修好链路。

决定应对方式的三个条件

三个事实就能把它收窄到一个答案。第一，记录里显示的是明确拒绝还是传输故障。第二，这个身份是否跨设备、跨服务共用。第三，正在重试的客户端是你管理的，还是别人控制的。

来自你控制的单个客户端的明确拒绝，意味着停掉那个客户端、通过批准的途径解锁，然后做一次刻意的登录。共用身份则把答案推向重新分配凭据而不是解锁，因为另一台设备一重连，循环立刻就会继续。传输故障指向网络层，那里根本不是账户保护的问题。

这些分支没有一个涉及削弱保护。锁定阈值和速率限制之所以存在，是因为让你在故障期间恼火的同一个信号，也正是拖慢密码猜测尝试的信号。

解锁之前先停掉重发的那一端

停掉那个一直在认证的单元或连接，而且要停得能扛住重启。当它的服务被设成开机自动启动时，仅仅暂停客户端是不够的。

# which unit is presenting the credential?
journalctl -u openvpn-client@home --since '20 min ago' | grep -i 'auth\|error'

# stop it, and keep it stopped across reboots
sudo systemctl stop openvpn-client@home
sudo systemctl disable openvpn-client@home
systemctl is-active openvpn-client@home

等几分钟，确认失败计数不再变动。那段停顿就是你找对了源头的证据。如果失败还在继续，循环来自别处，解锁那一步就白做了。

只有到这时，才使用运营商文档里写的解锁或恢复流程，并且随后用你打算保留的那台设备做且只做一次受控登录。具体的阈值、冷却时间和恢复流程的措辞都因服务而异，所以要去读，而不是猜一个数字。

把原因去掉，让它不再回来

在凭据真正被保管的地方更新它：操作系统的密钥环、客户端配置文件，或者服务账户配置。从一个地方清掉、另一个地方还留着副本，循环就是这样在一周后回来的——通常是一台离线已久的笔记本重新上线，重放了它缓存的值。

给自动化流程它自己的身份。单独配发的账户，有自己的凭据和自己的限额，可以让一次机器故障不至于把某个人锁在邮箱之外，也让故障在日志里可归属。给客户端加上退避，让被拒绝的凭据停止重试而不是反复重试；并对反复出现的认证失败设置告警，这样下一次循环几分钟内就会被发现，而不是等到 02:40。

报告交到支持团队时，保留账户标识、时间戳和客户端名称。密码和恢复材料永远不该出现在这份记录里。