Azure VPN Client：VPN 平台未触发连接

状态行提示 VPN 平台未触发连接，配置文件导入时毫无报错，网关对其他所有人也都正常。这条消息描述的是 Windows 内部的交接环节，而不是凭据被拒，因此有效的顺序应当从代价最小的状态改动走向破坏性最大的操作。重新导入配置文件只花一分钟，修复安装包需要重启一次，而重置会清掉机器上的所有配置文件。顺序弄反会毁掉你区分这些情形所需的证据。

重新导入、修复、重置：三种不同的代价

这三种操作不能互相替代，而且只有一种无需额外工作就能回退。重新导入会刷新配置文件，同时保留应用安装。修复会保留已导入的配置文件并重写安装包文件。重置则会连同应用状态一起删除配置文件，所以之后你要把一切重新导入一遍。

每当网关、地址池或身份验证方式发生变化，都应从重新下载的 azurevpnconfig.xml 开始。配置文件如果指向已删除的网关，产生的正是这条状态行；而客户端修复再怎么彻底，也修不好一个指向已不存在对象的文件。

在执行任何破坏性步骤之前，先确认应用被允许在后台运行：设置、应用、已安装的应用、Azure VPN Client、高级选项。被挂起的客户端无法完成平台交接。

RasMan 是客户端交接所指向的服务

远程访问连接管理器负责把客户端请求变成 Windows 连接。请在提权的命令提示符中先执行 net stop rasman，再执行 net start rasman 重启它，然后重新连接，再考虑改动其他设置。

如果连接恢复了，就把启动类型设好，让修复在重启之后依然有效：sc.exe config rasman start= delayed-auto。一个现在能跑、但开机时被禁用的服务，明天早上还会复现同样的故障。

要留意那种启动之后又自行停止的服务。这种模式指向依赖项或策略，而重启只能撑几分钟，比干脆的失败更糟，因为它看起来像间歇性的网络问题。去系统日志里查看尝试时间点前后的服务名，并确认依赖项也在运行。

当前用户还是本地计算机：两个证书存储

如果客户端打开后证书列表为空，问题既不在配置文件，也不在服务。客户端读取的是当前用户的个人存储：打开 certmgr.msc，展开证书、当前用户、个人、证书，确认证书在那里并且带有私钥。

用 certlm.msc 打开的本地计算机存储是另一个存储，装在那里并不能满足只在用户存储里查找的客户端。采用证书身份验证时，网关只持有根证书的公钥，每台设备都需要从该根证书签发的自己的证书。从其他机器复制来的证书通常不带私钥，于是你会看到一个能选中却仍然无法通过验证的条目。

选择器为空是存储问题，不是隧道问题。

证书身份验证还是 Azure AD：不同的失败形态

采用 Azure AD 身份验证时，点到站点配置需要租户 URL、作为受众的 Azure VPN Client 应用程序 ID 以及 STS 颁发者，并且要由管理员授予 Azure VPN 应用程序同意。保存好这份配置，重新下载安装包，并导入新文件，而不是沿用旧副本。

还要确认客户端地址池没有与虚拟网络或本地网段重叠，并且目标机器的网络安全组允许该地址池。这两个错误能躲过客户端侧的任何一次修复。

笔记本这一侧还是网关那一侧

不要用公网地址检查来判断隧道。点到站点连接不会把所有上网流量都送到 Azure，所以隧道正常工作时公网地址保持不变是正常的。应当改为测试虚拟网络内部的私有地址，并查看机器上的有效路由。

记录下是哪一步恢复了连接、客户端版本、配置文件下载日期，以及凭据来自证书还是身份提供方。这份记录能把下一次故障变成两分钟的例行检查，也能看出问题是否正在从笔记本漂向网关。

操作顺序：重新导入当前配置文件、重启 RasMan、允许后台运行、修复安装包，只有在确认证书存储完好之后才做重置。