为什么 SSL VPN 与站点到站点 VPN 并非对立
SSL VPN 与站点到站点描述的是两条不同的轴：谁接入网络，以及隧道如何建立。把两者并列而谈是范畴错误。
请两位管理员描述同一个 VPN，一位可能回答“SSL VPN”，另一位却说“站点到站点”，仿佛两者是菜单里互相竞争的选项。它们回答的是不同的问题，把二者当作替代方案，就会产生无法调和的比较。一个标签说明连接的是哪些端点，另一个说明端点之间由什么承载流量。把两条轴分开，争论的大部分就会消失。
两个标签，两个独立的问题
拓扑回答的是“谁接入什么”。远程访问设计把单个用户或设备接入网关，通常配有按用户区分的身份和地址池。站点到站点设计通过网关连接两个网络，因此值得关注的身份是对端网关，而不是坐在键盘前的人。这是两类不同的运维问题，从地址规划一直到凌晨 2 点谁有权撤销访问。
机制回答的是“隧道如何建立与认证”。带 IKEv2 的 IPsec、在内部承载 IP 的基于 TLS 的产品，以及面向浏览器的应用门户，都是机制选择，各自有自己的协商、密码套件和故障模式。它们都不隐含某种拓扑，拓扑也不会选择机制。
把两条轴放进一张表，混乱就变得可见，因为表格的每个格子都能填。表格做不到的，是告诉你厂商实际交付的是哪种组合，因为产品名称把两条轴压成了一句营销话术。
范畴错误从何而来
厂商多年来把“SSL VPN”当作“IPsec VPN”的对立面来卖，使机制比较看起来像拓扑选择。这个说法本身也已过时，因为当前设计使用受支持的 TLS 版本，SSL 之名主要作为产品类别留存下来。
| Axis | Question it settles | What it cannot tell you |
|---|---|---|
| Topology | Whether users join a gateway or two networks join each other | Which protocol carries the traffic, or how peers prove identity |
| Mechanism | Which protocol suite builds the tunnel and negotiates keys | Whether the endpoints are people, devices or routers |
| Access surface | Whether the client sees a routed network or a set of published applications | Which topology or mechanism is underneath the portal |
| Authentication | What proof each side presents, and to whom | Whether the traffic is later authorized per resource |
同一种压缩还派生出两个相关迷思。其一是 IPsec 就等于站点到站点；IKEv2 同样是为客户端到网关的关系设计的，所以单台笔记本也能用 IPsec 接入。其二是基于 TLS 的产品只意味着远程访问；OpenVPN经常用于在两个站点之间承载流量，它的 TLS 使用集中在控制与认证交换上，而不是浏览器会话。
对任何描述都有用的检验：如果换一个词就同时改变了端点和协议，这句话就在混用两条轴。“SSL VPN 对比站点到站点”通不过这一检验，因为前一个词命名的是机制家族，后一个命名的是拓扑。
把部署描述到可以比较的程度
写下四个字段并填好：端点、机制、认证和访问面。分支链路可以读作两个命名前缀之间的一对 IKEv2 网关，采用证书认证，没有用户级门户。远程访问服务可以读作基于 TLS 的客户端：按用户分配地址，登录时要求第二因素，只发布一个内部 DNS 区域。
这些句子之所以可比较，是因为产品名称做不到这一点。两个远程访问设计可以按同一套用户工作流和同一条撤销路径来衡量，两个跨站点设计可以按同一份前缀清单、流量策略和故障要求来衡量。标签只是组织比较，并不取代比较。
术语还有一份公开的依据。IETF 的 VPN 术语文档把包括远程访问和站点到站点在内的若干服务模型，与构建它们所用的机制区分开来，而这正是不断被丢掉的区别。
读协商出来的协议，而不是产品名称
盒子上的标签并不能确定一条运行中的隧道同意了什么。直接在 TLS 一侧询问对端，读取握手产生的协议版本和密码，而不是宣传册上的版本。
openssl s_client -connect vpn.example.net:443 -tls1_3 -brief对 IPsec 网关来说，等效的观察来自实现自身的状态输出，它会报告正在使用的 IKE 和 ESP 提案。无论如何，要点相同：机制这条轴必须从活会话里读，因为客户端和网关可能协商到比两位管理员预想更旧的配置。
ipsec statusall | grep -E "IKE|ESP"此后剩下的问题，是任何标签都回答不了的：还接受哪些协议版本，网关身份如何验证，允许哪些算法集合，谁授权某个用户访问某个资源，以及设备丢失时由什么撤销访问。拓扑图和机制名称是这份清单的开头，而不是替代品。
所以，保留这两个标签，但按它们的本义使用：简短地说明连接了哪些端点、隧道如何建立。一旦用其中一个去排除另一个，这段描述就不再描述任何东西了。