EC2 Windows：VPN 客户端、VPN 服务器，还是 AWS 网关？

团队需要为运行在 Windows EC2 实例上的应用提供 VPN 连接，找到了兼容的客户端软件，安装完成后却开始追问：为什么 VPC 的其余部分用不了它。安装是成功的，角色却从未被决定。客户机里运行的软件可以是加入他人网络的客户端，也可以是接受其他客户端的服务器，还可以两种 AWS 托管 VPN 产品都不是；每种角色留给你的工作都不同。

症状通常出在角色选错

常见症状是一条能跑通、却解决了错误问题的隧道。VM 里的客户端只给这台 VM 一条出站路径，并不会给你的笔记本、办公室或另一个子网留出入口。VM 里的服务器让别人能进来，但监听器、身份验证和转发从此都归你管。

托管服务把服务运维交给 AWS，把设计留给你。Site-to-Site VPN 通过客户网关和 AWS 网关连接网络，Client VPN 则为远程设备提供托管终端节点。两种情况下，路由、授权规则和身份源都是你的配置，而且两款产品都不会在 Windows 客户机里安装通用客户端。

可能存在四种形态，表格按什么连到什么、以及谁承担运维负担把它们区分开。

要读的是表格里的行，而不是产品名：同一台 Windows 实例，根据里面运行的软件不同，可能落在两个不同的行里。

VM 内的客户端：VM 加入某个网络

出站客户端在安装任何东西之前，都要先核对 Windows 版本、体系结构和驱动程序要求。客户端会改动实例上的路由和 DNS，这可能影响已经在那台机器上运行的服务，包括你用来做远程管理的通道。请记录适配器名称和客户端设置的接口跃点数，因为新接口可能优先于旧接口。如果实例是通过会话管理器而不是 SSH 或 RDP 管理的，请确认客户端连上之后那条通道仍然可用。

在启用客户端之前，先决定它应该承载哪些流量。全隧道可能把管理会话一并接管，把你锁在门外；拆分隧道则可能让实例能访问专用网络，而它的其他流量走另一条出口。测试时要保留第二条管理通道，并记录客户端安装的路由，这样以后的变化才解释得清。

VM 内的服务器：其他客户端连到它

自管服务器意味着监听器、证书或密钥材料、用户数据库和转发规则都由你负责。如果服务器要为其他客户端转发流量，这台实例就变成了路由器，那既需要客户机层面的转发，也需要在 AWS 层面修改路由和安全组。

先从客户机内部探测监听器，再从另一个子网探测一次，然后探测实例为其转发的某台主机。本机服务健康并不能证明转发路径没问题，所以两项结果都要写进变更记录。

托管网关保留的是服务，不是你的访问设计

AWS Site-to-Site VPN 记录了客户网关与 AWS 网关的隧道角色，而买下这条连接并不能替代每一种远程访问设计。Client VPN 记录的是带客户端角色的托管终端节点，但授权规则和目标路由仍然由你负责。AWS 让终端节点及其证书保持运行；谁能访问哪个应用，依旧是你编写并维护的授权规则。

从五个维度比较这些产品：各自扮演什么角色、接受哪些协议、期望什么身份源、流量如何转发、可用性如何交付。论坛帖子里的任何单一吞吐量数字都别当真，因为公开容量会随服务变化。也不要以为一对托管隧道能改变任意客户机客户端的行为。

先定角色，再选产品

写一句话点明方向：这台 VM 加入某个网络、这台 VM 接受客户端，或者由 AWS 网关连接若干已定义的网络。

这句话决定了产品候选清单、软件归属，以及你将来要调试的故障类型。如果需求是远程用户访问某个应用，那么装在应用所在 VM 里的客户端就是错误形态。如果需求是一台 VM 访问合作方网络，那么托管站点到站点网关就比任务所需更重。两个答案都成立，但只有其中一个与你写下的那句话相符。