AWS Client VPN 还是 Site-to-Site：先看谁发起连接

决定这件事的是四项检查，没有一项是协议名称。谁发起连接、AWS 认证什么、连接以什么方式接入你的网络，以及随之而来的路由与策略。按顺序回答这四项，产品选型通常自然就有了答案；等买完方案再回答，你就是在为一条只解决半个问题的隧道辩护。四项检查没有一项要求你先挑密码套件，所以从协议出发的设计，往往说明需求从来没被写下来。

每一项检查都要针对你实际要用的端点、客户端和地址族来做，而不是针对类别。托管型 VPN 产品与它们看起来相似的 OpenVPN、IPsec 组件并不相同。

第一，谁发起连接

如果要用访问权限的是笔记本、手机或某一位管理员的工作站，连接就从远端设备发起，方案属于远程客户端接入。如果要用访问权限的是路由器背后一整片机器的分支机构，连接就从那台路由器发起，方案属于网关到网关。大多数情况靠这一项检查就能定下来，而当厂商的演示材料已经把话题框在密码套件上时，人们跳过的也正是这一项。

如果你说不出是谁发起连接，就停在这里。想用一条隧道同时覆盖两种情况的设计，最后往往变成一段假装自己是网关的客户端会话。

第二，AWS 认证什么

在 Client VPN 里，AWS 认证的是所配置的客户端或用户身份：证书、目录或联合身份，取决于具体配置。在 Site-to-Site VPN 里，AWS 认证的是网关对端身份。这个差别不是表面文章。一种模型靠增加用户、吊销其凭据来扩展，另一种靠信任单台网关背后的一切来扩展。

网关认证并不等于认证它背后的每位员工或每个应用，所以即便隧道本身可信，应用身份和资源级访问权限也要保留。路由器持有合法对端身份的分支机构，不应被自动读成那栋楼里每张办公桌都被授权了。

第三，连接以什么方式接入

Client VPN 通过 VPC 子网关联或受支持的直连 Transit Gateway 挂载来接入。Site-to-Site VPN 接入 AWS VPN 目标，通常是虚拟专用网关或 Transit Gateway。Client VPN 架构指南记录了 Transit Gateway 这一选项，而它的存在既不会把笔记本会话变成分支机构网关，也不会取消上面说的客户端认证与授权。

在设计路由之前，先确认你的账户和区域真正支持哪一种挂载，然后再确认那个挂载归谁所有。文档里有、却落在你配置不了的网络上的选项，不算选项。

第四，随之而来的是哪些路由与策略

Client VPN 带来的是客户端连接管理，以及针对你放行的目标网络的授权规则。已连接的用户仍然需要通往目标端点的预期路由、允许它的授权规则，以及资源本身要求的访问权限。Site-to-Site VPN 在客户网关所代表的网络之间转发，按设计使用受支持的静态路由或 BGP，因此分支机构路由器背后的单台机器不必各自登录客户端。

不要往任何方向从类别推断出未受支持的行为。远程接入 VPN 并非普遍无法承载返回流量或支持网关式布置，IPsec 也不会被 NAT 自动阻断——AWS 记录了 NAT 穿越与客户网关的要求，真正的约束是受支持的网关配置。在要求建立由客户端方向发起的连接、或把某个局域网放到一条会话背后转发之前，先核对你所用端点的限制。同样的谨慎也适用于地址族：在 IPv4 上能通的端点并不意味着有 IPv6 路径，所以要确认你的客户端或网关实际协商的是哪个地址族。

Site-to-Site VPN 每条连接给你两条隧道，这份冗余是设计工作，而不是可以直接假设的功能。客户网关的运行、路由故障切换和测试覆盖都要规划；把一段笔记本会话跟一个抽象的 VPN 服务器相比，对两者都证明不了什么。

两种设计交汇的地方

这两项服务并不互斥，常见的生产形态是两者并用：员工走 Client VPN，分支机构网络走 Site-to-Site，并在需要互通的目标之间配置明确的路由和访问策略。表格只是四项检查的回顾，不能代替把它们跑一遍。

有一件事两种产品都替代不了：面向某个应用的 TLS，而该应用的加密要求延伸到了 VPN 端点之外。如果你的合规边界止于应用，隧道只是传输通道，证书仍然是那个控制点。

在设计评审之前把四个答案写下来，每条一行。当其中两条互相冲突时——比如一个按用户认证的客户端设计，配上分支机构量级的路由需求——这个冲突本身就是发现，现在看到比切换时才看到便宜得多。