集中器还是网关？在你的路径上定位 VPN 终结点

两家厂商可能把同一台设备叫作集中器，也叫作网关，而这两个词都不会告诉你流量在哪里被解密。这些标签描述的是部署角色而非协议，而角色在各个方向上都互相重叠。对一次设计评审而言，重要的是终结隧道的设备、它周围的控制，以及解密后的请求所走的路径。从这三点作出判断，规格表上的那个名词就不再是争论的焦点。

两个标签，一个决定

集中器通常指同时接收并管理大量连接的中心系统，这个词暗含规模的意味。网关是更宽泛的说法，指把隧道接上其背后网络的端点，它可以指路由器、防火墙或托管服务。两个词都没有指明某种协议，也都没有承诺特定的功能集。同一台设备可能被两家厂商分别以两个名字出售，术语之争因此永远无法了结。

把标签当作关于预期用途的提示，仅此而已。决定属于你能在配置中核实的功能，而不属于宣传册上的字眼。

找到真正终结隧道的设备

从外向内跟踪一条客户端连接。某个环节接受传输，某个环节认证对端，某个环节为客户端分配地址，某个环节授权目的地，某个环节提供回程路由。这五项功能可以集中在一台设备上，也可以分散在五台上，唯一有用的问题是哪台设备做哪件事。上游的路由器可能只是转发外层报文而从不解密，拓扑图让评审者指错设备的情形恰恰就在这里。

在候选设备本身上确认终结而不是依据图纸。在预期端口上监听的套接字，加上一条已建立的状态记录，比一张网络图更有说服力；两者都没有，则更有说服力。

sudo ss -lunp | grep -E ":500|:4500"
sudo ip xfrm state
sudo traceroute -n -U -p 4500 vpn.example.com

按五项属性判断，而不是按产品名字

五项属性把候选设备区分开来，每一项都可以从文档而非营销材料中得到答案。这个版本支持哪些 VPN 角色，可以使用哪些身份来源，允许多大的转发范围，能维持多少容量，以及发生故障时如何表现。把这五项以书面形式要来，标签对决定就不再重要。

容量是集中器这个标签暗示得最强的一项属性，也是最常被含糊处理的一项。并发上限、单隧道吞吐和总吞吐是三个不同的数字，一台设备可能在一项上很宽裕，在另一项上很吝啬。高可用性是这一对的属性，而不是任何单台设备的属性，它属于恢复的问题。暗示规模的标签并不等于规模的规格。

恢复属于同一场讨论。要问当隧道本身就是坏掉的那个部件时，管理员如何够到设备，因为带外通路是设计决定，而不是附属品。

先看证据，再看标签

当下的服务应当按受支持的角色、身份策略、转发范围、容量和恢复行为来评估，而且答案必须针对你将要部署的那个版本。历史综述可以解释集中器这个词为什么存在，但它无法告诉你当前版本支持什么。Cisco VPN 概览正因如此才是有用的术语背景，而把它当作当前功能清单，正是一次设计评审走偏的方式。

然后端到端核实一项主张。挑出最重要的属性，比如单隧道吞吐或切换时间，问的是测量方法而不是那个数字。就设备实际暴露了什么做一次快速的本地检查，是合理的起点。

sudo ip xfrm state | grep -c '^src '
sudo swanctl --list-sas

在 Linux 上，第一行统计的是安全关联，而一条隧道通常有两个，每个方向一个，所以在与隧道数量主张作比较之前，先把数目减半。在 strongSwan 主机上，第二行直接列出隧道名称。统计套接字不能替代这一点：IPsec NAT-T 让所有隧道共用同一个 UDP 4500 套接字，因此在该端口上统计套接字只得到零或一，无论存在多少条隧道。这两行都不是吞吐测量，也都不能预测负载下的行为。它们给你的是该去追问的单位，而能说清方法的厂商有规格，说不清的只有宣传册。

把路径写下来，标签就不再重要

把架构描述成一份带责任方的功能清单：终结、认证、地址分配、授权、回程路由、日志与恢复。这份描述能经受产品改名、更换厂商和被收购，而这些都不会去更新你的图。

每季度对照一次真实的客户端会话复核，因为某个功能可能在没人改图的情况下就挪了位置。标签会继续变化，而责任方清单仍将是真正解释这张网的东西。