摘要

  • RFC 3193 要求用 IPsec ESP 保护 L2TP 的控制包和数据包，但只有当 IPsec 选择器随建隧道过程中选定的地址与端口一起变化时，这种保护才覆盖了正确的流量。
  • IKE 的派生密钥逐包验证的是 IKE 所声明的身份；若 IKE 认证机器、PPP 认证用户，而本机又没有隔离用户流量，那么有效的 IPsec 包仍不能证明是那名用户发出的。

安全隧道常被画成一根密封管道。RFC 3193 展示的却是两套状态机互相递送事实的过程。

L2TP 知道自己正在建立哪条控制连接、使用哪个套接字、承载哪些 PPP 会话。IPsec 知道某个安全关联覆盖哪些地址、协议和端口，也知道 IKE 验证了什么身份。两边都握有必要信息，但任何一边都没有全貌。若它们不交换信息，“L2TP over IPsec”只是一句产品标签。

L2TP 原本并非毫无安全机制。它可以在隧道建立时认证 LAC 与 LNS，PPP 也可以认证客户，并协商加密或压缩。但这些动作没有为之后每个控制包与数据包提供完整性和防重放，也没有给 L2TP 建立可扩展的密钥管理。PPP 加密还能保护内容，却不能保护 L2TP 控制信道，ECP 的算法协商本身也没有受到保护。

因此 RFC 3193 要求合规实现为控制与数据都实现 IPsec ESP，必须支持传输模式和 IPsec 防重放；隧道模式可选。实现必须具备当时 IPsec 要求的算法，包括空加密，但具体选择由运营者决定。这里已经有一条重要边界：支持某种能力不等于部署时已经启用它。

真正麻烦的是流量选择器。IKE Phase 2 通过地址范围、IP 协议和端口描述要保护的流量。L2TP 却允许发起方使用动态源端口，应答方也可在 SCCRP 中选择新端口；早期 L2TP 文本甚至允许应答方选择新 IP 地址。应用还在决定最终套接字，安全层却要先知道自己该保护什么。

RFC 3193 的办法不是放宽成“保护所有 UDP”，而是让 L2TP 把新事实注入 IPsec 过滤数据库。首个 SCCRQ 发出之前，初始过滤器必须已经存在。若尚无可保护该包的 Phase 2 SA，发送 SCCRQ 应触发 IKE 建立 SA；建不成，就必须丢包。隧道的第一项控制动作不能先裸奔、再由后续数据补票。

当发起方确定动态端口，L2TP 把端口交给 IPsec。Quick Mode 完成后，IKE 安装更具体的过滤器，并把它同 SA 关联。在建立阶段，较宽的规则可以容纳应答方可能选择的新端口；隧道稳定之后，残余的建立期 SA 与过滤器便可删除。临时发现能力不应演变成永久范围。

若应答方要更换 IP 地址，规范没有允许它从新地址直接出现，并要求另一端把两者视作同一主体。它必须沿原先受保护的路径发送 StopCCN，以一般错误和 “Try Another” 指示新地址。发起方解析并检查地址格式，注入新过滤器，重新进行 IKE Phase 1 与 Phase 2，然后才向新地址发送新的 SCCRQ。应用意图可以延续，密码关系却必须重新建立。

更换端口走另一条路径。应答方必须在发送 SCCRP 前作出选择，让 L2TP 注入过滤器，并由应答方启动新的 Phase 2。最终规则描述的是谈判真正选中的套接字，而不只是最初的 1701 端口。因此“看见 UDP 1701”既不能证明这就是 L2TP，也不能证明后续整条隧道一直使用同一端口。

入站处理同样要求两个判断。第一，L2TP 必须确认 IPsec 已经解密和／或认证该包，说明它通过预期 SA 而来，不是明文混入。第二，还要检查包的 IP 地址和 UDP 端口是否匹配建立这条 L2TP 隧道时使用的套接字。一个受信任的对端仍可能把受保护的包塞进另一条隧道；密码真实性不能替代应用上下文。

