无需 VPN 的 Windows 远程桌面:原因和真正的解决方法

Windows Remote Desktop Without VPN: Causes and Real Fixes

设想远程桌面在你的局域网中正常工作,但一旦你在其他地方尝试就失败。客户端卡在Initiating remote connection,随后返回一个包含三个原因的错误,提示远程计算机在网络上不可用。或者在到达登录屏幕之前以0x2040x4失败。这是架构层面的问题,而不是你在设置中犯了错误。RDP 期望到主机的直接路径,并且自身不提供通过 NAT 协商该路径的机制。因此,除非由路由器、网关或隧道提供这条路径,否则它无路可走。了解为何在没有 VPN 的情况下 Windows 远程桌面无法工作、有哪些可用的原生选项,以及能让你连接上的修复方法的更多细节。

如果你需要的那台机器位于你无法控制的网络内部,HelpWire 可以解决 RDP 无法处理的情况。它是一款面向处理远程支持的 IT 团队和技术人员的远程访问软件,并且它通过双方的出站连接发起会话,而不是依赖主机上的入站端口。它优先选择两台机器之间的直连路径以保持控制的响应性,当网络不允许直连时则使用中继连接。在更下方,在用尽所有原生修复方法之后,有一份完整的教程。

为什么在没有 VPN 的情况下,通过互联网的远程桌面连接会失败

RDP 没有 NAT 穿越层,因此它依赖其他机制来为主机提供一条直接路径。微软在其关于 从你的网络外部进行访问 的官方页面上是这样说明的,其中称 RDP 会话为点对点连接。这里的说法意指“直接”而非“经代理”并不意味着 RDP 采用任何点对点架构。关键在于其后果:你需要对主机进行直接访问。同一页面仅提供两种实现该访问的方式:端口转发或 VPN,并且对第一种方式附有警告。微软原话如下:你正在将你的 PC 暴露到互联网上,这并不推荐。

这就是厂商所陈述的整个问题。将其与现代点对点协议的行为进行对比。它们通常带有 STUN 客户端,能够发现自身的公网地址,进行 NAT 打洞,并在遇到无法穿越的 NAT 类型时回退到中继。RDP 完全不做这些。它仅监听 TCP 3389,如果没有数据包抵达那里,就什么也不会发生。

连接路径如何中断

客户端解析名称或 IP,并在主机上的端口 3389 建立 TCP 连接。该连接必须穿过你的 ISP、你的路由器、Windows Defender 防火墙,并到达 RDP 侦听器。运营商级 NAT 会在第一跳将其阻断,因为你的路由器持有私有 WAN 地址,你编写的转发规则永远收不到流量。动态公网 IP 会在地址更换后于第二跳将其中断。未启用相应远程桌面规则的防火墙配置文件会在第三跳将其中断,因为这些规则按配置文件划分作用域,而被分类为 Public 的网络通常将其关闭。缺少侦听器会在第四跳将其中断,这正是 Windows 家庭版上的情况:无论你在注册表中怎么写,主机组件都不存在。

检查 WAN 地址

该检查耗时三十秒。先从路由器状态页面读取 WAN IP,然后将其与公共 IP 检查器报告的结果进行比较。地址一致意味着路由器持有公共 IPv4 地址,这是必要条件而非充分条件,因为 ISP 仍可能在你上游对 3389 的入站流量进行过滤。地址不一致则意味着在你之上还有一个 NAT,而 WAN 地址有助于缩小是哪一种类型。

位于 100.64.0.0/10 的地址是共享的运营商空间,指向运营商级 NAT,在这种情况下,你编写的任何规则都无法接收入站流量。位于 10.0.0.0/8172.16.0.0/12192.168.0.0/16 的地址更常见地意味着在你的路由器前面还有 ISP 的调制解调器或网关。这是普通的双重 NAT,可以通过在两个设备上都设置规则,或在上游设备上启用桥接模式来解决。一些运营商也会在私有网段上运行运营商级 NAT,因此如果在两个设备上设置规则仍然没有结果,请将其视为运营商级 NAT。

网络正常后,身份验证可能会失败

一旦数据包确实到达主机,连接仍可能在身份验证期间中断,而且从客户端看来,这些错误与网络故障没有区别。CredSSP 版本不匹配会产生 An authentication error has occurred. The function requested is not supported。已加入 Microsoft Entra 的主机会拒绝 domain\user 格式,并返回一条说明远程计算机已加入 Entra 的消息。Windows 11 24H2 客户端在大约 65 秒后会断开到旧版 RDS 主机的 UDP 会话。

