该不该叠加两层 VPN？三个必须核对的条件

在给 VPN 加上第二层加密之前，请诚实回答一个问题：两层都完成各自的工作之后，观察者手里还剩下什么？如果答案是原封不动的内层密文，那么嵌套只买到了时间，别无所获。接下来的内容是判定流程，而不是推荐意见。同一张图在一种部署里是浪费的 CPU，在另一种部署里却是正确答案，而区分两者的只有三个条件。

写下观察者究竟保留了什么

记录对手今天就能保存下来的对象，再记录那串最终会暴露明文的剥离顺序。外层隧道产生密文；当它的保护结束时，剩下的仍是内层隧道的密文，依旧封着。剥掉一层包装并不等于解密。这句话描述的正是嵌套，而它成立的前提是内层密钥仍然存活。一旦两层共享任何东西，时间线就塌缩成同一个事件。

所以有用的产物是时间线，而不是方框示意图。对每一层，写下终止点、密钥持有者、身份校验，以及该假设预计失效的年份。

检验自己主张的实用方法：假设观察者记录一切、永不放弃。在这个假设下，设计仍能在所需寿命内保护载荷吗？如果答案取决于观察者选择不存储流量，那么这个设计就没有答案。

条件一：两层的终止点在不同地方吗？

当两层终止于不同的信任域时，嵌套才划算，例如由服务商管理的 IPsec 网关位于一个在你自有网络内部终止的应用层隧道之前。此时攻破外层得到的密文只有你自己的主机能打开，服务商在任何时刻都看不到明文。把两层放在同一个网关上，这个性质就消失了。谁攻破了盒子，谁就能读到两次解密操作之间的流量，无论图上画了几层包装。

要用实际安装的状态去核对，而不是看设计。在 Linux 上，ip xfrm state 会列出每个安全关联及其端点，这能确定每一层究竟在哪里终止。

条件二：密钥材料真的相互独立吗？

由同一张证书、同一个预共享密钥或同一个厂商库构建的两层，只是多了几步的一层。此时一次凭据泄露就能同时打开两者，一个实现缺陷也能同时消除两者。独立性必须体现在配置里，而不是写在幻灯片上。

这正是混合密钥协商胜过叠加隧道的地方。IKEv2 可以在一次协商中承载多次密钥交换，因此经典群和后量子 KEM 都能喂养同一组会话密钥，而不是彼此包裹。结果是单个安全关联，其密钥同时依赖两个秘密，攻击者必须同时攻破两者。这是有既定组合方式、有文档记录的构造，而两个 VPN 产品的手工堆叠不是。在 strongSwan 上，swanctl --list-sas 会打印每个 SA 协商出的提案，你据此确认实际运行的是什么，而不是你配置了什么。

条件三：数据的寿命超过外层假设吗？

必须维持二十年的层需要二十年的论证。现在记录、以后再解密成本很低，正因如此，经典的外层不能当作包在更强方案外面的临时包装。

要问每个密钥何时可以被恢复，而不是问密码今天有没有被攻破。没有前向保密性的静态密钥交换，会在私钥失守那天被追溯性地攻破。临时密钥协商只在攻击者能趁会话存活时发起攻击的情况下失效，或者算法本身变弱时失效。这一差别决定内层在 2040 年是否还有帮助。它同样决定外层是否改变了什么，因为密钥寿命更短的外层只会成为时间线上最早的那个点。

答案是否定的时候该改做什么

三个条件中任何一个不成立，就放弃嵌套，把精力花在真正承载寿命要求的那一层上。在你们已经在跑的协议里配置混合密钥交换，保持实现更新，并写清楚你依赖的组合方式。在设计文档里写上 ML-KEM 并不是安全属性，FIPS 203 定义的是密钥封装机制，不是你的隧道。

第二层真正挣得其位置的地方，要把它描述为纵深防御，而不是证明。然后核对组合：哪个端点持有哪把密钥、每一侧校验什么身份、拥有控制台权限的运维人员能读到什么。能通过这三问的设计值得多花 CPU。通不过的，只是一张图。

在变更窗口之前，抓取当前的 SA 表和协商出的提案；之后再次抓取并对比，因为唯一算数的证据是设备实际达成的东西。