开源代码实现pppoe over l2tp方案

PPPoE L2TP 实现方案

1. 需求描述

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

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

从历史的角度看，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基本概念作一些描述。

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转发模型分析

1.   L2TP透传PPPoE方案

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

整个框架主要包含四个部分：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 文，此处不再赘述。

文章知识点与官方知识档案匹配，可进一步学习相关知识 络技能树首页概览22515 人正在系统学习中