大部分Windows服务器管理员有时候要用到远程桌面服务（Remote Desktop Service，RDS）。这是因为Windows RDS在远程交付应用和桌面给用户时是一个价格实惠的解决方案。它还很容易获得：只需点击几次鼠标，任一台Windows Server都能变成RDS服务器。

　　尽管远程桌面会话主机（Remote Desktop Session Host，RDSH）是RDS的核心，远程桌面网关（Remote Desktop Gateway，RDG）是一个相同效力的角色服务，它实现了不受信网络和互联网上的安全用户会话。

　　所以，如果RDG是互联网启用Windows RDS应用的实用工具，为什么没有更多的IT工作站使用它呢？一个障碍在于对RDG整合到DMZ或内部LAN的不同方式缺少了解。复杂的事情是一系列误解让RDG看上去比本身更不安全。

　　不同之处在你的设计中。

　　将RDG整合到现有DMZ有四种不同的设计，拥有四种中的一种代表着当前行业的最佳实践。在每一种设计中，你都可以假设RDG角色服务安装在一台独立的服务器上，这台服务器单独用于RDG服务。另外，虽然“互联网”这个词用来形容LAN外部的网络，但是这个词也代表所有外部不受信任的网络（例如外网）。

　　设计一：没有DMZ。LAN里的RDG。

　　最常见的RDG设计也是最简单的。这种设计中不需要DMZ，因为RDG放置在内部LAN里且拥有到RDSH的完全网络连接。在这种设计中，防火墙端口TCP/443在互联网和RDG间打开，DNS记录正确地更新，因此RDG的完全限定域名（FQDN）可以从LAN或互联网上解析。

　　虽然这个设计足够简单，它并不提供大部分安全策略需要的网络隔离和保护的类别。例如，大部分安全策略需要来自于互联网的网络流量来在进入一个内部LAN前通过一个DMZ服务器代理。这种设计不支持这样的要求。

　　设计二：DMZ中的RDG。不曝光内部活动目录。

　　为了支持大部分企业网络上强制执行的代理要求，第二种设计将RDG迁移到DMZ中。由于它的位置，端口TCP/443首先必须在互联网和RDG间打开，接着是端口TCP/3389要在RGB和内部LAN间打开。

　　虽然该设计将RDG从内部LAN上隔离，但它这么做是出于内部活动目录曝光的成本考虑。因为只有远程桌面协议端口（TCP/3389）在DMZ和内部LAN间打开，运行RDG的服务器必须以工作组模式运作。

　　注意，只有在Windows Server 2008 R2上才能这样使用工作组模式。2008 R2之前的操作系统版本需要RDG作为一台加入域的服务器。还要注意，这种设计，连接的用户将需要两组不同的用户名和密码。第一组由本地用户在RDG上管理，而第二组则是他们的内部域证书。

　　设计三：DMZ中的RDG，曝光内部活动目录。

　　要求用户保存两组不同的用户名和密码是个沉重的负担，在RDG服务器上维护它们的管理工作本身也是个沉重的负担。因此，大部分环境需要遍及整个连接的单点登录体验，从远程设备，贯穿RDG，最终到达RDSH应用。

　　提供单点登录体验的一种方法是使用加入域的RDG服务器。这里的问题是需要将一个Windows域扩展到DMZ的网络端口范围太广。所需的端口数量太大通常是执行每三种设计的的限制因素。RDS团队博客记录了这些端口。

　　创建这种设计的过程非常复杂，因此这篇文章读起来可能有些让人困惑。但是要知道，下面三种高级选项的任一种都可用来执行第三种设计：

　　第一种选项在RDG与内部域控制器间打开了足够的网络端口来维护其域成员。

　　为了进一步保证这种配置的安全性，第二种选项取代了DMZ中只读域控制器（Read-Only Domain Controller）的位置。为了维护其域成员，该RODC通过足够的网络端口连接到一个内部DC，RDG使用RODC来认证。

　　第三种选项企图通过在DMZ中使用独立的域和域控制器进行进一步隔离，该DMZ参与到与内部域建立信任关系的林中。然后足够的端口在DMZ DC和一个内部DC间打开，用来支持通过该林信任关系的认证。

　　设计四：DMZ中的反向代理。LAN中的RDG。

　　如果第三种选择看上去像是白费力气，那么它确实是。它还打开了大部门安全人员会关闭的防火墙端口。这也是为什么第四种选择对于那些承担的起的人来说可能是当前行业中的最佳解决方案的原因。

　　第四种选择是在第一种选择的网络设计中添加了一个额外组件。这个额外组件是DMZ中反向代理服务器的定位，还有在路由到LAN内部的RDG之前通过代理的网络流量。这个反向代理服务器可以是微软的Forefront安全威胁管理网关或者统一访问网关，或者支持RDG整合的任意第三方反向代理解决方案排列。

　　作为反向代理，这些解决方案中的任一种都能作为SSL桥接设备运作，用来在互联网和内部LAN间的HTTPS请求上接收和传递。网络数据包在反向代理上终止，检查恶意代码，并在发送到内部服务器之前重建。这个过程启用了内部LAN里加入域的RDG来认证并进一步代理使用内部域证书的用户会话。这就是SSO。

　　一个没那么复杂的RDG

　　当应用程序需要互联网曝光时，RDG的确是非常有用。一个稳固的解决方案只执行一个简单的功能且大获成功，这个内置于Windows Server 2008 R2中的小角色服务可能会是一个聪明的方法。

　　你所需要的是正确的设计。