某局点MSR L2TP 拨号账号带@导致无法登录

某局点配置 L2TP LNS 端（设备型号：MSR3640G），终端发起 VPDN 拨号。

用户反馈 VPDN 拨号始终无法成功，提示账号或密码错误。在 LNS 设备上观察，发现 Virtual-Access 接口不断地 UP 然后瞬间 DOWN，一直处于震荡循环状态，隧道无法建立。

首先，为了确认是在哪个阶段被拒绝，我们在 MSR3640G 上开启了 L2TP 的底层调试开关（debugging l2tp all）。

1、确认客户端传过来的原始账号名

*Mar 18 21:03:12:635 2026 DC_JF_GYWX_MSR3640G_1 L2TPV2/7/EVENT: 

 Parsed Proxy-Authen-Type AVP: 3.

*Mar 18 21:03:12:635 2026 DC_JF_GYWX_MSR3640G_1 L2TPV2/7/EVENT: 

 Parsed Proxy-Authen-Name AVP: xxx@yyyyyy  <--- 客户端传来的完整用户名

日志显示，客户端发过来的原始用户名为 xxx@yyyyyy。此时 PPP 协商通过，状态机进入 Established。

2、PPP 认证被拒，在隧道建立后的瞬间，设备底层收到了 PPP 的断开报文，VA 接口立刻 DOWN 掉：

*Mar 18 21:03:13:194 2026 DC_JF_GYWX_MSR3640G_1 L2TPV2/7/KDUMP: 

 Received a packet from PPP on interface Virtual-Access6 (length=33):

 ff 03 c2 23 04 01 00 1d 49 6c 6c 65 67 61 6c 20 

 75 73 65 72 20 6f 72 20 70 61 73 73 77 6f 72 64 

 2e 

把这段 HEX 代码转换成 ASCII 字符

49 6c 6c 65 67 61 6c 20 75 73 65 72 20 6f 72 20 70 61 73 73 77 6f 72 64 2e

翻译过来正好是：“Illegal user or password.”（非法的用户名或密码）。

此外，还有一条报文：

41 75 74 68 65 6e 74 69 63 61 74 69 6f 6e 20 66 61 69 6c 65 64 2e

翻译过来是：“Authentication failed.”（认证失败）。

这证实了问题根本不在 L2TP 隧道协商，而是死在了最基础的 PPP 账号密码认证阶段。

根因分析：华三 Comware 系统的 AAA/PPP 模块在处理用户名时，默认将 @ 符号作为域名分隔符（Domain-delimiter）。

当设备收到 xxx@yyyyyy  时：

设备认为该用户的实际账号是：xxx

设备认为该用户所属的 ISP 域（Domain）是：yyyyyy

而实际上，由于特定的业务场景（如某些专网/物联网拨号），这个 @ 仅仅是用户名本身的一部分，RADIUS 服务器或者本地认证需要的就是这串完整的字符。因为设备自作主张把账号“截断”了，导致送到认证服务器的账号变成了残缺的 xxx，自然会被打回 Illegal user or password.。

在系统视图下，修改 PPP 模块的默认域名分隔符。

domain-delimiter ppp /

#