RDP Shortpath 是不同的

RDP Shortpath 使用 ICE 来评估候选路径,STUN 用于在客户端与会话主机之间建立直接 UDP 连接,而 TURN 则在无法直连时用于中继。中继服务通过出站 UDP 端口 3478 进行访问。直接 UDP 路径使用可配置的端口范围,而非固定端口。当 UDP 被完全阻止时,会话将回退为通过服务网关的基于 TCP 的反向连接传输。

Shortpath 是这些服务内部的一种传输优化,而不是一种可以用于任何机器的 NAT 穿越层。客户端和会话主机首先通过 Azure Virtual DesktopWindows 365 控制平面互相发现,随后 Shortpath 才会协商 UDP 路径。这种经由撮合的引荐是普通 PC 到 PC 连接所缺乏的部分。 Shortpath,以及构建其之上的较新的 RDP Multipath,其适用范围仅限于 Azure Virtual Desktop 会话主机和 Windows 365 云电脑,不适用于针对普通 Windows PC 的 mstsc.exe

大多数人首先尝试的做法,以及它为何会失败

netsh int ip resetnetsh winsock resetsfc /SCANNOW,以及 DISM 修复会按顺序运行,但不会带来任何变化,因为本地协议栈从未损坏。一个有记录的案例是在 Windows 10 企业版 22H2,内部版本 19045.3803,执行了这四项外加一次 远程桌面服务 重启、完全禁用防火墙、切换 RD 网关,以及清空凭据缓存,之后报告者才注意到关键线索:连接到未使用的 IP 正常进行,而连接到真实主机则立刻抛出 0x4。这种模式指向客户端会话缓存或安全层,而非路由。

DMZ 模式和 UPnP 被启用来对抗 CGNAT。两者都无效,因为阻断发生在你无法登录的运营商网关上,位于你的路由器上游数跳处。 DMZ 只会扩大你本地的暴露面,而入站流量仍然无法到达。

还有人把侦听端口从 3389 改为其他端口,认为这样能隐藏主机。互联网扫描器可以在非默认端口上识别 RDP。他们还把禁用 NLA 当作第一步而不是最后一步,这会从即将暴露到互联网的机器上移除会话前的身份验证。

通过 fDenyTSConnections 在 Windows 家庭版上启用 RDP 会接受该值但不起任何作用,因为该版本并不存在主机组件。并且在 2026 年 1 月更新破坏了 远程协助,曾流传一种变通方法,用另一台机器上未打补丁的副本替换 msra.exe。它通过重新打开 CVE-2026-20824远程协助 的安全功能绕过,微软于 2026 年 1 月 13 日发布,来恢复该功能。

无需 VPN 的远程桌面:行之有效的修复方案

这些按它们解决问题的频率排序,从最省时的诊断开始。

修复 1. 在更改 Windows 之前确认存在可访问的地址

在你知道入站流量是否能够到达你的路由器之前,其他一切都不重要:

  1. 打开您的路由器管理页面,并在状态页面中记录 WAN 或 Internet IP 地址。

  2. 使用同一网络中的浏览器,打开任意公网 IP 查询工具,并记录其显示的地址。

  3. 比较它们。相同表示路由器拥有可路由的公网 IP。不同则表示在你之上还有一层 NAT,而 WAN 地址会告诉你是哪一种:100.64.0.0/10 表示运营商级 NAT,而 10.0.0.0/8172.16.0.0/12192.168.0.0/16 更常见地表示在你的路由器前面还有一个 ISP 网关。

  4. 如果地址匹配,请确认该端口对外开放。使用处于移动数据而非你的 Wi‑Fi 的手机,针对你的公网 IP 上的 3389 运行一次端口检查。

  5. 如果 ISP 网关位于你的路由器之前,请在两个设备上转发端口,或将上游设备切换为桥接模式,然后重新测试。

  6. 如果 WAN 地址是运营商级,或者在两台设备上设置规则仍然没有效果,请致电 ISP 并要求分配一个公网 IPv4 地址。有些会在提出请求时免费提供,另一些则会收取少量的月费。如果他们拒绝,请跳到后备方案部分。

