Windows VPN 网关：三项职责，三位负责人

只要有人说 VPN 服务器，三件事就会被捆在一起：终止加密隧道、在网络之间搬运数据包，以及可选地改写地址。在 Windows 上，即使一台机器包办三件事，它们也分处协议栈的不同部分。每件事都有自己的输入和各自的失败方式，而且都可以交给不同的产品。在纸面上把它们拆开，是让小规模部署保持可理解的最便宜办法。

可读的设计会为每一条流指定负责人，而不是把机器描述成一个角色。

终止、转发、转换

在 Windows 原生场景中，隧道由 RRAS 处理：它验证用户、从地址池分配地址，并决定允许访问哪些目标。另一种 VPN 产品也可以拥有监听器和虚拟适配器，把已解密的数据包交给 Windows 转发。微软的 Remote Access 文档把 VPN、站点到站点和路由三种角色分开，安装路由角色并不会产生第二个 VPN 身份。再加一个 VPN 应用，也不会把它的适配器交给现有的每一项网关功能。

转换是第三件事，也是最可有可无的一件。它位于转发之后，改变远端网络看到的源地址。是否需要它，取决于目标网络愿意接受什么作为源地址，而不是取决于这台机器被叫作 VPN 网关。

谁拥有适配器和地址池

当多个产品共用一台主机时，有四样东西必须各自只有一个负责人：监听端口、适配器生命周期、客户端地址池和路由。最麻烦的是适配器，因为 VPN 服务可能动态创建它，并在断开时销毁它。把那个接口当作固定命名的网卡来对待、并针对它的名字写规则，只能撑到下一次重连。请使用产品支持的集成点，而不是把接口名硬编码。

地址池是第二处冲突。两个产品发放相互重叠的地址段，会产生看起来正确、实际什么也送不到的转发。把地址池和路由写进同一份文档，这样改了一边就能对着另一边看见影响。

保留源地址，还是改写

保留客户端的源地址，就保住了按用户区分的可见性：日志、配额和防火墙规则都能把不同用户分开。代价是目标局域网需要一条指回网关的回程路由，而且得有人维护它。用 NAT 改写源地址，就免掉了这个要求，同时也免掉了可见性。要有意识地做选择，并写清楚改写隐藏了哪些信息。

访问私网、访问互联网，以及在网关上终止的连接，是三条不同的路径。它们并不都需要同样的处理。

用一句话描述这条流

一句话应当能描述设计：这项服务接纳哪些客户端、这条转发策略放行哪些资源，以及回程路径如何让整条流闭环。如果这句话要靠第二层 NAT 才成立，通常说明前面的部分还没敲定。主机同时也是共享的故障边界和信任边界，所以一次路由改动可能同时影响用户访问和管理。要为后者留一条独立的恢复路径。

在配置旁边维护一份角色清单：哪个产品负责终止、哪个负责转发、哪个负责转换，以及每一环谁能改。正是这份清单让下一次变更可被评审。

当这句话变得含混时，再加一层地址转换很少能让它更清楚。去掉一层往往可以。