一位用户无法登录 VPN：按顺序诊断

当一个人连不上而团队其他成员照常工作时，有用的问法不是哪里坏了，而是哪一层没有对上。登录是一条链：客户端启动，网关应答，身份被声明，第二因素被满足，策略被评估，然后流量才开始通过。这条链上任何一处断裂，传到您这里都是用户口中同样的一句话，所以第一件事是找出真正失败的一环。

把报告当作起点，而不是诊断。下面的检查由最省事的开始，每一项都写成一旦失败就结束调查。

锁定阶段与时间点

在动任何配置之前，先记下四件事：客户端及其版本、屏幕上出现的原话、尝试的分钟数，以及当事人所在的网络。原话承载真实信息，因为凭据被拒绝、网关不应答，以及登录已完成却仍打不开内部页面，是三个不同负责人处理的不同问题。注意客户端有没有产生本地日志行，因为从未发出数据包的客户端，对服务端检索没有任何贡献。记下时间点之后，后面的每一次查询都是查找，而不是大海捞针。

此时不要再猜密码。在账户有重试上限的地方，一串快速尝试可能把它锁死，在真实故障之上再添一个人为故障。记录已经尝试了多少次，以免之后把锁定误当成新的症状。被锁的账户还让您无法区分密码错误与策略拒绝，因为两者都以拒绝的形式出现。

读取那一次尝试的身份事件

请管理员调出与您记下的分钟数相符的认证记录。在 Windows NPS 部署中，Microsoft 的NPS 故障排除指南记录了拒绝事件 6273 及其附带的理由代码，这通常能把未知用户、错误凭据、策略不匹配和因无关原因挂断的呼叫分开。

空结果同样是信息。如果什么都没到达身份服务，这次尝试更早就死了：配置文件里过期的网关地址、客户端够不到的监听端口，或在配置文件仍存活期间被下线的服务器。如果记录存在并报告成功，凭据就不是问题，争论转向授权或网关之后的路由。这两种结果指向相反的方向，所以必须在任何人重装客户端之前先做日志检索。

把理由代码留在工单里。这一个字段就把下一次出现变成五分钟的查找，而不是重复调查。再配上客户端版本，因为只在一个版本上出现的代码，与在每个版本上都出现的代码，是完全不同的话题。

在策略允许范围内，每次只改一个条件

诱人的做法是一口气重装客户端、重置密码、把笔记本换到另一个网络。那有时能修好症状，却总是毁掉证据。改为只做一次获准的替换：同一个人换到第二台已登记设备，或在同一台设备上使用已批准的测试身份。每次替换只回答一个问题，所以成功会把故障收窄到您改动的那一侧，而不是怪罪整个 VPN。

不要借用同事的凭据来做这个比较。通过受支持的流程使用测试身份，绝不要复制设备密钥，也不要因为更快就跳过登记。在策略完全禁止替换的地方，那项限制本身就是被测系统的一部分，应当写进记录，而不是绕开。

在原路径上确认修复

找到断裂的一环后，只修那一环，然后重复原来的尝试：同一个人、同一台设备、同一个网络、同一个应用。从管理 VLAN 连上的测试账号只能证明网关还活着，完全不能证明用户周二早上的情况。请用户做失败的那个动作，而不是更简单的动作，因为 ping 成功说明不了被拒绝的文件共享。

用工单记录排除了什么、改动了什么。这条记录，就是一次性的救火与下一位值班工程师可以复用的东西之间的差别。