修复 2。正确启用主机,并证明监听器正在运行

仅设置注册表标志并不会打开防火墙,而打开防火墙这一步往往被大多数指南忽略:

  1. 在主机上以管理员身份打开命令提示符并启用该协议:


    reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f

     

  2. 打开防火墙规则。将其范围限定为 DomainPrivate,除非你确实需要 Public


    netsh advfirewall firewall set rule group="remote desktop" new enable=Yes profile=domain,private

     

    在非英语的安装环境中,显示的组名称会被本地化,因此该命令将无法匹配任何内容。规则名称未被本地化,所以请直接针对它们:

     

    Get-NetFirewallRule -Name "RemoteDesktop-UserMode-In-TCP","RemoteDesktop-UserMode-In-UDP" | Set-NetFirewallRule -Enabled True -Profile Domain,Private

     

  3. 确认该服务已设置为自动启动并正在运行:


    sc config TermService start= auto

    sc query TermService

     

  4. 验证侦听器是否已绑定:


    netstat -an | findstr :3389

     

    默认配置会同时返回 TCP 0.0.0.0:3389 ... LISTENINGTCP [::]:3389 ... LISTENING。仅绑定到一个地址或一个协议栈的侦听器会显示更少的条目,这在自定义主机上是正常的。空结果是失败的信号。

     

  5. 请显式添加该账户,因为本地管理员成员身份并不总是像人们以为的那样被继承:


    net localgroup "Remote Desktop Users" "DOMAIN\username" /add

     

  6. 确认防火墙规则处于启用状态,而不是仅仅存在:


    netsh advfirewall firewall show rule group="remote desktop"

     

    如果第 4 步没有返回任何内容,主机为家庭版,或 TermService 未能启动。这两种情况都无法通过进一步的注册表编辑来修复。

修复 3。通过 TCP 443 将 RDP 置于 RD Gateway 之后

Microsoft 支持这种无需 VPN 的远程桌面方案,因为它将 RDP 置于 HTTPS 网关之后,而不是直接暴露端口 3389。RD Gateway 将 RDP 封装在 HTTPS 内部,因此端口 3389 从不直接面向互联网,并且在会话到达目标主机之前,客户端会先向网关进行身份验证。在几乎所有屏蔽 3389 的酒店、咖啡馆和机场网络中,出站的 443 也都是开放的。

  1. 在 Windows Server 主机上,安装 远程桌面网关 角色服务,通过 服务器管理器

  2. 绑定一个主题名称与外部 FQDN 匹配的 SSL 证书。使用公开受信任的证书最省事,因为自签名证书必须安装到每个连接的客户端的 Trusted Root 存储中。

  3. 创建一个连接授权策略和一个资源授权策略,用于指定允许的用户组和允许的内部主机。

  4. 将网关放置在 DMZ 中,并为其开放入站的 TCP 443,如果需要 UDP 传输,再开放 UDP 3391。除此之外无需其他设置。

  5. 在客户端上,打开 mstsc.exe,展开 显示选项,转到 高级 选项卡,单击 从任何位置进行连接 下的 设置,然后输入网关的 FQDN。

  6. 在退役任何现有的访问路径之前,请先从外部网络进行测试。

对成本要有现实的认识。这种方案需要 Windows Server、一个你要么购买要么自行分发的证书,以及 DMZ 网络设计。许可取决于网关后面的内容,因为 RDS CAL 绑定的是对远程桌面会话主机的使用,而不是对网关角色本身。因此,将连接代理到各个客户端 PC 的部署,其许可情况与会话主机场不同。在制定预算前先确认你的情况。对于一台家用 PC 或两人办公室来说,这样做代价不成比例,这也是正当的理由去考虑其他方案。

修复 4. 正确清除 CredSSP 加密 Oracle 错误

正确的修复方法是为两端都打补丁,而不是削弱客户端。

