1. 项目背景与核心需求拆解1.1 这个配置实例到底在解决什么问题“L2TP 配置实例——CALL LNS”这个标题，放在企业网络运维的语境里，说的其实是一件很具体的事：一台设备作为 LAC（L2TP Access Concentrator，L2TP 访问集中器），主动向另一台设备 LNS（L2TP Network Server，L2TP 网络服务器）发起隧道建立请求，把用户的二层链路延伸到远端网络。标题里的“CALL LNS”，重点就在“CALL”这个动作上——是 LAC 侧主动拨向 LNS，而不是等 LNS 来连自己。我在实际项目里碰到这个需求，通常来自这么几类场景。第一类是分支机构要把本地拨号用户或者专线用户“甩”到总部去统一认证和分配地址，本地设备只做接入和隧道封装，不做业务终结。第二类是某些行业终端只支持 PPPoE 拨号，但后台的认证、计费、地址池全在中心机房，这时候就需要在中间加一跳 L2TP 把会话透传过去。第三类是测试环境里模拟运营商侧的 LAC 行为，验证 LNS 的接入容量和稳定性。这个实例适合谁来参考？我的判断是：有一定网络基础、能看懂 PPP 和隧道概念、手上有两台可配置设备（物理或虚拟都行）的运维和网络工程师。纯小白也能看，但至少要先把“隧道”“会话”“PPP 协商”这几个词的含义搞清楚，不然配到一半会不知道自己在干什么。1.2 为什么是 L2TP，而不是别的隧道方案很多人第一反应会问：都什么年代了，为什么还用 L2TP？我一般会这么解释——L2TP 的价值不在于它新，而在于它“薄”。它本身不负责加密，只负责把 PPP 帧封装起来在 IP 网络里传，控制面和数据面分得很清楚。这种“薄”带来的好处是：它能把用户的 PPP 会话原封不动地送到 LNS，让 LNS 像直接面对拨号用户一样处理认证和地址分配。对比一下其他方案就明白了。如果只是要打通两个网段，用 GRE 或者 IPsec 隧道更直接；如果只是要远程访问，用 SSL 类的方案更省事。但“CALL LNS”这个场景的核心诉求是会话级的透传，不是网络级的互联。LAC 要做的，是把每一个用户的 PPP 会话单独映射成一条 L2TP 会话，LNS 侧看到的是一个一个独立的用户，而不是一条笼统的隧道。这一点，GRE 做不到，普通的 IPsec 站点到站点也做不到。所以选 L2TP，本质上是选它的“会话粒度”。这也是为什么标题强调“CALL LNS”——LAC 主动呼叫，意味着会话的发起权在接入侧，LNS 只负责响应和终结。这个方向性很重要，配反了整套流程就跑不通。1.3 核心角色与关键概念对齐在动手之前，我习惯先把几个角色和概念在纸上写清楚，避免配到一半概念混淆。角色/概念含义在本实例中的位置LACL2TP 访问集中器，负责发起隧道和会话主动 CALL 的一方LNSL2TP 网络服务器，负责接收隧道和会话被 CALL 的一方Tunnel隧道，LAC 和 LNS 之间的一条逻辑通道一条隧道可承载多条会话Session会话，对应用户的一次 PPP 连接隧道内的一对一映射PPP 协商用户与 LNS 之间的认证和地址分配过程由 LNS 终结隧道 ID / 会话 ID本地标识，用于区分不同隧道和会话双方各自维护，不要求一致这里有个容易踩的坑：隧道和会话是两层概念。一条隧道里可以塞很多条会话，隧道断了所有会话都断，但单条会话断了隧道还在。很多新手配完发现“隧道起来了但用户上不去”，问题往往出在会话层，而不是隧道层。把这两层分开看，排查思路会清晰很多。2. 配置前的环境准备与参数规划2.1 设备与拓扑的最小可用组合要复现这个实例，最省事的做法是两台支持 L2TP 的设备直连或者通过一台交换机互联。我一般推荐用两台路由器或者一台路由器加一台防火墙来做，因为这类设备的 L2TP 配置项比较完整，日志也好看。如果用虚拟环境，注意虚拟网卡的桥接模式要选对，不然隧道包可能出不去。拓扑上，我习惯画成三段：用户侧——LAC——中间 IP 网络——LNS——远端网络。用户侧可以是一个模拟拨号的终端，也可以是一台再往下的接入设备。中间 IP 网络就是 LAC 和 LNS 之间的三层可达网络，可以是直连，也可以跨几个跳。LNS 后面接的是真正要访问的资源网络。这里要强调一个前提：LAC 和 LNS 之间必须三层可达。L2TP 的控制报文和数据报文都是跑在 IP 之上的，如果中间有 NAT 或者防火墙，要提前把 UDP 1701 端口放通。我见过有人在中间加了 NAT，结果隧道能起来但会话建不起来，查了半天才发现是 NAT 把会话的源端口改了，LNS 侧对不上。2.2 关键参数的计算与选择过程配置 L2TP 之前，有几个参数必须先定下来，不然配到一半会反复改。隧道认证。L2TP 隧道本身可以配认证，也可以不配。如果 LAC 和 LNS 之间是可信网络，我一般先不配隧道认证，把流程跑通再说；如果是跨不可信网络，再补上。隧道认证的密码要两边一致，这个没什么好说的。本端和对端隧道名称。这个名称是逻辑标识，不要求两边一样，但建议起个能看懂的名字，比如按机房或者设备编号来。我踩过的坑是：两边都用了默认名称，结果同时起了多条隧道时，日志里分不清哪条是哪条。会话的地址分配方式。用户的地址是由 LNS 分配的，LAC 不参与。所以 LNS 侧要准备好地址池，池的大小要能覆盖预期并发用户数。如果地址池太小，用户多了会出现“认证过了但拿不到地址”的情况。MTU 和 MSS。这是 L2TP 最容易出问题的地方。因为 L2TP 封装会增加开销，如果用户的 PPP 会话 MTU 还是默认的 1500，大包可能会被丢弃。我一般的做法是：把 LAC 侧面向用户的接口 MTU 调小到 1400 左右，同时在 LNS 侧对 TCP 的 MSS 做 clamp，避免分片。具体调多少要看封装层数，L2TP over IP 大概占 40 字节左右，留点余量比较稳。2.3 配置前的检查清单动手前我会过一遍这个清单，能省掉很多返工：LAC 和 LNS 之间能不能 ping 通，路由有没有问题UDP 1701 有没有被中间设备拦掉LNS 侧地址池够不够大，有没有和现有网段冲突两边的时间是否同步，日志时间对不上排查会很痛苦有没有开调试日志的权限，L2TP 的问题基本靠日志定位提示：如果是在生产环境做，建议先在测试环境把整套流程跑通，再往生产上搬。L2TP 的配置项不多，但每一条都影响会话建立，改错一条可能整条隧道都起不来。3. LAC 侧配置实操与核心环节3.1 启用 L2TP 并定义 LNS 对端LAC 侧的第一步，是告诉设备“我要作为 LAC，主动去连某个 LNS”。这一步的核心是定义一个 LNS 的对端信息，包括对端地址和隧道参数。以常见的命令行风格为例，逻辑上是这样的：# 启用 L2TP 功能 l2tp enable # 定义 LNS 对端，名称自定义 l2tp-group 1 tunnel name LAC-SIDE # 指定主动呼叫 LNS start l2tp ip 192.0.2.10 # 隧道认证（可选，先不配） # tunnel password cipher ******这里的start l2tp ip 192.0.2.10就是“CALL LNS”的核心动作——设备会主动向这个地址发起隧道建立请求。注意这个地址是 LNS 的接口地址，必须是 LAC 能路由到的。我一般会把隧道名称起得有意义一点，比如带上本端设备编号。这样在 LNS 侧看日志时，能一眼看出是哪台 LAC 连过来的。隧道认证如果暂时不配，两边都不配就行，不要一边配一边不配，那样会协商失败。3.2 把用户会话映射到隧道光有隧道还不够，LAC 还要知道“哪些用户的会话要往这条隧道里送”。这一步是通过在面向用户的接口上绑定 L2TP 组来实现的。假设用户是通过某个接口拨号上来的，配置逻辑是：# 面向用户的接口 interface dialer 1 # 绑定到 L2TP 组 1 l2tp-group 1 # PPP 相关配置 ppp authentication-mode chap ip address negotiated这里的l2tp-group 1就是把该接口上的 PPP 会话和前面定义的 L2TP 组关联起来。用户一拨号，LAC 就会为这个会话建立一条 L2TP 会话，送到 LNS 去。有个细节要注意：LAC 侧不需要配地址池，因为地址是 LNS 分的。LAC 侧配ip address negotiated表示地址由对端协商分配。如果这里配了固定地址，用户可能拿不到 LNS 池里的地址，反而用了 LAC 本地地址，那就失去透传的意义了。3.3 LAC 侧的关键注意事项配 LAC 侧时，我总结了几条经验，都是实际踩出来的：第一，隧道源地址要明确。如果 LAC 有多个接口，最好显式指定隧道使用的源地址，不然设备可能选了一个 LNS 不可达的地址做源，隧道就起不来。配置里通常有一个source或者类似的选项。第二，会话数限制要留意。有些设备默认对单条隧道的会话数有限制，用户多了之后新会话建不起来。如果预期并发高，提前把这个限制调大。第三，调试日志要开对级别。L2TP 的日志分隧道层和会话层，排查时先看隧道层有没有起来，再看会话层有没有协商成功。一上来就开最详细的日志，反而会被淹没。注意：LAC 侧配置改动后，建议先reset掉旧的隧道再重新触发，不然可能残留旧状态导致新配置不生效。我遇到过改了 LNS 地址但旧隧道还挂着的情况，日志里两套信息混在一起，很难看。4. LNS 侧配置与响应逻辑4.1 定义 LNS 接收参数LNS 侧的角色是“等别人来连”，所以配置重点是定义好接收参数和用户处理逻辑。# 启用 L2TP l2tp enable # 定义 L2TP 组，作为 LNS l2tp-group 1 tunnel name LNS-SIDE # 允许 LAC 发起呼叫 allow l2tp virtual-template 1这里的allow l2tp virtual-template 1是关键——它表示 LNS 接受 LAC 的呼叫，并把会话交给虚拟模板 1 去处理。虚拟模板相当于一个“用户接入模板”，里面定义了 PPP 认证方式和地址分配。4.2 虚拟模板与地址池配置虚拟模板是 LNS 侧的核心，用户的 PPP 协商都在这里终结。# 虚拟模板 interface virtual-template 1 ppp authentication-mode chap # 地址从池里分配 ip address 10.10.10.1 255.255.255.0 peer default ip address pool USER-POOL # 地址池 ip pool USER-POOL network 10.10.10.0 mask 255.255.255.0 gateway 10.10.10.1地址池的网段要和 LNS 后面的资源网络路由可达，不然用户拿到地址也访问不了资源。我一般会把池的网关设成虚拟模板的地址，这样用户的路由指向就明确了。认证方式上，CHAP 比 PAP 更常用，因为密码不在链路上明文传。如果用户侧只支持 PAP，那 LNS 侧也要相应改成 PAP，两边必须一致。4.3 LNS 侧如何确认会话来自哪台 LACLNS 侧可能同时接多台 LAC，所以日志和会话表里要能区分来源。我一般会关注这几个字段：对端隧道 ID、对端 IP、隧道名称。隧道名称是 LAC 侧定义的，如果 LAC 侧起名规范，LNS 侧一眼就能看出是谁。如果发现某台 LAC 的会话异常，可以在 LNS 侧针对性地看该对端的会话统计。有些设备支持按对端过滤显示，这个功能在排查多 LAC 环境时特别有用。提示：LNS 侧的地址池不要和 LAC 侧任何网段重叠，否则用户可能拿到地址后路由混乱。规划阶段就要把两边的网段列出来对一遍。5. 常见问题与排查技巧实录5.1 隧道起不来怎么办隧道起不来是最常见的问题，排查顺序我一般是这样的：现象可能原因排查动作隧道一直处于协商中中间 UDP 1701 被拦检查防火墙和 NAT 规则隧道建立后立即断开隧道认证不匹配核对两边认证配置完全看不到隧道LNS 地址不可达从 LAC ping LNS 地址隧道名称冲突两边名称重复改成唯一名称我印象最深的一次是中间有台防火墙只放通了 TCP，没放 UDP，结果隧道控制报文过不去，现象就是“一直协商中”。后来把 UDP 1701 双向放通，立刻就起来了。所以排查隧道问题，先确认三层可达和端口放通，这两步能解决大半问题。5.2 隧道起来了但用户上不去这种情况说明隧道层没问题，问题在会话层或 PPP 层。排查思路：第一，看 LNS 侧有没有收到会话请求。如果没收到，说明 LAC 侧没把用户会话映射进来，检查面向用户接口的 L2TP 绑定。第二，看 PPP 认证有没有过。如果认证失败，检查两边的认证方式和密码。CHAP 的密码是密文存储的，有时候复制配置时密码没带过去，就会认证失败。第三，看地址有没有分下去。如果认证过了但没地址，检查 LNS 地址池是不是空了或者配置错了。第四，看用户能不能访问资源。如果地址有了但访问不了，检查 LNS 后面有没有回程路由。5.3 MTU 问题导致的“能连上但打不开网页”这是最隐蔽的一类问题。用户 PPP 拨号成功，ping 小包也通，但一打开网页就卡住。原因通常是 MTU 不匹配，大包被丢弃。我的处理办法是：在 LAC 侧把面向用户的接口 MTU 调到 1400，在 LNS 侧对 TCP MSS 做 clamp 到 1360 左右。这样即使封装有开销，也不会触发分片。调完之后，网页基本就能正常打开了。注意：MTU 不要调得太小，太小会影响吞吐。1400 是个比较稳妥的经验值，具体可以根据封装层数微调。5.4 多用户并发时的性能观察单用户跑通不代表多用户没问题。我一般会做一轮并发测试，观察几个指标：隧道数、会话数、CPU 占用、地址池剩余。如果会话数上不去，可能是设备限制或者地址池不够。如果 CPU 飙高，可能是调试日志开太多，关掉日志再测。还有一点，L2TP 的会话建立是有开销的，大量用户同时拨号时，LNS 侧可能会有短暂的响应延迟。如果业务对建立速度敏感，可以考虑把会话建立分散开，或者提升 LNS 的处理能力。6. 实操心得与后续扩展方向6.1 我踩过的几个典型坑第一个坑是隧道源地址选错。有次 LAC 有两个接口，设备默认选了不面向 LNS 的那个做源，隧道怎么都起不来。后来显式指定源地址，问题解决。这个坑的教训是：多接口设备配 L2TP，源地址一定要明确。第二个坑是地址池和现有网段冲突。LNS 的地址池配了一个和内部网络重叠的网段，用户拿到地址后路由混乱，访问内部资源时走了错误的路径。后来重新规划了地址池，问题消失。规划阶段多花十分钟对网段，能省掉后面几小时的排查。第三个坑是日志级别开太高。为了排查问题把 L2TP 日志开到最详细，结果设备 CPU 被日志拖高，反而影响了会话建立。后来改成按需开日志，问题定位完就关掉。6.2 这个配置还能怎么扩展把基础的 CALL LNS 跑通之后，可以往几个方向扩展。一是加隧道认证，提升 LAC 和 LNS 之间的安全性。二是做多 LNS 备份，LAC 侧配多个 LNS 地址，主用不通时切备用。三是结合 RADIUS，把认证和地址分配交给外部服务器，LNS 只做隧道终结。四是做流量统计和限速，在 LNS 侧对每个会话做带宽控制。这些扩展都不是必须的，但实际项目里经常会用到。我的建议是先把基础流程跑稳，再按需加功能，不要一上来就堆配置，那样出了问题很难定位是哪一层引起的。6.3 给准备动手的人几句实在话L2TP 这个协议本身不复杂，配置项也不多，但它涉及 PPP、隧道、会话、地址分配好几层，任何一层出问题都会表现为“连不上”。所以排查时一定要分层看：先看三层可达，再看隧道，再看会话，最后看 PPP 和地址。按这个顺序走，基本不会迷路。另外，实验环境里跑通和生产环境稳定运行是两回事。生产环境要考虑并发、冗余、监控和故障切换。如果只是学习，把单隧道单会话跑通就够了；如果要上生产，建议把前面提到的扩展方向都评估一遍。最后分享一个小技巧：配 L2TP 时，把 LAC 和 LNS 的配置分别存一份带注释的备份，改配置前先对比一下。我吃过改错一个参数导致整条隧道挂掉的亏，后来养成备份习惯，回滚起来快很多。
1. 项目背景与核心需求拆解1.1 这个配置实例到底在解决什么问题“L2TP 配置实例——CALL LNS”这个标题，放在企业网络运维的语境里，说的其实是一件很具体的事：一台设备作为 LAC（L2TP Access Concentrator，L2TP 访问集中器），主动向另一台设备 LNS（L2TP Network Server，L2TP 网络服务器）发起隧道建立请求，把用户的二层链路延伸到远端网络。标题里的“CALL LNS”，重点就在“CALL”这个动作上——是 LAC 侧主动拨向 LNS，而不是等 LNS 来连自己。我在实际项目里碰到这个需求，通常来自这么几类场景。第一类是分支机构要把本地拨号用户或者专线用户“甩”到总部去统一认证和分配地址，本地设备只做接入和隧道封装，不做业务终结。第二类是某些行业终端只支持 PPPoE 拨号，但后台的认证、计费、地址池全在中心机房，这时候就需要在中间加一跳 L2TP 把会话透传过去。第三类是测试环境里模拟运营商侧的 LAC 行为，验证 LNS 的接入容量和稳定性。这个实例适合谁来参考？我的判断是：有一定网络基础、能看懂 PPP 和隧道概念、手上有两台可配置设备（物理或虚拟都行）的运维和网络工程师。纯小白也能看，但至少要先把“隧道”“会话”“PPP 协商”这几个词的含义搞清楚，不然配到一半会不知道自己在干什么。1.2 为什么是 L2TP，而不是别的隧道方案很多人第一反应会问：都什么年代了，为什么还用 L2TP？我一般会这么解释——L2TP 的价值不在于它新，而在于它“薄”。它本身不负责加密，只负责把 PPP 帧封装起来在 IP 网络里传，控制面和数据面分得很清楚。这种“薄”带来的好处是：它能把用户的 PPP 会话原封不动地送到 LNS，让 LNS 像直接面对拨号用户一样处理认证和地址分配。对比一下其他方案就明白了。如果只是要打通两个网段，用 GRE 或者 IPsec 隧道更直接；如果只是要远程访问，用 SSL 类的方案更省事。但“CALL LNS”这个场景的核心诉求是会话级的透传，不是网络级的互联。LAC 要做的，是把每一个用户的 PPP 会话单独映射成一条 L2TP 会话，LNS 侧看到的是一个一个独立的用户，而不是一条笼统的隧道。这一点，GRE 做不到，普通的 IPsec 站点到站点也做不到。所以选 L2TP，本质上是选它的“会话粒度”。这也是为什么标题强调“CALL LNS”——LAC 主动呼叫，意味着会话的发起权在接入侧，LNS 只负责响应和终结。这个方向性很重要，配反了整套流程就跑不通。1.3 核心角色与关键概念对齐在动手之前，我习惯先把几个角色和概念在纸上写清楚，避免配到一半概念混淆。角色/概念含义在本实例中的位置LACL2TP 访问集中器，负责发起隧道和会话主动 CALL 的一方LNSL2TP 网络服务器，负责接收隧道和会话被 CALL 的一方Tunnel隧道，LAC 和 LNS 之间的一条逻辑通道一条隧道可承载多条会话Session会话，对应用户的一次 PPP 连接隧道内的一对一映射PPP 协商用户与 LNS 之间的认证和地址分配过程由 LNS 终结隧道 ID / 会话 ID本地标识，用于区分不同隧道和会话双方各自维护，不要求一致这里有个容易踩的坑：隧道和会话是两层概念。一条隧道里可以塞很多条会话，隧道断了所有会话都断，但单条会话断了隧道还在。很多新手配完发现“隧道起来了但用户上不去”，问题往往出在会话层，而不是隧道层。把这两层分开看，排查思路会清晰很多。2. 配置前的环境准备与参数规划2.1 设备与拓扑的最小可用组合要复现这个实例，最省事的做法是两台支持 L2TP 的设备直连或者通过一台交换机互联。我一般推荐用两台路由器或者一台路由器加一台防火墙来做，因为这类设备的 L2TP 配置项比较完整，日志也好看。如果用虚拟环境，注意虚拟网卡的桥接模式要选对，不然隧道包可能出不去。拓扑上，我习惯画成三段：用户侧——LAC——中间 IP 网络——LNS——远端网络。用户侧可以是一个模拟拨号的终端，也可以是一台再往下的接入设备。中间 IP 网络就是 LAC 和 LNS 之间的三层可达网络，可以是直连，也可以跨几个跳。LNS 后面接的是真正要访问的资源网络。这里要强调一个前提：LAC 和 LNS 之间必须三层可达。L2TP 的控制报文和数据报文都是跑在 IP 之上的，如果中间有 NAT 或者防火墙，要提前把 UDP 1701 端口放通。我见过有人在中间加了 NAT，结果隧道能起来但会话建不起来，查了半天才发现是 NAT 把会话的源端口改了，LNS 侧对不上。2.2 关键参数的计算与选择过程配置 L2TP 之前，有几个参数必须先定下来，不然配到一半会反复改。隧道认证。L2TP 隧道本身可以配认证，也可以不配。如果 LAC 和 LNS 之间是可信网络，我一般先不配隧道认证，把流程跑通再说；如果是跨不可信网络，再补上。隧道认证的密码要两边一致，这个没什么好说的。本端和对端隧道名称。这个名称是逻辑标识，不要求两边一样，但建议起个能看懂的名字，比如按机房或者设备编号来。我踩过的坑是：两边都用了默认名称，结果同时起了多条隧道时，日志里分不清哪条是哪条。会话的地址分配方式。用户的地址是由 LNS 分配的，LAC 不参与。所以 LNS 侧要准备好地址池，池的大小要能覆盖预期并发用户数。如果地址池太小，用户多了会出现“认证过了但拿不到地址”的情况。MTU 和 MSS。这是 L2TP 最容易出问题的地方。因为 L2TP 封装会增加开销，如果用户的 PPP 会话 MTU 还是默认的 1500，大包可能会被丢弃。我一般的做法是：把 LAC 侧面向用户的接口 MTU 调小到 1400 左右，同时在 LNS 侧对 TCP 的 MSS 做 clamp，避免分片。具体调多少要看封装层数，L2TP over IP 大概占 40 字节左右，留点余量比较稳。2.3 配置前的检查清单动手前我会过一遍这个清单，能省掉很多返工：LAC 和 LNS 之间能不能 ping 通，路由有没有问题UDP 1701 有没有被中间设备拦掉LNS 侧地址池够不够大，有没有和现有网段冲突两边的时间是否同步，日志时间对不上排查会很痛苦有没有开调试日志的权限，L2TP 的问题基本靠日志定位提示：如果是在生产环境做，建议先在测试环境把整套流程跑通，再往生产上搬。L2TP 的配置项不多，但每一条都影响会话建立，改错一条可能整条隧道都起不来。3. LAC 侧配置实操与核心环节3.1 启用 L2TP 并定义 LNS 对端LAC 侧的第一步，是告诉设备“我要作为 LAC，主动去连某个 LNS”。这一步的核心是定义一个 LNS 的对端信息，包括对端地址和隧道参数。以常见的命令行风格为例，逻辑上是这样的：# 启用 L2TP 功能 l2tp enable # 定义 LNS 对端，名称自定义 l2tp-group 1 tunnel name LAC-SIDE # 指定主动呼叫 LNS start l2tp ip 192.0.2.10 # 隧道认证（可选，先不配） # tunnel password cipher ******这里的start l2tp ip 192.0.2.10就是“CALL LNS”的核心动作——设备会主动向这个地址发起隧道建立请求。注意这个地址是 LNS 的接口地址，必须是 LAC 能路由到的。我一般会把隧道名称起得有意义一点，比如带上本端设备编号。这样在 LNS 侧看日志时，能一眼看出是哪台 LAC 连过来的。隧道认证如果暂时不配，两边都不配就行，不要一边配一边不配，那样会协商失败。3.2 把用户会话映射到隧道光有隧道还不够，LAC 还要知道“哪些用户的会话要往这条隧道里送”。这一步是通过在面向用户的接口上绑定 L2TP 组来实现的。假设用户是通过某个接口拨号上来的，配置逻辑是：# 面向用户的接口 interface dialer 1 # 绑定到 L2TP 组 1 l2tp-group 1 # PPP 相关配置 ppp authentication-mode chap ip address negotiated这里的l2tp-group 1就是把该接口上的 PPP 会话和前面定义的 L2TP 组关联起来。用户一拨号，LAC 就会为这个会话建立一条 L2TP 会话，送到 LNS 去。有个细节要注意：LAC 侧不需要配地址池，因为地址是 LNS 分的。LAC 侧配ip address negotiated表示地址由对端协商分配。如果这里配了固定地址，用户可能拿不到 LNS 池里的地址，反而用了 LAC 本地地址，那就失去透传的意义了。3.3 LAC 侧的关键注意事项配 LAC 侧时，我总结了几条经验，都是实际踩出来的：第一，隧道源地址要明确。如果 LAC 有多个接口，最好显式指定隧道使用的源地址，不然设备可能选了一个 LNS 不可达的地址做源，隧道就起不来。配置里通常有一个source或者类似的选项。第二，会话数限制要留意。有些设备默认对单条隧道的会话数有限制，用户多了之后新会话建不起来。如果预期并发高，提前把这个限制调大。第三，调试日志要开对级别。L2TP 的日志分隧道层和会话层，排查时先看隧道层有没有起来，再看会话层有没有协商成功。一上来就开最详细的日志，反而会被淹没。注意：LAC 侧配置改动后，建议先reset掉旧的隧道再重新触发，不然可能残留旧状态导致新配置不生效。我遇到过改了 LNS 地址但旧隧道还挂着的情况，日志里两套信息混在一起，很难看。4. LNS 侧配置与响应逻辑4.1 定义 LNS 接收参数LNS 侧的角色是“等别人来连”，所以配置重点是定义好接收参数和用户处理逻辑。# 启用 L2TP l2tp enable # 定义 L2TP 组，作为 LNS l2tp-group 1 tunnel name LNS-SIDE # 允许 LAC 发起呼叫 allow l2tp virtual-template 1这里的allow l2tp virtual-template 1是关键——它表示 LNS 接受 LAC 的呼叫，并把会话交给虚拟模板 1 去处理。虚拟模板相当于一个“用户接入模板”，里面定义了 PPP 认证方式和地址分配。4.2 虚拟模板与地址池配置虚拟模板是 LNS 侧的核心，用户的 PPP 协商都在这里终结。# 虚拟模板 interface virtual-template 1 ppp authentication-mode chap # 地址从池里分配 ip address 10.10.10.1 255.255.255.0 peer default ip address pool USER-POOL # 地址池 ip pool USER-POOL network 10.10.10.0 mask 255.255.255.0 gateway 10.10.10.1地址池的网段要和 LNS 后面的资源网络路由可达，不然用户拿到地址也访问不了资源。我一般会把池的网关设成虚拟模板的地址，这样用户的路由指向就明确了。认证方式上，CHAP 比 PAP 更常用，因为密码不在链路上明文传。如果用户侧只支持 PAP，那 LNS 侧也要相应改成 PAP，两边必须一致。4.3 LNS 侧如何确认会话来自哪台 LACLNS 侧可能同时接多台 LAC，所以日志和会话表里要能区分来源。我一般会关注这几个字段：对端隧道 ID、对端 IP、隧道名称。隧道名称是 LAC 侧定义的，如果 LAC 侧起名规范，LNS 侧一眼就能看出是谁。如果发现某台 LAC 的会话异常，可以在 LNS 侧针对性地看该对端的会话统计。有些设备支持按对端过滤显示，这个功能在排查多 LAC 环境时特别有用。提示：LNS 侧的地址池不要和 LAC 侧任何网段重叠，否则用户可能拿到地址后路由混乱。规划阶段就要把两边的网段列出来对一遍。5. 常见问题与排查技巧实录5.1 隧道起不来怎么办隧道起不来是最常见的问题，排查顺序我一般是这样的：现象可能原因排查动作隧道一直处于协商中中间 UDP 1701 被拦检查防火墙和 NAT 规则隧道建立后立即断开隧道认证不匹配核对两边认证配置完全看不到隧道LNS 地址不可达从 LAC ping LNS 地址隧道名称冲突两边名称重复改成唯一名称我印象最深的一次是中间有台防火墙只放通了 TCP，没放 UDP，结果隧道控制报文过不去，现象就是“一直协商中”。后来把 UDP 1701 双向放通，立刻就起来了。所以排查隧道问题，先确认三层可达和端口放通，这两步能解决大半问题。5.2 隧道起来了但用户上不去这种情况说明隧道层没问题，问题在会话层或 PPP 层。排查思路：第一，看 LNS 侧有没有收到会话请求。如果没收到，说明 LAC 侧没把用户会话映射进来，检查面向用户接口的 L2TP 绑定。第二，看 PPP 认证有没有过。如果认证失败，检查两边的认证方式和密码。CHAP 的密码是密文存储的，有时候复制配置时密码没带过去，就会认证失败。第三，看地址有没有分下去。如果认证过了但没地址，检查 LNS 地址池是不是空了或者配置错了。第四，看用户能不能访问资源。如果地址有了但访问不了，检查 LNS 后面有没有回程路由。5.3 MTU 问题导致的“能连上但打不开网页”这是最隐蔽的一类问题。用户 PPP 拨号成功，ping 小包也通，但一打开网页就卡住。原因通常是 MTU 不匹配，大包被丢弃。我的处理办法是：在 LAC 侧把面向用户的接口 MTU 调到 1400，在 LNS 侧对 TCP MSS 做 clamp 到 1360 左右。这样即使封装有开销，也不会触发分片。调完之后，网页基本就能正常打开了。注意：MTU 不要调得太小，太小会影响吞吐。1400 是个比较稳妥的经验值，具体可以根据封装层数微调。5.4 多用户并发时的性能观察单用户跑通不代表多用户没问题。我一般会做一轮并发测试，观察几个指标：隧道数、会话数、CPU 占用、地址池剩余。如果会话数上不去，可能是设备限制或者地址池不够。如果 CPU 飙高，可能是调试日志开太多，关掉日志再测。还有一点，L2TP 的会话建立是有开销的，大量用户同时拨号时，LNS 侧可能会有短暂的响应延迟。如果业务对建立速度敏感，可以考虑把会话建立分散开，或者提升 LNS 的处理能力。6. 实操心得与后续扩展方向6.1 我踩过的几个典型坑第一个坑是隧道源地址选错。有次 LAC 有两个接口，设备默认选了不面向 LNS 的那个做源，隧道怎么都起不来。后来显式指定源地址，问题解决。这个坑的教训是：多接口设备配 L2TP，源地址一定要明确。第二个坑是地址池和现有网段冲突。LNS 的地址池配了一个和内部网络重叠的网段，用户拿到地址后路由混乱，访问内部资源时走了错误的路径。后来重新规划了地址池，问题消失。规划阶段多花十分钟对网段，能省掉后面几小时的排查。第三个坑是日志级别开太高。为了排查问题把 L2TP 日志开到最详细，结果设备 CPU 被日志拖高，反而影响了会话建立。后来改成按需开日志，问题定位完就关掉。6.2 这个配置还能怎么扩展把基础的 CALL LNS 跑通之后，可以往几个方向扩展。一是加隧道认证，提升 LAC 和 LNS 之间的安全性。二是做多 LNS 备份，LAC 侧配多个 LNS 地址，主用不通时切备用。三是结合 RADIUS，把认证和地址分配交给外部服务器，LNS 只做隧道终结。四是做流量统计和限速，在 LNS 侧对每个会话做带宽控制。这些扩展都不是必须的，但实际项目里经常会用到。我的建议是先把基础流程跑稳，再按需加功能，不要一上来就堆配置，那样出了问题很难定位是哪一层引起的。6.3 给准备动手的人几句实在话L2TP 这个协议本身不复杂，配置项也不多，但它涉及 PPP、隧道、会话、地址分配好几层，任何一层出问题都会表现为“连不上”。所以排查时一定要分层看：先看三层可达，再看隧道，再看会话，最后看 PPP 和地址。按这个顺序走，基本不会迷路。另外，实验环境里跑通和生产环境稳定运行是两回事。生产环境要考虑并发、冗余、监控和故障切换。如果只是学习，把单隧道单会话跑通就够了；如果要上生产，建议把前面提到的扩展方向都评估一遍。最后分享一个小技巧：配 L2TP 时，把 LAC 和 LNS 的配置分别存一份带注释的备份，改配置前先对比一下。我吃过改错一个参数导致整条隧道挂掉的亏，后来养成备份习惯，回滚起来快很多。