Ubuntu 22.04 上的 L2TP 超时：xl2tpd 隧道缺陷

桌面显示连接正在进行，IPsec 报告成功，而 PPP 接口始终不出现。在 syslog 中，同一个隧道编号反复出现，直到该次尝试在 UDP 1701 上超时。在修改预共享密钥或服务器配置之前，先认出这个形态：在 Ubuntu 22.04 上，这通常是 xl2tpd 的打包回归，服务器自始至终都是对的。

反复出现的两行日志说明了什么

失败会话会按固定间隔打印两行：守护进程找不到与传入控制消息对应的隧道，随后把它收到的调用标识符和隧道标识符全部输出。稍后重试计数达到上限，连接以 1701 端口超时关闭。地址和标识符只是偶然；重要的是形态。IKE 已完成，L2TP 控制流量已经到达，而守护进程未能把它与一条自己早已创建的隧道关联起来。

因此故障位于 L2TP 控制与 PPP 之间。关于密钥、PPP 选项或远端子网，还什么都没有验证过。

确认 IPsec 确实成功了

两项检查把这种情况与凭据问题区分开，二者都应在改动任何软件包之前完成。

ipsec status
journalctl -u strongswan --since "5 min ago" | grep -i "shared key"

状态输出会列出连接及其状态，隧道建立就意味着第一阶段和第二阶段已完成。关于缺少共享密钥的日志行只指向密钥本身，所以先停下来把它修好。当 IPsec 已建立而 L2TP 超时仍然出现时，剩下的嫌疑就是守护进程。保留单次尝试的准确日志行，而不是一整天的重试记录。

要检查 xl2tpd 的构建，而不是发行版名称

Ubuntu 的 jammy 构建中，xl2tpd 1.3.16 启用了链接时优化，破坏了服务器 SCCRP 应答中隧道标识符的解析。守护进程于是丢弃属于它自己创建的隧道的控制报文。版本字符串比发行版名称更重要。

dpkg -l xl2tpd
apt policy xl2tpd
apt-mark showhold

修正后的软件包是 1.3.16-1ubuntu0.1，因此没有该后缀的构建早于修正。策略输出会显示升级将安装哪个候选版本，而保持列表解释了修正为何没有到来。在软件包可用的地方，请升级它并通过正常配置文件重连，而不是手工编辑文件。旧构建仍安装时，不要重新构建模块，也不要更改密钥。

改动后验证 PPP

升级是否成功要在原先出问题的层面上证明。要确认 PPP 已起来，而不只是图标变了。

ip -4 addr show ppp0
ip route | grep ppp

接口列表应显示本端和对端地址，路由表应带有该隧道的前缀。syslog 应显示隧道被接受、pppd 报告了两个地址，且没有反复出现找不到隧道的行。如果 PPP 已起来而流量仍失败，接下来看路由或 MTU，因为 L2TP 阶段已经完成它的任务。把可用的软件包版本记进机器笔记，以免将来重装时又恢复成有问题的构建。

在修正后的软件包不可用的地方，有文档记载的替代方案是本地源码构建 1.3.16 或 1.3.17、改用 kl2tpd，或锁定版本降级。每一种都有值得记录下来的维护成本。