通过 VPN 的远程桌面：你卡在哪一步失败？

隧道已经接通，内部 Wiki 能打开，远程桌面却仍然拒绝连接。这种组合很正常，因为 VPN 只提供到主机的路由，而桌面服务必须正在监听、被它自己的防火墙放行，并且愿意认证该账户。从可用的隧道到可用的会话之间有四层失败，每一层的报错各不相同。先读报错，因为报错会点明卡在哪一层。

四种看起来像一种的失败

这几层是有顺序的：名称解析到设计所预期的私有地址，端口能完成 TCP 握手，主机按自己的策略接受连接，会话登录成功。每一步都会让下一步无法测试，所以在网络没理清之前改 RDP 设置只会制造噪音。从用户这边看，四种情况的症状一模一样。只有客户端的报错能把它们区分开。

内部网站能打开，什么也证明不了。它只证明同一网络里的某台主机在另一个端口上用另一个服务做了应答。把它当作关于路由的证据，仅此而已。

按顺序测试，并记录结果。因为端口答应了就跳到登录界面，等于把一下午花在第一步早已定位的防火墙问题上。

3389 端口上有人在监听吗？

从名称开始，因为解析到错误地址的名称会让后面每一次测试失效。问隧道的解析器这个名称指向什么，然后把答案与设计预期的私有地址对比，而不是与有响应对比。解析到公网地址的名称就是问题本身，改 RDP 不会有任何帮助：

nslookup desktop.corp.example
Resolve-DnsName desktop.corp.example

然后测端口，而不是测主机。3389 上完成 TCP 握手，就把可达性与它上面的所有层分开了：

Test-NetConnection -ComputerName desktop.corp.example -Port 3389

从 LAN 和从隧道各跑一次这个测试，因为两个结果的差异能把故障定位到 VPN 路径上。路径上有两道防火墙，很容易混为一谈：网络必须允许客户端的隧道地址到达主机，而主机自己的防火墙也必须允许同一来源访问监听端口。只针对 LAN 子网放行的规则覆盖不到 VPN 客户端池，这正是只有远程用户报告超时最常见的原因。查规则的适用范围，而不是规则是否存在。

回程同样值得检查。应答需要一条回到客户端池的路由，而不是回 LAN 的路由；主机前面的地址转换会改变日志里记录的来源。如果端口一个方向通、另一个方向不通，缺的那一半通常就是回程。

先读报错，再读配置

第三层是主机按自己的策略拒绝连接，表现常常是端口刚打开就关闭。有东西回应了，这比没有回应有用得多。如果握手完成而会话立刻死掉，网络没问题，是主机在做决定。再次动网络之前，先看远程桌面的权限设置。

功能可能对整台机器开启，而访问只允许特定组；监听器也可能以排除了你到达时所用地址的方式绑定。网络级身份验证加了一道在桌面加载前就失败的关卡，它的报错文本与密码错误并不相同。把客户端报错与主机事件日志对照，因为报错点的是关卡，日志点的是账户。

会话登录是另一道边界

身份验证属于桌面服务，而不属于 VPN。隧道的身份与桌面账户是两套凭据、两套锁定策略，所以隧道能用只证明隧道接受了你。锁定桌面账户不会影响隧道，反过来也一样。

两者都要保住。私网路由缺失时，去修路由，因为把监听器发布到公网，等于用可达性缺陷换一台暴露的桌面。也不要为了绕过同时出现的证书警告而削弱会话的身份校验。RDP 监听器上的自签名证书本来就会报警告，所以接受它是一个决定，而不是一个步骤。

重试之前先数尝试次数。桌面锁定阈值会把登录失败与 VPN 失败分开统计，而按时钟重试的客户端可能在你还在改规则时就把阈值触发。这就是改密码后锁账户的那套并行重试机制。

会话能带走什么，又留在哪里

在需要之前先学会被批准的注销流程。关闭窗口可能只断开视图，而会话仍按已配置的策略继续运行，这在共享或受审计的主机上很关键。策略要求时，从会话内部注销。

再决定会话可以携带什么，因为剪贴板、重定向的驱动器、打印机重定向和文件传输都会在策略允许的地方，在本地与远程系统之间搬运数据。发布在远端运行的应用，并不自动等于禁止下载的边界；看起来只读的会话仍然可以携带剪贴板。测真实任务，而不是测连接：打开文件、使用应用，确认你需要的重定向。Microsoft 关于从外部访问远程桌面的指南介绍了受支持的暴露方式，它比在压力下临时加上的公网监听器更值得参考。