TLS VPN 与 IPsec：值得核对的五个字段

按协议家族给 TLS VPN 和 IPsec VPN 排名，回答的是一个没人提出的问题，而且通常会引用两个家族多年前就不再使用的构造。审查者真正能评估的，是协商出来的保护、对端身份、客户端模型以及暴露的服务。这四点在部署中都看得见，没有一项能从产品标签推出来。要求五个字段，对话就会变得具体。

五个字段，标签不在其中

第一个字段是受支持的软件版本，因为没有版本的协议描述只是宣传册。第二个是协商出的协议版本，它决定哪些构造根本可用。第三个是保护套件，第四个是对端与用户双方的认证方式，第五个是产品在准入后授予的访问范围。

SSL VPN 这个标签至少涵盖三种不同产品：完整网络客户端、应用代理，以及基于浏览器的旧式门户。它们暴露的服务不同，失败方式也不同，所以标签无法代替范围字段。

认证加密究竟改变了什么

TLS 1.3 要求认证加密，这会把较旧的 MAC-then-encrypt 构造从协议中移除，而不是留作可选项。IPsec ESP 同样早就有认证加密套件，AES-GCM 在其单独的 RFC 中定义。两个家族的保证都来自协商出的套件，而不是家族名称，这正是字段清单从版本开始的原因。叫不出套件名字的审查者，就没有可评估的东西。

所以历史上的比较会误导人。固定使用旧 TLS 版本加 CBC 套件的部署，与运行 TLS 1.3 加 AEAD 套件的部署，并不是同一种安全态势，尽管两者都是 TLS VPN。同样的分裂也存在于 IPsec 一侧，介于现代 ESP 套件与旧式组合之间。

要读协商出来的值，而不是你打算配置的内容。下面的命令显示一个在线端点和一条在线隧道实际达成了什么。

openssl s_client -connect vpn.lab.example:443 -tls1_3 -brief
ip xfrm state
swanctl --list-sas

如果端点不愿协商 TLS 1.3，那是发现，而不是偏好。如果隧道列出你没有预料到的套件，重要的配置是对端选中的那个，而不是模板里的那个。

对端身份是另一个问题

没有经过验证的对端，加密只是把流量挡在旁观者之外，却把它交给任何回应了连接的一方。对端认证要问：期望哪个身份、用什么信任材料来验证它、答案不匹配时客户端如何表现。证书链、固定密钥和预共享秘密是三种不同的答案，运营成本也各不相同。

然后对用户或设备问同样的问题。只认证机器却放行任何用户的网关，或者反过来的情况，都有具体的姿态，应该写下来而不是假定。准入后应用的资源权限属于同一个字段，因为认证不是授权。

保留主机名和证书检查，比登录窗口是否眼熟更重要。配置成忽略验证的客户端，已经去掉了唯一能把你的网关与逼真仿冒区分开的一步。

产品暴露的边界

无客户端门户通过网关代理选定的应用操作，所以用户到达的是接口而不是网络。全隧道客户端承载其路由和过滤策略所选中的一切，那是大得多的面。按协议强度比较两者，会漏掉攻击者能通过它们到达什么的差异。一个暴露应用接口，另一个暴露被路由的网络，两者需要不同的审查。

要问暴露的是哪个服务、授权了哪些操作，以及网关自身在监听什么。管理与用户门户在同一地址可达，就是部署层面的发现，任何协议选择都补偿不了。

按应用划分范围会进一步收窄暴露面，也会改变隧道断开时的失败行为。假定全隧道可达的设计，会以按应用设计不了解的方式出问题，支持负担随之而来。

决定故障结果与生命周期

认证或保护不可用时会怎样，是属于审查范围的政策决定。被阻断的结果与未告知的直接回退后果不同，而这一差异在功能清单里看不到。把预期行为写在它所保护的资源旁边。

要把网关的补丁与支持生命周期、已启用的外部功能，以及客户端的更新路径都写进去。正确的协议选择并不能让部署糟糕的服务变安全，大多数事故就活在这个缺口里，而不是套件里。

把五个字段、故障策略和生命周期负责人写在一页上。那一页才是审查；协议家族的比较只是意见。