确切的错误为:An authentication error has occurred. The function requested is not supported. Remote computer: <name>. This could be due to CredSSP encryption oracle remediation。这可追溯到CVE-2018-0886和 2018 年 5 月的强制实施更新,该更新阻止了已打补丁的客户端连接到未打补丁的主机。

  1. 在主机上安装最新的累积更新。这将永久解决该错误,并且这是微软唯一认可的修复方法。

  2. 如果主机无法立即打补丁,请在管理员命令提示符中应用文档中记录的临时客户端变通方法。值 2 表示易受攻击的保护级别:


    REG ADD HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters\ /v AllowEncryptionOracle /t REG_DWORD /d 2

     

  3. 先为主机打补丁,然后恢复客户端。三种防护级别分别为 0 对应 Force Updated Clients,1 对应 Mitigated,以及 2 对应 Vulnerable,并且在 CredSSP 更新后,默认值为 1。将其恢复为该默认值:

     

    REG ADD HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters\ /v AllowEncryptionOracle /t REG_DWORD /d 1

     

    使用 0 而不是 1 用于 Force Updated Clients,该设置更为严格,并且会拒绝任何仍在运行未打补丁的 CredSSP 的主机。如果注册表值无法保留,Encryption Oracle Remediation Group Policy 正在覆盖它。请检查 Computer Configuration > Administrative Templates > System > Credentials Delegation > Encryption Oracle Remediation 并设置策略本身,而不是该键。

     

修复 5。在已加入 Microsoft Entra 的主机上使用正确的用户名格式

已加入 Microsoft Entra 的计算机会直接拒绝 domain\user 格式,并返回:Remote machine is Microsoft Entra joined. If you are signing in to your work account, try using your work email address

  1. user@domain.comAzureAD\user@domain.com 的格式输入凭据。切勿使用 domain\user

  2. 按照相同的格式,将该账户添加到主机的 Remote Desktop Users 组:
    net localgroup "Remote Desktop Users" "AzureAD\user@domain.com" /add

  3. 若要实现完整的Entra身份验证,打开 mstsc.exe,转到高级选项卡,并勾选使用 Web 帐户登录到远程计算机。这对应于enablerdsaadauth RDP 属性。

  4. 通过主机名连接,而不是通过 IP。Web 帐户选项不接受 IP 字面量,且名称必须与设备的主机名一致,该主机名注册于 Entra ID.

  5. 如果使用有效凭据登录仍然失败,请检查该帐户是否存在旧版的每用户多重身份验证设置。每用户强制执行会阻止此路径,必须将其移除,改用条件性访问

Web 帐户选项的最低版本要求:适用于 Windows 11(需安装 KB5018418 或更高版本)Windows 10 20H2 或更高版本(需安装 KB5018410 或更高版本)Windows Server 2022(需安装 KB5018421 或更高版本)临时密码在 RDP 登录中始终无效,因此请先在浏览器中重置密码。

修复 6. 修补已知的 Windows 11 回归问题,而不是使用 UDP 开关

近期的 Windows 11 版本遇到了三个彼此独立的回归问题。这三个问题都已修复,而对其中任何一个问题来说,永久禁用 UDP 都是错误的应对方式。

症状 受影响的配置 已确认的解决方案
连接后不久会话卡死,鼠标和键盘无响应 Windows 11 24H2KB5050094(2025 年 1 月 28 日)之后,其更改由 KB5051987(2025 年 2 月 11 日)合入安全更新通道 KB5052093,2025 年 2 月 25 日的可选更新,或之后的任何累积更新
服务器端出现相同的卡死 安装 2025 年 2 月安全更新后的 Windows Server 2025 KB5055523,于 2025 年 4 月 8 日发布,或更高版本
通过 UDP 连接约 65 秒后会话断开 Windows 11 24H2 客户端到运行 Windows Server 2016 或更早版本的 RDS 主机 KB5053656 或更高版本
在 Windows App 或远程桌面中立即登录失败并出现身份验证错误 Windows 11 24H2 版本 26100.762325H2 版本 26200.7623KB5074109 之后;Windows 10 和 Windows Server 在其 2026 年 1 月 13 日更新后也出现相同的回归问题
2026 年 1 月 17 日发布的带外更新,在步骤 2 中按版本列出,或之后的任何累积更新
未出现上述任一症状,但会话仍会中断 任何 在禁用 UDP 之前,请先单独诊断传输
  1. 运行 winver 并确认内部版本号。24H2 属于 26100 系列,单凭版本字符串无法确认补丁是否存在。

  2. 打开 设置 > Windows 更新 > 更新历史记录。对于 2025 年的两个回归问题,KB5053656 或任何后续的累积更新都可同时覆盖二者。对于 2026 年 1 月的身份验证回归问题,微软于 2026 年 1 月 17 日发布了带外更新:KB5077744 适用于 Windows 11 25H224H2KB5077797 适用于 Windows 11 23H2KB5077796KB5077795 适用于 Windows 10,KB5077793 适用于 Windows Server 2025,KB5077800 适用于 Windows Server 2022,以及 KB5077792 适用于 Windows Server 版本 23H2

  3. 如果设备受管理且尚无法打补丁,请通过 Microsoft 为此问题提供的 组策略 模板部署 已知问题回退 策略,刷新该策略并重新启动。

  4. 仅在打补丁后断线仍然持续的情况下,请在 计算机配置 > 管理模板 > Windows 组件 > 远程桌面服务 > 远程桌面连接客户端 > 在客户端上关闭 UDP 处将 UDP 关闭进行测试,并将其视为诊断手段,而非永久状态。

