Ubuntu 24.04 的 L2TP 失效：xl2tpd 还是 go-l2tp 守护进程

Ubuntu 24.04 悄悄换掉了 NetworkManager 的 L2TP 插件背后的守护进程。旧路径使用 xl2tpd；新的打包方式引入了 Go 实现，生成名为 kl2tpd 的守护进程。插件会启动已安装的那个，因此升级可以在不碰配置文件和凭据的情况下替换守护进程。故障的全部就在这里：新守护进程不认识的某条控制消息。

插件负责协调 IPsec、L2TP 和 PPP，然后把生成的接口交给 NetworkManager。它本身并不实现 L2TP。

插件是协调者，不是守护进程

network-manager-l2tp 会启动 IPsec 辅助程序、L2TP 守护进程和 PPP，并把该接口接入桌面的连接管理。多年来守护进程一直是 xl2tpd，凡是提到其配置的教程都沿用了这个假设。后来 Debian 打包同时接受两种实现，而 24.04 安装的是提供 kl2tpd 的 Go 版本。配置文件里没有任何字段记录此前运行的是哪个守护进程，所以在消息被拒绝之前，这次替换一直不可见。

两个软件包都装着的机器，运行时仍可能不是你以为的那个。选择由插件决定，而不是你参考的那篇指南。

先读阶段，再选修法

journalctl -b --no-hostname _COMM=nm-l2tp-service _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd _COMM=charon _COMM=pluto

把一次尝试在几个辅助程序之间串联起来，而不要只信桌面通知。那条查询能看出流程停在哪一步，dpkg -l 则显示装的是哪种实现。IPsec 对端建立之后才出现、并且提到控制消息或未知属性的故障，指向守护进程。隧道还没建立就失败，说明根本没走到守护进程。

预共享密钥不匹配会在 IPsec 阶段结束，并点名对端。PPP 凭据问题要等隧道起来才出现，通常带着可读的 CHAP 或 MS-CHAP 拒绝。两者都出现在同一条查询里，但它们是不同的问题。

两条路，而且互不混用

sudo apt install xl2tpd
sudo apt purge go-l2tp

这一对命令先放上 xl2tpd，再移除 Go 守护进程，让插件去选网关所说方言的那套实现。顺序很重要：插件依赖其中一种实现，所以先卸载 Go 包会把插件一起拖下水。第二条路保留 Go 守护进程，换到理解该消息的更新构建，通常意味着维护者的 PPA，而不是归档里的版本。在受管机群里，固定 PPA 比教用户卸载软件包更容易交代。

不要把两者合进一次变更。那样一旦之后出故障，你就说不清是哪一半起了作用，而将来的升级还可能把你刚卸掉的包装回来。

把守护进程的可执行文件、版本和确切消息写进工单。只写“发布后 L2TP 坏了”的报告没人能复现，而点名的属性加软件包版本至少给了他们起点。

它不是的三件事

这不是配置文件的问题，因为同一份配置在 22.04 上对着同一台网关是能用的。也不是缺路由或改了防火墙，那些会在别处失败，证据也不一样。重装插件同样修不好，因为选中的还是同一个守护进程。有用的描述会点名守护进程，以及它拒绝的那条消息。

网关侧修复是另一种正当结局。不再发送该属性的固件能扛过每一次客户端升级，而固定软件包只有在有人记得为什么固定时，才扛得过下一个发行版。

比较两条路时看维护成本，而不是速度。两种都可能有效；只有一种消除了方言不匹配。