开源代码实现pppoe over l2tp方案

PPPoE L2TP 实现方案

1. 需求描述

有些运营商有路由器需要支持L2TP拨号功能，同时对终端用户支持PPPoE拨号功能。依据L2TP的隧道建立方式，分为单隧道工作模式和多隧道工作模式，目前的实现方案仅讨论单隧道工作模式，即一台路由器创建一个L2TP隧道，一次PPPoE拨号创建一个L2TP会话，每个用户对应一个会话连接，报文交互流程如图1.1所示：

图1.1 L2TP单隧道工作模式

      

根据图1.1的描述，可以总结几下几点关键点：第一、PPPoE的开始和终结分别在终端和路由器；第二、L2TP的开始和终结分别在路由器和BRAS；第三、PPP报文的交互的开始和终结分别在终端和BRAS。理解以上三点是解决该问题的关键，特别是第三点尤为关键，这就意味着在路由器的进程中不应该存在任何的pppd进程，否则的话，后续的几天内的工作都将是极其枯燥和乏味的，当然也是徒劳的。

1. L2TP深入分析

L2TP 扩展了 PPP 模型，允许第二层和 PPP 终点处于不同的由包交换网络相互连接的设备来。通过 L2TP，用户在第二层连接到一个访问集中器（如：调制解调器池、ADSL DSLAM 等），然后这个集中器将单独的 PPP 帧隧道到 NAS。这样，可以把 PPP 包的实际处理过程与 L2 连接的终点分离开来。对于这样的分离，其明显的一个好处是，L2 连接可以在一个（本地）电路集中器上终止，然后通过共享网络如帧中继电路或英特网扩展逻辑 PPP 会话，而不用在 NAS 上终止。从用户角度看，直接在 NAS 上终止 L2 连接与使用 L2TP 没有什么功能上的区别。L2TP 协议也用来解决“多连接联选组分离”问题。多链接 PPP，一般用来集中 ISDN B 通道，需要构成多链接捆绑的所有通道在一个单网络访问服务器（NAS）上组合。因为 L2TP 使得 PPP 会话可以出现在接收会话的物理点之外的位置，它用来使所有的通道出现在单个的 NAS 上，并允许多链接 *** 作，即使是在物理呼叫分散在不同物理位置的 NAS 上的情况下。

以上这段教科书式的描述摘录至百度百科，对于初次接触L2TP或者PPP的读者来说，理解以上的这段文字是有一定难度的，笔者将结合自己的一些理解和对L2TP的认识，来深入分析L2TP的一些技术关键和常用的应用场景。笔者将先从熟悉的socket的概念来切入L2TP，L2TP本质上是一个基于UDP协议的socket通信协议，其默认端口为1701，主流的开源方案有rp-l2tpd和xl2tpd。L2TP协议里面有两个关键的概念是tunnel和session，对应这两个概念有tunnel id和session id，这两个ID标识一个可以通信的数据通道，也就是说，如果想通过L2TP来透传PPP报文，必须要获取tunnel id和session id，即需要建立可以通信的session。从编程的角度讲，需要建立一个UDP的端口，然后收发几个L2TP的协议报文，就可以得到一个后续通信的tunnel id和session id，幸运的是rp-l2tpd很好完成这项工作，即使它并不能满足本文的需求，后续章节将会详细介绍rp-l2tpd的用法，典型的L2TP应用拓扑图如图2.1所示。

本节笔者将澄清一个容易混淆的概念，即L2TP和PPP之间的关系，从通信协议的角度讲，这两者之间没有必然的联系，L2TP协议仅仅是对PPP的应用作了一次跨越性的延生，理论上在L2TP隧道上可以承载任何的协议报文；但是在丰富多彩的世界里，充满了各种各样的观点和言论，经常是，正是这些爆炸式的信息使得人们迷失了自我，而且很长一段时间内都看不到事实的真相，没有人明确的告诉你什么是正确的，什么是错误的？那么这些观点包括能够获取到的开源软件，似乎都在向他人传递一个信息，L2TP和PPP是同在的。以rp-l2tpd为例，无论是配置文件，还是代码实现，好像你都无法避开PPP这个伟大而又神秘的协议，感觉上L2TP和PPP绑定的很牢固，事实上，后文介绍的方案将彻底打破这个看似牢不可破的世俗观念。

图2.1 典型的L2TP应用拓扑图

