L2TP 调试日志为空？错误很可能在 journal 里

你带调试启动 L2TP 辅助程序，盯着终端，它却停下来了，屏幕上没有任何有用的信息。这不是调试开关坏了。NetworkManager 的 L2TP 连接由四个协同工作的进程组成，只有其中一部分会写入你正在看的终端。其余证据都在 journal 里，只差一个过滤器。

四个进程，两个日志去向

连接从 IPsec 开始，按安装情况是 libreswan 或 strongSwan。接着 L2TP 守护进程——传统上是 xl2tpd，某些构建里是 kl2tpd——负责运行隧道。最后 pppd 在隧道内部处理身份验证和地址分配。

辅助服务协调这些环节，并打印自己的进度。IPsec 守护进程和 pppd 通常通过系统 journal 汇报，所以终端显示连接失败，而原因却在你没打开的文件里。

这种分工也解释了为什么从桌面看，PSK 错误和密码错误一模一样：两者都会导致通用断开，失败的阶段只在各进程自己的输出里可见。这正是 journal 在这里重要的全部原因。桌面上只有一条笼统的消息，背后却有四个可能的作者。

先收集一次尝试，再读顺序

用已知的配置文件和已知的时间复现一次，然后读一个窄窗口，而不是整次启动。一边改设置一边反复尝试，日志会变成无法解释的混合物。

这些命令选出本次启动的参与进程，插件路径值得在你的发行版上确认：

journalctl -b --no-hostname _COMM=nm-l2tp-service _COMM=pluto _COMM=charon _COMM=xl2tpd _COMM=pppd
rpm -ql NetworkManager-l2tp 2>/dev/null | grep nm-l2tp-service

同一次调用里重复的字段取这些进程的并集，从而按时间顺序保持序列。在基于 Debian 的系统上，等价查询是 dpkg -L；关键在于手动运行之前先弄清辅助程序究竟在哪里。

三个条件决定下一步

先读第一个失败的阶段，再据此选择。如果 IPsec 报告提案或对端身份验证失败，隧道根本没建立，改 PPP 密码帮不上忙。

如果隧道建立了而 pppd 拒绝了登录，说明共享密钥本来就没问题，凭据问题在上一层。如果 pppd 协商到了地址，而失败出现在之后，说明两者都正常，剩下的问题是路由、DNS 或服务器自己的策略。

这三个分支几乎覆盖了所有通用断开，决定它们的是哪个进程记录了最后一个错误，而不是哪条错误消息看起来最吓人。

在动调试设置之前，也值得确认装的是哪个 IPsec 后端。为 strongSwan 写的日志选项在 libreswan 运行时毫无作用，而你编辑一个没人读的文件时，连接会一直在同一处失败。

调试模式会留下文件

上游的调试流程用调试开关手动运行服务，这种模式可能在连接结束时把生成的运行时配置文件留在原处。

这些文件包含认证材料：预共享密钥、凭据，或两者都有。把生成的配置复制到聊天窗口是凭据泄露，不是日志摘录。分享任何内容前先删掉秘密行，调查结束后删除目录。把它们当作机密，只提取报告所需的具体行，然后删除，而不是把整个目录贴进工单。

手动实例还必须与正常实例协调。服务已经占用插件时再启动调试副本，会产生两个所有者，日志也会混在一起，这比完全没有调试输出更糟。

之后恢复正常辅助程序

调查结束时，停止手动实例，删除保留的运行时文件，并通过正常路径重新连接，让下一个人看到与实际情况相符的配置。

然后在失败的层验证结果，而不是在桌面图标上：

journalctl -b -u NetworkManager --since -10min | tail -30
ip -4 addr show ppp0
ip -4 route get 10.20.4.10

一个通过认证、获得地址并路由到预期目的地的会话，就是你一直在调试的结果。失败尝试中沉默的终端只告诉你 输出没有写到哪里。