SSH 转发、VPN 还是 RD Gateway：单个 RDP 桌面该走哪条路？

三种方案都能承载 RDP，所以协议并不是决定因素。真正的问题是：一个用户应该获得多大的可达范围，以及由谁来运维提供这种范围的那个东西。一个转发的 TCP 端口、一个已路由的私有网络和一个桌面网关，用三种不同的规模回答了这个问题。先选定规模，产品自然随之而来。

问题在于范围，而非协议

写下用户实际需要触及的对象。如果答案是一台桌面，那么授予整个子网的设计就过于宽泛。如果答案是桌面加上文件共享再加上管理控制台，那么只转发一个端口的设计下个月就会再要求两个转发。目的地清单才是需求，其余都是实现。

把入口身份与登录桌面的 Windows 账户分开。下面每个设计两者都有，而将二者混为一谈，正是跳板机账户获得超出任何人预期权限的原因。

经批准的 SSH 跳板机可以把本地监听转发到它能访问的 RDP 服务。当该监听只服务于用户自己的机器时，应将其绑定到 loopback，这正是本地转发的常见意图。转发是给一个人的便利，不是给团队的服务。

SSH 登录只认证对转发路径的访问，仅此而已。Windows 身份验证与 RDP 授权仍然发生在目标端，因此有效的跳板账户并不等于有效的桌面会话。这是两道彼此独立的门，必须同时打开。

限制跳板账户的转发目的地，而不是授予不受限的 shell。这种设计适合规模小、明确列出的机器集合，代价是增加一台主机、一个身份和一套需要运维的生命周期。那台额外主机正是人们在与网关比较时容易忘记的部分：总得有人打补丁、做监控并保管它的密钥。

VPN 提供私有 DNS 以及对多个协同使用服务的访问，这才是它真正的价值。隐藏一个桌面端口只是副作用，而不是构建它的理由。当有人问 VPN 到底为什么存在时，这一区分很重要。

把路由和资源权限限制在预期的目的地。已连接的用户并不会自动配得上整个局域网，而目标防火墙加上 Windows 登录权限仍是彼此独立的边界，VPN 并不能替代。

这种安排对已经成形的受管工作区很方便。代价是入职、设备要求、解析器行为与连接策略都成为用户工作环境的一部分，必须有人负责。在假定 VPN 更便宜之前，请把这项成本与网关的许可费用做比较。

Remote Desktop Gateway 提供的是 RDP 专用边界，而不是网络边界。它的连接授权策略决定谁可以连接，资源授权策略决定他们能通过它访问哪些内部资源。两项策略都是产品的一部分，而非可选附加项。

把证书、身份集成和所需传输一并规划。网关不是匿名 TCP 中继，按匿名中继部署就会跳过使它成立的那些策略。它还带有单一转发端口所没有的许可与运维要求。请在设计评审之前把这些编入预算，而不是之后。

在团队已经运行集中式桌面访问的地方，这些额外开销已经付过。在一个人只需要一台机器的地方，为一件小事买一台大机器并不划算。

在每个设计中保留主机身份校验。本地别名或隧道不会让意外出现的证书变得无害，而为了穿过代理去接受不匹配的证书，就破坏了隧道的意义。客户端中的名称与证书上的名称必须有意识地核对一致。

在策略要求的入口点应用 MFA，并保留目标端的账户控制。两者互补：前者决定谁可以走到门口，后者决定谁可以打开它。丢掉任何一个，留下的都是看似完整、实则不完整的设计。

选择与工作内容以及你实际拥有的运维模式相匹配的边界。RDS 角色概述描述了网关在会话主机与其他组件之间的位置，正是这一背景让它的成本变得可读。