不要卸载整个 24H2 累积更新。那样会移除无关的安全修复,只是为了解决一个早在一年多前就已修补的问题。

不使用 VPN 的情况下,远程桌面安全吗?

是的,不使用 VPN 的远程桌面连接如果其前面有网关或隧道,则是安全的。不,当 3389在公共 IP 上处于开放状态时。

区分这两者很重要,因为两者常被当作一回事来讨论。RD 网关、经认证的隧道以及由代理中介的连接都能让 RDP 监听器不暴露在公共互联网之上,因此是可防御的。转发端口则完全是另一回事。这份 2026 年 Sophos 活跃对手报告,基于 661 起在 2024 年 11 月至 2025 年 10 月间处理的事件响应与托管检测案例,仍将 RDP 排在被滥用的 Microsoft 二进制文件清单之首。内部 RDP 使用出现在 66% 的案例中,外部使用出现在 10% 的案例中。仅暴力破解就占据了 15.58% 的根本原因,而与身份相关的原因合计达到 67.32%。Sophos 还记录到当年暴露的 RDP 系统数量减半,这是一种进步,但并不意味着高枕无忧。

局限性:暴露端口无法为你提供的内容

被转发的 3389 除了 NLA 之外没有任何预认证关卡,没有按用户或按时间的访问规则,也没有地理位置过滤。日志功能是有的,但默认关闭。Windows Defender 防火墙会写入 %systemroot%\system32\LogFiles\Firewall\pfirewall.log,但只有在你在 wf.msc 中为每个配置文件的日志设置里,将记录丢弃的数据包和记录成功的连接设为Yes之后才会生效,而这两项的默认值都是No。若不启用它们,在遭受活跃的暴力破解时,唯一的信号就是安全事件日志几乎每秒都会充满一次 4625 失败。最后这个症状值得了解,因为在遭受攻击时,机器会因资源耗尽而开始抛出 An internal error has occurred,而该错误并不会告诉你原因。

如果你无论如何都要保持端口开放,请做以下四件事。在路由器上而不是主机上限制源 IP 范围,因为仅存在于Windows 防火墙中的过滤器仍会让流量到达机器。重命名Administrator帐户,并将锁定阈值设置为 3 到 5 次失败尝试。对Remote Desktop Users组中的每个帐户强制执行至少 12 个字符的最小密码长度。保持 NLA 开启,因为它会在创建会话之前强制进行身份验证,并拒绝向未经身份验证的请求提供可被耗尽的资源。

在某些情况下,VPN 仍然是正确的选择,假装并非如此是不诚实的。受监管且要求使用加密隧道的环境、需要集中访问控制的多站点网络,以及 IT 监管最少的基础设施,都能从 VPN 提供的网络边界中受益。在这些环境中,VPN 是合适的工具。当只有一个人需要访问一台机器时,它就显得不相称了。

如果 Windows 远程桌面在没有 VPN 的情况下仍然无法连接

两个本机备用方案适用于特定情形,且二者都有硬性上限。

Quick Assist,仅用于有人值守的支持。Quick Assist 通过微软的 relay at remoteassistance.support.services.microsoft.com 在 TCP 443 端口并使用 TLS 1.2 运行,因此两台计算机都不需要开放入站端口。它适用于受支持的 Windows 10 和 Windows 11 版本,并通过 Microsoft 商店分发和更新。协助方使用 Microsoft 帐户或工作帐户登录,生成一个限时代码,接收方输入并批准会话。当远程计算机前有人值守时使用它。它没有无人值守模式,因此不能替代 RDP 来访问你自己的无人值守 PC,并且不会留下可供事后查看的会话记录。需要更多功能的受管环境会使用 Remote Help,微软对此单独授权。

