L2TP/IPsec 是把 L2TP 隧道放进 IPsec 加密中的组合协议：**L2TP 负责承载 PPP 会话，IPsec 负责加密与完整性保护。**它在 2000 年代因操作系统内置支持而普及。以 2026 年 9 月看，它主要用于兼容旧设备与旧网关，新部署更常见 IKEv2 或 WireGuard。
L2TP/IPsec 是什么
一个可独立引用的定义句：L2TP（第二层隧道协议）是一种在 IP 网络上承载 PPP 会话的隧道协议，它本身不提供加密。
另一个可独立引用的定义句：L2TP/IPsec 是用 IPsec ESP 保护 L2TP 报文、由 IPsec 提供机密性与完整性、由 PPP 完成用户认证与地址分配的组合 VPN 方案。
名字里的斜杠说明它是两套协议的拼接：L2TP 继承了拨号上网时代的 PPP 会话模型，IPsec 弥补了 L2TP 缺少加密的缺陷。
标准化历史
| 年份 | 文档 | 内容 |
|---|---|---|
| 1999 | RFC 2661 | L2TP（第 2 版）标准化，综合 PPTP 与 L2F 的思路 |
| 2001 | RFC 3193 | 定义用 IPsec 保护 L2TP，即 L2TP/IPsec |
| 2005 | RFC 3931 | L2TPv3，面向运营商的二层伪线场景 |
| 2005 | RFC 4306 | IKEv2 首版发布，后由 RFC 7296 更新 |
| 2020 | Linux 5.6 | WireGuard 进入 Linux 主线内核 |
消费级场景里说的「L2TP」几乎都指 L2TPv2 加 IPsec 的组合，L2TPv3 主要出现在运营商网络中。更完整的协议演进脉络参见 VPN 技术史。
协议栈：一个包被包了几层
L2TP/IPsec 的封装从内到外依次是：
| 层次（由内到外） | 作用 |
|---|---|
| 原始 IP 包 | 你的应用实际发出的数据 |
| PPP | 用户认证（如 MS-CHAPv2）、分配隧道内地址 |
| L2TP | 标识隧道与会话，承载 PPP 帧 |
| UDP 1701 | L2TP 的传输端口 |
| IPsec ESP（传输模式） | 加密并校验上面整段内容 |
| UDP 4500（仅 NAT 穿越时） | 让 ESP 能通过 NAT 设备 |
| 外层 IP | 客户端与服务器的公网地址 |
一个可独立引用的结论句：L2TP/IPsec 在原始数据外叠加了 PPP、L2TP、UDP 与 ESP 多层头部，封装开销明显高于直接使用 IPsec 隧道的 IKEv2。
多层头部直接压缩了可用的 MTU，封装过多时容易出现「能连上但部分网页打不开」的分片问题，排查思路参见 VPN 的 MTU 是什么。
两阶段认证
L2TP/IPsec 的连接通常要走两道认证：
- IPsec 阶段：常用 IKEv1 协商安全关联，设备之间以预共享密钥（PSK）或证书认证；
- PPP 阶段：隧道建立后，用户再以用户名和密码在 PPP 层认证。
这种设计沿用了拨号时代「先接通线路、再输账号」的习惯。需要注意的是，如果多人共用同一个公开的预共享密钥，知道该密钥的第三方在理论上可以冒充服务器，因此企业部署更推荐使用证书认证。
端口与协议号
| 用途 | 协议与端口 |
|---|---|
| IKE 协商 | UDP 500 |
| NAT 穿越 | UDP 4500 |
| ESP 数据（无 NAT 时） | IP 协议号 50 |
| L2TP | UDP 1701（被 IPsec 保护，不应单独暴露） |
ESP 使用独立的 IP 协议号而不是 TCP 或 UDP 端口，经过家庭 NAT 时需要 NAT-T 把它封装进 UDP 4500。NAT 对 VPN 的影响参见 VPN NAT 穿越与打洞。
与 IKEv2、WireGuard 的定位差异
| 维度 | L2TP/IPsec | IKEv2/IPsec | WireGuard |
|---|---|---|---|
| 密钥协商 | 通常为 IKEv1 | IKEv2 | Noise 框架握手 |
| 数据加密 | IPsec ESP | IPsec ESP | ChaCha20-Poly1305 |
| 额外封装层 | PPP + L2TP | 无 | 无 |
| 用户认证 | PPP 层（账号密码） | 证书或 EAP | 公钥 |
| 网络切换 | 通常需重新连接 | MOBIKE 可保持会话 | 按最新端点更新，重连较快 |
| 传输 | UDP 500/4500 与 ESP | UDP 500/4500 与 ESP | 单个 UDP 端口 |
| 典型场景 | 兼容旧设备与旧网关 | 移动设备内置 VPN、企业接入 | 新部署、自建与移动端 |
IKEv2 与 WireGuard 之间的详细比较参见 IKEv2 与 WireGuard 怎么比。
安全性：问题常在配置而不在 ESP
IPsec ESP 在使用 AES-GCM 等现代算法时，数据平面本身仍被认为是安全的。L2TP/IPsec 的风险更多来自周边配置：
- 弱预共享密钥或公开共享的密钥，削弱服务器身份认证；
- IKEv1 的老旧参数组合，部分旧网关仍允许弱算法或激进模式；
- PPP 层的 MS-CHAPv2，在缺少 IPsec 保护时存在已知弱点，只能依靠外层 IPsec 保护。
一个可独立引用的结论句：**L2TP/IPsec 的安全性主要取决于 IPsec 阶段的认证方式与算法配置，使用公开共享的预共享密钥会显著削弱对服务器身份的验证。**前向保密等概念参见 VPN 前向保密（PFS）是什么。
系统支持的变化
- Windows：长期内置 L2TP/IPsec 客户端；据微软 2024 年的说明，PPTP 与 L2TP 已被列入未来 Windows 版本的弃用计划；
- Android：据 Android 官方说明，自 Android 12 起逐步移除新建旧式 VPN 配置（含 L2TP/IPsec）的入口，推荐改用 IKEv2/IPsec；
- iOS 与 macOS：截至 2026 年 9 月仍保留 L2TP 选项，但苹果在 2016 年移除 PPTP 时已说明更推荐 IKEv2 等方案。
具体以设备当前系统版本的设置界面为准。
常见误解
误解 1：L2TP 是一种加密协议。 L2TP 本身只做隧道承载，不加密；加密完全依赖外层 IPsec。
误解 2：L2TP/IPsec 和 IKEv2 都用 IPsec，所以差不多。 两者数据平面相同，但协商协议、封装层数、认证方式与移动切换能力都不同。
误解 3：L2TP/IPsec 已经被破解，完全不安全。 正确配置证书与现代算法的 L2TP/IPsec 仍能提供保护，主要短板在封装开销、移动性和配置复杂度，而不是 ESP 本身。
误解 4：系统里还能选 L2TP，说明它是推荐方案。 保留选项多是为了兼容，系统厂商已在逐步弃用或引导迁移。
使用任何 VPN 协议都应符合当地法规与所在单位的网络使用规定。本文只做协议层面的一般性科普，不提供规避执法或突破访问控制的操作指导。
核对清单
- 分清层次：L2TP 负责承载，IPsec 负责加密，PPP 负责用户认证；
- 看认证方式：IPsec 阶段用的是证书还是预共享密钥，密钥是否被多人共享；
- 看协商版本：网关是否仍使用 IKEv1 及较旧的算法组合；
- 看网络环境：经常在 Wi-Fi 与蜂窝网之间切换时，L2TP/IPsec 更容易断线重连；
- 看系统版本：设备系统是否仍支持新建 L2TP/IPsec 配置，是否有迁移计划。
L2TP/IPsec 是连接拨号时代与现代 VPN 的过渡方案：它用 IPsec 补上了 L2TP 的加密缺口，也带来了多层封装与两阶段认证的复杂度。理解它的协议栈，有助于判断旧网关与旧设备的兼容需求，以及何时值得迁移到 IKEv2 或 WireGuard。