IKEv2 与 L2TP/IPsec：你的服务器实际跑的是哪个配置？
同一个标签背后是两套栈、三种密钥，以及地址变化时不同的表现。先分清层次，再比较菜单。
这两个名字并排放在同一个下拉菜单里，很容易让人以为是在两个对等选项之间做选择。它们并不对等。L2TP是一种本身不带机密性的隧道协议，L2TP/IPsec 服务里的保护来自包在它外面的 IPsec 层。IKEv2 直接协商一个 IPsec 关联，没有“隧道套隧道”这一步。搞清楚服务器提供的是哪套栈，决定了配置、提示，以及笔记本换网时会发生什么。
两套栈，客户端里只有一个标签
L2TP 通过 UDP 把点到点会话送到 1701 端口，加密交给包住它的一方。把它和 IPsec 配对，就得到两层：保护路径的 IPsec 关联，以及里面承载用户链路层帧和 PPP 认证的 L2TP 会话。
IKEv2 先建立控制关联，再建立一个或多个保护流量的子关联，全部落在 UDP 500 和 4500 上的同一套交换里。没有内层隧道协议，也没有 PPP 协商。
凭据：三个秘密分布在三层
支持时间大多耗在这里。一个 L2TP/IPsec 配置可能同时要 IPsec 层的预共享密钥，以及内层 PPP 会话的用户名和密码，而这两者由不同组件校验。共享密钥属于整个网关，所以它不识别任何人；它只证明对端知道一个秘密。
IKEv2 常用证书，或用 EAP 加用户名和密码，也可以用预共享密钥。这些选项与 L2TP 的那一对不能互换。重置密码能修好被拒绝的 EAP 登录，却对过期的客户端证书毫无用处；把账户密码重敲多少遍，也满足不了一个错误的网关密钥。遇到你没预料到的提示时，先问运维它属于哪一层，再猜。
| Question | L2TP/IPsec | IKEv2 |
|---|---|---|
| What encrypts the traffic | A wrapping IPsec association | The child association |
| Ports you must permit | UDP 500/4500 and UDP 1701 inside | UDP 500 and 4500 |
| Typical secrets | Gateway PSK plus PPP credentials | Certificate, EAP, or PSK |
| Address change | Tunnel breaks, reconnect needed | Can migrate with MOBIKE |
MOBIKE 改变了什么，没改变什么
当两端都支持 MOBIKE 时，IKEv2 可以把关联迁移到新地址，这覆盖了笔记本从 Wi-Fi 切到手机热点却不拆掉安全关联的情况。
但它并不能让每个应用在这次迁移中活下来。传输流仍然换了地址，绑在旧地址上的套接字仍然会断，把流量钉在某个接口上的策略仍然可能把它丢掉。要测你真正执行的那次切换，无论是离开某个网络、从睡眠唤醒，还是长时间空闲后回来，并且看应用，而不是看“已连接”标签。
区分两者的故障形态
一个连到网关后就停住的 L2TP/IPsec 配置，通常卡在两个提示之一：共享密钥，或 PPP 凭据。密钥错了，客户端日志里往往什么有用信息都没有；密码错了，会产生明确的认证拒绝，这个差别告诉你去哪里找。
当身份或证书不对时，IKEv2 配置失败得更早、更响，因为控制关联根本建不起来。如果关联建起来了而流量仍然不通，问题已经转到子关联、流量选择器或路由上，改凭据不会有帮助。
各自还适合哪里
L2TP/IPsec 之所以还在，是因为几乎每个客户端都有它，也不用装额外软件，这对在你不管的设备上干活的外部人员很重要。代价是多一层、共享密钥模型，以及每次地址变化后都要重连。
IKEv2 更适合受管设备：证书身份、更干净的移动性，以及只有一套关联要推理。它在客户端老旧时也失败得更硬，所以围绕它设计之前，先确认平台支持的认证方式。
测试你拿到的配置
先从服务器侧确认模式，再挑与它匹配的客户端配置。用为该配置签发的确切主机名和凭据去测，并且验证内网资源，而不是公网站点。
如果能连上却什么都加载不出来，说明隧道是通的，路由、DNS 或流量选择器不通。此时换协议只会让诊断重新开始，而不是往前走。