L2TP 报 NO_PROPOSAL_CHOSEN？先扫描网关

在用户名提示出现前就失败的 L2TP/IPsec 客户端，从未就第 1 阶段达成一致。与其粘贴网上找来的加密串，不如扫描网关的提议集合。

用户名提示始终不出现，客户端报告 NO_PROPOSAL_CHOSEN。此时凭据和预共享密钥都无关，因为两端尚未就如何保护第 1 阶段达成一致。多数人的反应是粘贴一段网上找到的加密字符串。扫描网关能用证据回答同一个问题，耗时也差不多。

这条消息排除了什么

拒绝发生在主模式，早于任何 L2TP 或 PPP 交换，因此既没有查询隧道，也没有查询用户数据库。第 1 阶段协商加密、完整性和 Diffie-Hellman 组。第 2 阶段协商用于数据的 ESP 提议。第 1 阶段的失败无法靠修改第 2 阶段的 PFS 设置来修复，而且 IKE 关联完成也不能证明 ESP 提议合适。

修改语法前先记录后端：ipsec --version。libreswan 与 strongSwan 对同样的算法接受不同的提议写法。

然后用下面的命令结合上下文读取拒绝信息：journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd。

扫描网关的转换集

扫描器直接询问网关会协商哪些转换。先停掉本机的 IPsec 服务，免得探测和你自己的客户端争抢，然后读取 SA 行。把清单当作关于对端的证据，而不是一份可以全盘启用的菜单。

sudo ipsec stop
sudo ike-scan --trans=3des-sha1-modp1024 10.10.10.250 | grep SA=

较老的设备经常提供 3DES、SHA1 和 MODP1024，因为那是产品出厂时的默认值，之后没人重看过。保留扫描的原始输出，它是当天对端提供了什么的唯一记录。如果这已是可得的最强交集，正确的上报方向是网关所有者，而不是让所有人的客户端重新启用弱加密。

在不关闭安全性的前提下匹配交集

只填入扫描结果和你的策略里都出现的转换。下面的示例对应一台在第 1 阶段提供 3DES、SHA1 和 MODP1024 的网关。注意后端的限制：libreswan 4.x 不编译 modp1024 组，所以这适用于 strongSwan，或支持 DH2 的 libreswan 构建。先确认版本，再断定客户端有问题。

Phase 1: 3des-sha1-modp1024
Phase 2: aes256-sha1,aes128-sha1,3des-sha1

结尾的感叹号会钉住单一提议。用它隔离一次测试，然后去掉，好让网关以后能协商更强的方案。

重试前检查守护进程和端口

NetworkManager-l2tp 会启动自己的 xl2tpd 实例。如果系统服务已经占用了 UDP 1701，客户端会退回临时源端口，RFC 3193 允许这样做，但有些服务器会悄悄丢弃。下次尝试前先确认套接字归属。

sudo ss -unlp | grep 1701
sudo systemctl stop xl2tpd.service
sudo systemctl disable xl2tpd.service

过期的生成密钥是另一个安静的原因。下面目录里的文件 /etc/ipsec.d/ 若以旧连接命名，可能比创建它的配置文件活得更久，因此删掉无人引用的那些再重试。

最后，确认这条建议出自哪里。一份为 IKEv1 XAuth 写的 ipsec.conf 描述的是另一种 VPN 类型，它的提议并不是 L2TP 配置里唯一会出错的设置行。把你输入的转换集记在配置文件旁边，下一个人就不必重复探测。

相关文章