IPv6(当两端都具备时)RDP 默认绑定到所有接口,这也是为什么 netstat 会显示 TCP [::]:3389 LISTENING. IPv6 没有 NAT,因此 CGNAT 就不再相关,在路由器和主机上开一个防火墙小孔即可。需要同时满足三个条件。两端都需要可用的 IPv6,可通过 test-ipv6.com 进行确认。运营商不得对入站 IPv6 进行一刀切过滤,但确有数家这样做,T-Mobile Home Internet 就是被广泛报道的案例。你还需要一种稳定的方式来访问主机。Windows 上的 IPv6 地址选择随配置而异,且在重新连接时 ISP 的前缀可能会变化,因此由动态 DNS 客户端保持最新的 AAAA 记录是更持久的答案。如果你确认所需的地址在轮换,下面这两个命令分别针对不同的机制。第一个停止接口标识符随机化。第二个停止临时地址。当 ISP 更改你的前缀时,二者都无法保持地址不变,这也是为什么 DNS 记录更为关键:

netsh interface ipv6 set global randomizeidentifiers=disabled

netsh interface ipv6 set privacy state=disabled


关于 Windows App 的说明。Windows App 是微软在 Windows 365、Azure Virtual Desktop、Microsoft Dev Box、Remote Desktop Services 以及远程 PC 上的统一客户端。但它能连接到哪些内容取决于你运行它的平台;在 Windows 上,它目前不覆盖 Remote Desktop Services,而 macOS、iOS、iPadOS 和 Android 则覆盖;同时,Windows 上的远程 PC 连接处于预览阶段。通过 MSI 安装的独立 Remote Desktop 客户端和 Remote Desktop Web 客户端已于 2026 年 3 月 27 日停止支持商业云环境;对于 Azure Government、由 21Vianet 运营的 Azure,以及 AVD Classic,MSI 客户端的支持延长至 2026 年 9 月 28 日。同时,mstsc.exe 仍是普通 PC 到 PC 连接的一般可用选项,而这些变化都不会改变数据包到达主机的方式。

若两者均不适用,问题就不再是 Windows 层面的问题。这是一个你无法更改的网络问题,下一节将介绍在该环境下可行的做法。

当你无法更改网络时:HelpWire

HelpWire 是一款远程访问软件,能够访问 RDP 无法访问的机器,因为双方都不需要入站端口。操作端应用和客户端应用都会发起出站连接。这就是所有原生方式都走到尽头的场景:没有可转发到的公网 IP、没有用于托管网关的 Windows Server,也没有人在远程机器旁读出 Quick Assist 代码。

HelpWire 的工作原理

操作员通过电子邮件、聊天或服务台工单发送生成的连接链接。客户打开该链接,系统会自动检测其操作系统并开始下载,然后他们启动应用。客户端应用默认为便携式,因此无需安装程序,也无需管理员权限即可运行。他们点击 授予访问权限,您就可以开始为其提供远程支持。

对于需要超过单次会话的工作,您可以稍后请求无人值守访问。客户只需批准一次,之后只要机器已开机并联网,操作员及其团队成员即可从门户进行连接,而无需客户采取任何操作。会话会在重启后自动重新连接,这对于驱动程序安装和 Windows 更新等情况尤为重要,否则这些操作往往会使支持通话过早结束。

使用 HelpWire 的 Windows 远程支持会话

当没有可用的直接路径时会发生什么

HelpWire 优先建立操作员与客户之间的直接连接,以在动手操作时降低延迟。当网络状况无法提供直连路径时,它会改用中继连接以维持连通性,而不是中断会话。其实际效果会在对话框和设置页面之间反复导航时体现出来。

访问控制和加密

会话通过 TLS 进行传输,并采用 AES-256 加密。客户端需批准每一次有人值守的会话,并可随时撤销访问权限。操作员可以撤回其自己的 无人值守访问,可在门户的工作站选项卡中操作。账户登录使用 Clerk,并可选择一次性密码作为第二因素,应用由 DigiCert 签名。与暴露的 3389 监听器相比,实际的区别在于:访问权限是由可以收回权限的人按设备授予的,而不是取决于谁先猜中密码。

