Cisco Secure Client 会阻止从 RDP 会话建立 VPN

登录成功了，隧道却始终起不来。这种组合很容易被误读成认证问题，于是有人花一下午重置那些从来不是原因的凭据。Cisco Secure Client 可以拒绝建立 VPN，原因正是这次尝试来自 Remote Desktop 会话，而这个决定由客户端一侧的策略作出。

这个问题出现在连接流程的哪一步

把客户端从上到下走一遍。配置文件加载，凭据收集完成，认证结束。接着，在任何隧道建立之前，客户端会对照自己所处的环境评估会话与建立相关的设置。

此时要记下三件事：完整的提示文字、客户端版本、客户端中显示的配置文件名称。这三样能把含糊的抱怨变成可以处理的工单。给对话框截图，因为长消息在日志里会被截断。也要记下时间，方便管理员与头端对账。

真正起决定作用的设置

Windows VPN Establishment 策略是相关的控制项，它有两个有文档记录的值：仅本地用户，以及允许远程用户。后者允许在受支持的配置下从 Remote Desktop 会话建立隧道。前者是许多企业配置文件中的默认姿态。

别把它和 Windows Logon Enforcement 搞混，后者在配置文件指南中被记录为关于登录会话的另一项策略。一个决定哪个会话可以建立隧道，另一个决定并发或登录前的行为。改错了那一个不会带来任何可见的变化。

读一读真正生效的那份配置文件

在受管部署中，客户端从头端或受管位置获取配置文件，而在磁盘上编辑过的副本往往并不是生效的那一份。这就是为什么本地改 XML 看起来完全正确，却什么都没改变。

去问管理员设备实际收到的是哪份配置文件和哪个组策略，而不是问笔记本上存在哪个文件。版本升级之后，这两者常常对不上。本地文件夹里的旧副本照样能在编辑器里打开，看起来也照样正确。它只是不是客户端实际应用的那一份。

隧道起来之后的 RDP 路径

允许远程建立，并不保证你的 Remote Desktop 会话能活下来。当隧道改变路由或本地访问规则时，把你带进来的那个会话可能失去维持它的路径。

在变更前先规划一条恢复通道：控制台访问、带外管理路径，或者一份成文的重新连接流程。事后再定通常意味着要跑一趟机房。

不要用窃取会话的花招、其他远程控制工具，或写进脚本里的密码来绕过策略。如果组织不授权这种工作方式，正确的做法是走它支持的管道路径。

该发给管理员什么

把提示原文、客户端版本、当前生效的配置文件名称、你连接时使用的会话类型，以及本地控制台尝试是否有不同表现，一并给他。再附上时间戳。

最后那一项对比最省时间，因为它能把会话策略层面的拒绝和设备整体故障区分开。

在获批变更之后做验证

配置文件更新后，新建一个 RDP 会话重新连接，然后刻意走一遍断开流程。确认隧道起得来、管理路径仍然存活、你的账号仍然能登录桌面。

VPN 准入、会话存活、Windows 登录权限是三件彼此独立的检查。通过其中一项，对另外两项毫无说明。