L2TP 连接成功但 PPP 协商失败：问题出在哪一阶段？

IPsec 隧道已建立，连接却仍然中断。先按顺序读完 LCP、认证和 IPCP，再动共享密钥或账号。

IPsec 隧道建立起来，客户端显示已保护的対端，随后连接在数据到达私有子网之前就断掉。这段空白是 PPP 在做自己的事：链路选项、用户认证和地址分配都发生在加密隧道存在之后。第一阶段交换成功，并不提供密码或内部地址。按顺序读各阶段，故障通常会自己报出名字。

隧道只是第一层

L2TP 在 IPsec 保护的隧道里承载 PPP 帧，这意味着在数据包被路由之前，必须有两个独立的协商成功。外层协商证明两端在密钥和身份上达成一致。内层协商决定链路参数、用户是否通过认证，以及客户端拿到哪个地址。

PPP 内部的故障，在每个只显示一个状态灯的客户端看来都像隧道坏了。把它当作隧道问题，就会重签密钥、重启服务，最后替换一个本来就没错的共享密钥。有用的区分很便宜：如果対端交换已完成，客户端进入了用户名提示或认证阶段，隧道就是好的。那之后的一切都属于 PPP。

读最后一个成功的阶段

顺着日志往前走，停在第一个没有完成的阶段。先来 LCP，然后是认证，再是 IPv4 参数的 IPCP。

sudo journalctl -u xl2tpd -b --no-pager | tail -n 40
sudo journalctl -b --no-pager | grep -i -E 'pppd|lcp|chap|ipcp'
ip -4 address show ppp0

LCP 超时意味着两端从未就基本链路选项达成一致，这属于配置文件不匹配或内层协议被拦截，而不是密码错误。明确的认证拒绝是相反的情况：链路起来了，有一端拒绝了凭据。认证成功后的 IPCP 超时指向地址池或服务器策略。每一种都有不同的负责人和不同的修法，所以阶段比最后的错误文本更重要。

在工单里把日志片段和阶段名称放在一起。没有阶段边界的粘贴尾段会邀请下一位读者去猜，而在这里猜要花一个小时。

客户端与服务器之间的一致

两端必须接受同一种认证方式，而保存的配置文件可能请求了服务器在上季度就停用的方式。受管部署还藏起了服务器一侧，那里的拒绝原因通常是记在用户名下而不是设备上。

只启用一种受支持的方式，而不是保留每一个旧选项，因为提供五种方式的客户端会掩盖究竟哪一种失败。向管理员索取服务器侧的策略和确切的拒绝原因，这不需要任何人公布密码。为救一个客户端而启用的旧方式，往往会蔓延到每一个复制了该文件的配置。

验证地址，而不是登录

登录完成并不等于可用的会话。IPCP 协商内部地址，而地址池耗尽或策略拒绝该客户端时，仍然可能留下一条连上却无路可走的隧道。

ip -4 address show ppp0
ip route get 10.52.9.1
ping -c 2 10.52.9.1

先查内部地址，再查你真正需要的那个资源的路径和解析器。内部地址不是网站报告的公共出口，把两者混为一谈会让人去找并不存在的泄漏。先用地址测试私有资源，再用名称测试，这样 DNS 失败就不会被误认为路由失败。

把阶段、方式和地址写进一条记录并注明日期。如果同一个账号一个月后又失败，那条记录就是五分钟的检查和一次全新排查之间的差别。不同阶段的失败是不同的故障，即使客户端只弹出一个对话框。

相关文章