关闭过程则揭示了状态的多重性。PPP 可以用 LCP TermReq/TermAck 优雅结束，L2TP 可以拆除控制连接或借 keep-alive 发现非正常中断，IKE 可以收到 Phase 1 或 Phase 2 删除通知。当 L2TP 隧道删除后，为它存在的 SA 应被删除并发送删除消息；IKE 收到删除时也应通知 L2TP。得到相应确认后，才可安全移除隧道状态与过滤器。

这些动词没有描述一笔原子事务。L2TP 隧道、IKE Phase 1、Phase 2 SA 和过滤器是彼此关联却不同的对象。“VPN 已断开”无法说明是否还有 SA 存活、临时过滤器是否收窄、对端是否确认，或应用是否仍保留一条看似活动的隧道。

封装还改变了可用报文尺寸。PPP 常以 1500 字节为默认 MRU，L2TP 与 IPsec 头部却要从路径容量中扣除。RFC 3193 建议在 LCP 协商前，把隧道出入口 MTU 减去额外头部后的值传给 PPP。如果 IPsec 后来收到更小的路径 MTU，它应把新值存入 SA，并通知 L2TP 反映到 PPP 接口。一个层面发现的现实，不经显式接口不会自动成为另一个层面的现实。

有状态压缩也暴露了类似问题。L2TP 是面向连接的，但在 IP 上并不强制包序。一旦丢包，依赖历史状态的压缩或加密可能让后续一串包都失去同步。规范因此偏好无状态方法。逻辑上有连接，并不等于底层获得可靠、有序的字节流。

最深的边界仍是身份。

PPP 可能在会话开始时认证用户，此后不会对每个包重新认证那名用户。IKE 可能认证机器，并从该身份派生密钥；IPsec 随后逐包验证密钥持有、完整性和重放状态。后一种证明持续而强，但它持续证明的是 IKE 身份。

在多用户机器上，区别会产生真实后果。假设 PPP 登录的是一名员工，IKE 证书属于整台机器。ESP 有效只说明包来自持有机器密钥的一方。若操作系统没有把隧道流量限制在那名员工的进程与会话中，机器上的其他用户也可能利用已经打开的隧道。每包认证并没有神奇地继承 PPP 的用户名。

如果 IKE 支持用户认证，问题可以缩小，却不会自行消失。客户端还必须确保只有那名用户的流量进入这条隧道。用户证书、IKE 认证成功和本地隔离执行仍是三项事实。

证书把控制面移到了签发流程。LNS 可以信任多个 CA，各家撤销检查可能不同。机器证书的价值取决于攻击者冒领它有多难。把用户证书放在智能卡中有助于保护私钥，却可能同“只准获批硬件接入”的机器策略冲突。凭据的载体并不决定组织赋予它的权力。

组预共享密钥更清楚地暴露了身份压缩。远程接入常使用动态地址，而 IKE Main Mode 在收到身份载荷之前就可能需要选出密钥。部署者于是可能给一群用户同一个秘密。知道秘密只能证明属于这群知情者，不能识别特定客户端或服务器；持有者可能冒充 LNS，并进一步攻击旧式 PPP 口令认证。RFC 3193 因此建议不要用组预共享密钥认证 LNS。

Aggressive Mode 较早发送身份，可以按身份选密钥，却暴露身份。证书更适合扩展，却依赖签发、信任和撤销体系。规范没有把这些取舍藏在一个“安全”徽章后面。

强制隧道与自愿隧道又给知识分配带来差异。强制隧道中，客户只把 PPP 帧交给 LAC，甚至可能不知道 LAC 到 LNS 之间存在 L2TP/IPsec。LNS 能读取该 SA 的属性，客户却不能据此证明自己到 LAC 的链路也被保护。双方掌握的信息不对称。

自愿隧道中，客户自己发起 L2TP，能了解直至 LNS 的 SA，与 LNS 对安全服务有较对称的认识，也更容易避免重复的 PPP 加密或压缩。但 LNS 之后的路径仍是另一段。RFC 3193 在开头就划明范围：它不是端到端安全标准。

这也是它的历史意义。它没有把 IPsec 粘在 L2TP 外面便宣布完成，而是规定应用状态何时进入安全策略、安全结果何时返回应用，以及每项身份凭据不能证明什么。隧道之所以可互操作，不是因为某一层拥有全权，而是因为各层只传递自己真正知道的事实。