HelpWire 与其他方案对比

路由 需要的入站端口 目标电脑上的 Windows 版本 无人值守访问 额外的基础设施
端口转发使用 3389 是,并且需要一个公网 IP 专业版、企业版、教育版或服务器版 路由器管理员权限
RD 网关使用 443 是,在网关上 专业版、企业版、教育版或服务器版 Windows Server、SSL 证书、DMZ 设计
快速协助 任何版本 协助者需要 Microsoft 帐户
RDP 通过 IPv6 在双方防火墙上开孔 专业版、企业版、教育版或服务器版 两端均需双栈 ISP
HelpWire Windows 7 及更高版本 网络侧无额外要求
 

注意: HelpWire 是围绕支持工作流程构建的,而不是面向大规模终端群管理。因此,如果你的需求是在数千个端点上进行集中式策略执行,那是另一类工具。对于需要在一个没有人会去重新配置的网络中访问某台特定机器的技术人员而言,它消除了使 RDP 从一开始就不可用的限制。

专业提示:测试重连,而不是连接

设置好你选择的任意路由后,在依赖它之前先重启主机并再次尝试。以我的经验,第二次连接比第一次更常失败,且原因是可预见的:DHCP 租约把主机切换到了新的内网 IP,导致转发规则失效;公网 IP 在夜间轮换而没有 DDNS 跟随;Windows 隐私地址重新生成了 IPv6 主机标识符;或者机器进入睡眠,导致监听被中断。固定一个静态内网 IP 或设置 DHCP 保留,通过 设置 > 系统 > 电源和电池 在主机上禁用睡眠,并确认该路径在重启后仍然有效。只有在重启后依然有效的路由才值得信赖。

常见问题

是的,可以通过四种原生途径:转发端口、通过 HTTPS 443 的 RD 网关、通过 Microsoft 的中继的 快速协助,或通过 IPv6 的 RDP。每种方式都有硬性要求。端口转发需要公网 IPv4 地址和对路由器的访问权限。RD 网关需要 Windows Server;若用户通过它连接到 远程桌面会话主机。还需要 RDS CAL。快速协助 需要远程计算机有人在场。IPv6 需要两端均为双栈服务,并且运营商不过滤入站流量。

最常见的原因是运营商级 NAT,你的 ISP 会在许多用户之间共享一个公共的 IPv4 地址,而你的路由器持有一个私有的 WAN 地址。入站流量会到达运营商网关,但该网关没有将其映射到你的规则,因此在到达你的路由器之前就被丢弃。将你的路由器的 WAN IP 与公网 IP 查询工具进行比较;如果两个地址不同,即可确认为 CGNAT。

不行。暴露的侦听端口会在数小时内就吸引自动化扫描,且除了 NLA 之外没有任何预认证门槛、没有源地址限制,也没有有效的审计日志。改为将流量通过运行在443端口上的 RD Gateway 或出站隧道进行转发。

你无法在任何家庭版上承载 RDP 会话,因为无论你如何设置 fDenyTSConnections,侦听组件都不存在。Windows 家庭版 可以充当客户端,并连接到 专业版、企业版、教育版 或 Windows Server 主机。若要对 家庭版 计算机进行入站访问,请使用不依赖 RDP 侦听器的远程访问工具。

局域网路径会跳过所有会破坏互联网路径的层。在局域网内,无需穿越 NAT,没有运营商网关,也不会发生防火墙配置文件切换。在互联网上,相同的连接必须经受 CGNAT、动态公网 IP、路由器规则,以及一个将公共网络与专用网络区别对待的 Windows 防火墙 配置文件。

两者都是通用代码,只报告连接失败或中断而不指明原因,因此应将它们视为诊断提示,而不是答案本身。对于 0x204,从网络层入手:确认路由、防火墙规则,以及 netstat -an | findstr :3389 是否显示主机上存在已绑定的侦听器。对于 0x4,它常出现在突然断开之后,在触及网络栈之前,先排除客户端会话状态和安全层的问题。

不建议,这还可能会引发问题。互联网扫描器会在非默认端口上识别 RDP。因此,这种更改几乎没有安全收益,而且有报告称它会破坏那些期望默认侦听器的多因素身份验证钩子。相反,应在路由器上限制源 IP 范围,并将流量置于网关或隧道之后。