Azure VM 上的 RRAS 不受支持：设计前先核实

你打开门户，把 Windows Server 2022 部署到某个子网，Remote Access 角色顺利装好。这一顺序只能证明安装程序可用，不能证明 Microsoft 支持该配置。已发布的 Azure 虚拟机服务器软件支持指南把 RRAS 列入 Azure VM 上不受支持的 Windows Server 功能，这是架构决策，不是排障细节。隧道能起来，并不会把部署移进支持边界之内。

下面的讲解从支持页面开始，再向外延伸到需求和替代方案。

从支持页面开始，而不是从实验室开始

在确定任何规模之前，先读 Azure VM 支持指南。它把受支持的产品、角色和功能分开列出，而不是把 Windows Server 当成一个不加区分的整体。注意你计划的工作负载究竟落在哪一行，因为控制台里看着相关的两个组件可能分属不同行。

趁页面还开着，把引文写进设计文档。支持状态是有来源的事实，无法引用它的设计评审会被手握演示的人驳倒。

把操作系统支持与角色、功能支持分开

同一份指南把 Network Policy and Access Services 列在受支持角色中，却把 RRAS 单独列为不受支持。这两条说的是不同的事，把它们合并成“远程访问受支持”，正是项目凭误读获批的路径。操作系统受支持，并不说明一个有独立行的功能也受支持。

这条限制也比有时被引用的范围更窄。它针对的是该功能在 Azure VM 内部运行；它并不意味着专用网络不能连接 Azure，也不表示 RRAS 在所有地方都不受支持。一台能正确转发数据包的旧实验环境，是对数据包的证据，不是对支持声明的证据。

在项目余下部分把这两个问题分开：它能不能用，以及它受不受支持。两者往往需要不同答案，有时还需要不同负责人。

写下设计实际必须做到什么

在选替代方案之前，把站点清单变成可衡量产品的要求：

• 分支设备已经在用的隧道协议，以及是否有站点需要动态路由。
• 远端前缀，包括任何需要地址转换而非路由的重叠地址空间。
• 与 Azure 的路由交换，以及路由表每条目的归属。
• 最忙时段必须承受的吞吐量和连接数。
• 站点负责人已同意的故障切换行为，而不只是你能实现的那种。

NAT 是最容易被跳过、却决定整个设计的一项。能建立 IPsec 的设备，其地址转换方式仍可能与它所取代的 RRAS 部署不同，从而改变分支看到的源地址和日志记录的内容。

把清单交给网络负责人，并在任何产品讨论之前确认。含糊的需求会把每次厂商比较容易变成偏好之争。

按这些要求评估替代方案

Azure 的托管连接服务和厂商支持的网络虚拟设备，都要按同一份清单打分。不要因为它们能终止 IPsec 就假定其中任何一个是 RRAS VM 的直接等价物：NAT 模型、路由归属和高可用设计，决定现有站点如何接入、应答从哪里返回。把每个候选方案在纸上对照清单打分，并写下它不满足哪些要求，因为这条记录才让选择日后可复核。

两台设备 VM 前面的负载均衡器本身并不等于高可用。它提供的是前端，不是同步的隧道状态；一次会丢掉所有会话的故障切换，是需要有人刻意做出的设计选择。问清设备厂商支持的高可用模式，以及它是否与向站点承诺的可用性相符。在站点依赖它之前测试切换，并把每个丢失的会话当作发现，而不是意外。

当需求确实简单——一个站点、一个前缀、没有重叠——托管服务通常在运维成本上胜出。当地址转换和动态路由同时在场时，设备路线可能是唯一合适的方案，这也是应当规划更长迁移、而不是保留不受支持 VM 的理由。

如果 RRAS VM 已经在运行

发现它并不是删除它的理由。围绕这台 VM 积累的依赖来规划变更：其他子网依赖的路由、隐藏源地址的 NAT 规则，以及监控已经学会期待其地址的一切。在受支持目标并行设计并验证的同时，保留必需的路由和经过测试的回退路径。

始终把可支持性与技术诊断当作两条独立结论。不受支持的架构里也可能有普通的路由错误，修好那个错误并不改变它的支持状态。两句话都属于报告，谁也不抵消谁。

最后记录支持引文、需求清单、选定的替代方案和切换顺序，作为这次讲解的收尾。审计人员或新团队成员最先要问的就是这四项。