L2TP 配置文件的哪一层真正断了

沿着协议栈往下查，而不是在设置页面里横向乱转: IPsec 协商，然后是 L2TP 控制，然后是 PPP 认证，最后是地址和 DNS 分配。每一层都有自己的错误特征和自己的可能原因。在用户认证处失败的配置文件，已经通过了三条检查，而更早超时的配置文件从未走到那里。这个顺序才是首先要确定的东西。

同一个协议名掩盖了四场不同的对话。

先给这一层命名，再改设置

IPsec 建立失败指向共享密钥、算法或对端身份。其后 L2TP 控制失败则说明问题出在隧道层本身，这是更窄的范围。PPP 认证失败会点名账户或认证方式。认证之后的地址或 DNS 失败意味着传输通了，而配置交换没有通。

记录客户端版本、操作系统版本和运营商文档中的配置。没有这三样，任何改动都只是猜测，可能顺手把别的东西改坏或者碰巧改好。

把配置文件和当前客户端对比

保存的配置文件可能带着当前客户端不再接受的共享密钥、认证选项或端点。有些平台已经彻底弃用或移除了 L2TP/IPsec 支持，而更新过的客户端可能在服务器毫无改动的情况下放弃旧的 IKE 行为。把你的保存值和运营商当前文档里的要求对比，而不是和一年前能用的东西对比。两份文档之间的差距，通常就是答案所在。

缓存的密钥或被改名的账户通常只需要一次普通的配置文件更新，这两项在任何重新设计之前都值得先排查。它们是最便宜的修法，应当在任何架构层面的动作之前被排除。

旧选项不会因为被打开就回来

关闭校验并不能修复信任链的问题，而仅仅因为某个论坛帖子提到就打开某个算法，也证明不了服务器接受什么。弱 IKE 提案通常是因为正当理由才被从客户端移除的，重新打开其中一个只会造出比原来更糟的连接。更弱的隧道不是修复，而是同一个症状下的新问题。正确的问题是运营商现在支持什么。

「全都打开」式的修复改动的东西远多于实际的故障，还让你说不清到底是什么修好的。

把迁移当成一个项目

如果部署已经不再支持所需的客户端，就和运营商一起规划替换，而不是保留一个没有记录的例外。要把访问要求、身份、DNS 记录和路由一并带过去，因为一次新的握手本身不会重建其中任何一项权限。那些正是一条能用的连接在默默依赖的部分。在确认恢复之前，安全地保留旧配置文件，然后到真正管理这些凭据的地方把它们停用。把它们留在原处，正是一条旧路径在所有人都以为它已经关闭之后仍然可用的原因。

迁移也是把「这个配置文件当初是干什么用的」写下来的时机。否则下一个人继承到的就是一条能用却毫无解释的连接。

检查层级、客户端版本和运营商当前的要求。然后判断这到底是一次修复还是一次替换。