从历史的角度看，PPP协议在L2TP协议被指定的很多年前就已经存在了，最初的PPP协议是为在点对点连接上传输多协议数据包提供了一个标准方法。PPP 最初设计是为两个对等节点之间的 IP 流量传输提供一种封装协议。在 TCP-IP 协议集中它是一种用来同步调制连接的数据链路层协议，替代了原来非标准的第二层协议，即 SLIP。除了 IP 以外 PPP 还可以携带其它协议，包括 DECnet和 Novell的Internet 网包交换（IPX）。PPP可以用于多种类型的物理介质上，包括串口线、电话线、移动电话和光纤（例如SDH），PPP也用于Internet接入。总而言之，从历史选择的结果看，PPP真是红透了半边天，正所谓人红是非多，后来的很多PPTP、L2TP、PPPoE等这些技术也踏上了漫长的追星之路。

1. PPPoE协议分析

PPPoE协议是随着以太网技术的成熟而广泛人知，PPPoE是典型的二层协议，如果PPPoE需要跨三层网络则需要进行PPPoE-relay协议的支撑。由于PPPoE对于大部分的读者来讲并不默认，本节将仅对PPPoE基本概念作一些描述。

图3.1 PPPoE工作流程图

PPPoE协议的工作流程包含发现和会话两个阶段，发现阶段是无状态的，目的是获得PPPoE终结端（在局端的ADSL设备上）的以太网MAC地址，并建立一个唯一的PPPoE SESSION-ID；发现阶段结束后，就进入标准的PPP会话阶段。当一个主机想开始一个PPPoE会话，它必须首先进行发现阶段，以识别局端的以太网MAC地址，并建立一个PPPoE SESSION-ID。在发现阶段，基于网络的拓扑，主机可以发现多个接入集中器，然后允许用户选择一个。当发现阶段成功完成，主机和选择的接入集中器都有了他们在以太网上建立PPP连接的信息。直到PPP会话建立，发现阶段一直保持无状态的Client/Server（客户/服务器）模式。一旦PPP会话建立，主机和接入集中器都必须为PPP虚接口分配资源，PPPoE工作流程图如图3.1所示。

1. L2TP NAT转发模型分析

针对路由器的实际应用场景，L2TP有两种比较常见的模型，本文的需求是其一，另外就是L2TP NAT转发模型，本章将介绍NAT转发的工作原理。首先，路由器和L2TP的LNS建立隧道，路由器通过PPP协议从LNS获取IP地址，路由器本身和LNS之间建立点到点连接；其次，路由器充当PPPoE Server的角色，终端用户通过PPPoE从路由器获取私网IP；最后，路由器启用NAT功能，路由器将为终端提供至LNS的连接通道，具体模型如图4.1所示。

图4.1 L2TP NAT转发模型

       L2TP NAT转发模型和本文需要实现的转发方案有这本质的差异，虽然它也有PPPoE server和L2TP client，这两种方案的确容易令人混淆。从图1.1(模型A)和图4.1(模型B)的流程对比来分析，这两个模型之间的差异主要存在以下几点：第一、模型A的终端侧地址是有LNS分配，模型B的终端测地址是由路由器分配；第二、模型A的路由器中没有任何的PPP端口，模型B至少存在两个PPP端口；第三、模型A中的PPPoE部分的交互依赖L2TP的状态，模型B没有这种限制；第四、模型A对于数据报文完全是透传，模型B则是做NAT，在大规模组网时，模型A有着绝对的优势，因为它符合运营商对网络的可管可控的要求。

1.   L2TP透传PPPoE方案

笔者在前几章对整个方案设计需要的重要概念进行了一次科普，本章的主要内容将介绍L2TP透传PPPoE的方案整个实现过程。从已经有的开源代码中，笔者选择了rp-pppoe和rp-xl2tpd这两个比较成熟的方案，但是这两个实现不能实现L2TP透传PPPoE的功能，下面笔者将详细描述整个方案的改造过程，整个方案的框架图如图5.1所示。

图5.1 L2TP 透传PPPoE方案

整个框架主要包含四个部分：rp-pppoe、rp-xl2tpd、l2tp-relay、内核转发模块，rp-pppoe进程主要负责管理pppoe连接的整个过程；当rp-pppoe进程收到PADR报文之后，rp-pppoe会调用l2tp-relay进程，l2tp-relay进程会向rp-xl2tpd进程发送建立l2tp session的指令，同时将信息写入内核转发表；rp-xl2tpd进程建立成功l2tp session之后，会将l2tp信息写入内核转发表，内核通过netlink机制将事件通知给rp-pppoe进程，rp-pppoe进程发送PADS报文；终端进入ppp协商阶段，此时内核转发模块封装报文，将PPPOE报文封装成L2TP报文，此处不再赘述。