Stefenson's Blog

一个渣渣程序员的笔记

Stefenson Wang's avatar Stefenson Wang

PPPoE服务器编写

按照约定,今天简单说一下编写PPPoE服务器。

PPPoE(Point-to-Point Protocol Over Ethernet)协议是一个以太网上的点对点协议,是将点对点协议(PPP)封装在以太网(Ethernet)框架中的一种网络隧道协议。
它是一个链路层协议,如果要想自己实现一个PPPoE服务器需要了解链路层编程的相关知识。
网络五层架构中:应用——传输——网络——链路——物理。链路层属于比较靠底层的一层,所以难度还是有的。编程的时候相当于是直接与网卡打交道,编写难度比较高。

这里在Windows中,我比较推荐 WinPcap 进行编程,虽然Windows中也有面向网卡的编程,但是一般只有C的接口,并且相关资料匮乏,往往还需要与各个型号的网卡打交道,所以推荐使用WinPcap,接口统一并且易于掌握,只是有些时候速度不太理想。
使用WinPcap,你甚至可以发送一个一字节的报文(虽然他毫无意义)!在WinPcap里,TCP/IP报文头将不再是限制!你甚至不会被链路层默认封装头限制!报文里的每一个字节全部由你自由定制!WinPcap!你值得拥有!

咳咳,扯远了(感觉跟打了个广告一样……)下面说回PPPoE编程。

PPPoE工作流程

PPPoE流程
上面的图是一个PPPoE完整的工作流程(点击可查看大图)。
双向箭头的地方表示顺序可以互换,任何一方都可以发起,没有严格要求谁先发起。

从图中可以看出,PPPoE流程分为五个阶段。
其实不细分,PPPoE只有两个阶段,一个是PPPoED阶段,后面的LCP/Auth/IPCP/PPP全部都可以纳入PPP Session阶段。

PPPoE服务器在后续数据交互的过程还要参与,它不仅仅是提供IP配置给客户端,后续通讯中全部建立在PPP Session之上,服务器需要处理这些Session包,一是与客户端通讯确认是否在线管理session,二是对数据进行重新封包,去掉PPP报文头,转换为一般的报文与外部目标设备通讯,并且吧通讯结果使用PPP封包发送给客户端。所以说PPPoE服务器对服务器性能要求非常高。
从上面的描述中也可以看出PPP Session是一个很重要的概念,PPPoE通讯中,链接保持、数据传输、链路通讯、链路状态汇报和修改全部都是在PPP Session通讯上进行的,Session是一个PPPoE通讯中的关键通道。

下面就每一个阶段讲解其流程和报文结构。

链路报文头

首先介绍一下链路报文头:

Destination Source Type
6 Bytes 6 Bytes 2 Bytes

由于我们做的是链路层编程,报文里面每一个字节都需要我们填进去,所以开头这一部分我们也需要了解。
Destination:目标的Mac地址,PADI阶段客户端会使用FF:FF:FF:FF:FF:FF广播地址。
Source:来源MAC,该值在组织报文时理论上可以随意设置,可以不与当前发送设备的MAC一致,链路层编程时Source不会被自动填入当前设备的MAC地址,所以这里可以随便写(要来搞事吗www)。
Type:报文类型,目前我所知道的取值有这些

0x8863……………..PPPoE Discovery
0x8864……………..PPPoE Session
0x0800……………..IPv4

PPPoE Discovery对应的就是PPPoED阶段报文类型,在PPPoED阶段Type取该值。
PPPoE Session对应的是PPPoED阶段之后链路通讯的报文类型,在LCP/Auth/IPCP/PPP阶段Type都使用该值。
IPv4为目前网络中使用的普通报文类型,现阶段v6没有普及,如果不使用PPPoE方式进行网络接入,报文类型一般都是IPv4。

PPPoE报文通用部分

在链路报文头之后,PPPoE报文有一段通用的部分:

Version&Type Code Session ID Payload Length
1 Bytes 1 Bytes 2 Bytes 2 Bytes

Version&Type:现阶段只有一个取值:0x11,表示PPPoE版本1,类型1。
Code:表示PPPoE报文细分类型,目前有如下取值

Code值 含义 描述
0x00 Session Data PPP流程通讯时的类型
0x09 PADI PADI
0x07 PADO PADO
0x19 PADR PADR
0x65 PADS PADS
0xA7 PADT PADT

PADI/PADO/PADR/PADS/PADT是PPPoED阶段使用的Code,Session Data是PPPoE Session阶段使用的Code。
其中Session ID在PADI/PADO/PADR阶段为0x0000,在PADS中服务器会分配一个Session ID给客户,在PADT中需要携带Session ID告知接收方要断开的Session。
Session Data阶段,Session ID表示客户端与服务器之间建立的Session编号。
Payload Length为后面跟的数据总长,不包括PPPoE头和链路头。

PPPoED(PPPoE Discovery)

PPPoED阶段主要工作是客户端发现并确定要注册的PPPoE服务器,在相关的PPPoE服务器注册Session。
它的流程简单描述如下:

1.客户端通过PADI通知PPPoE服务器自己的接入请求。
2.PPPoE服务器接到PADI请求之后判断是否要答复,需要答复回复PADO。
3.客户端判断PADO内容是否是自己期望的服务器,如果是,回复PADR申请Session。
4.PPPoE服务器收到了PADR,根据当前服务器状况判断是否要开启Session,如果可以接受回复PADS。

去掉开头的链路报文头和PPPoE通用部分,PPPoED阶段报文数据形式:

Tag Type Tag Length Tag Data
2 Bytes 2 Bytes x Bytes

PPPoED中Payload就是PPPoE Tag的列表,上面这一段会重复多次,他的各个部分含义:
Tag Type表示类型,可取值

Type值 含义 备注
0x0000 End of list Tags列表结束标志
0x0101 Service-Name 服务器名称,客户端携带,说明选择特定的服务器
长度可以为0表示接受所有PPPoE服务器
一般情况下长度是0
0x0102 AC-Name 服务器返回服务器自己的名字
0x0103 Host-Uniq Discovery阶段特征值,作用类似于SessionID
每个客户端在一个流程中会保持该值唯一
服务器答复的时候最好对该值进行判断并维持该值返回
0x0104 AC-Cookie -
0x0105 Vendor-Specific -
0x0110 Reply-Session-ID -
0x0201 Service-Name-Error -
0x0202 AC-System-Error -

以上有备注说明的是比较重要的字段,也是一个PPPoE服务器的基本能力所应具备的字段,其他字段解释请查阅RFC文档。
AC-Name当然可以自己发挥了,比如我写的就是stefenson-pppoe-server,当然也可以迎合客户端要求,根据客户端 0x0101 所需进行返回,机不机智?

Tag Length表示Tag的数据长,不包含Type和Length占用的长度。

Tag Data表示Tag携带的数据。

PPPoE Session阶段共用部分

PPPoED成功完成之后进入PPPoE Session阶段。
Session阶段会先携带一个通用的两字节数据 Point to Point Protocol
该值表示接下来的Session数据是哪种类型,包括以下取值

0x8021…………..IPCP
0xC021…………..LCP
0xC023…………..PAP
0xC223…………..CHAP
0x0021…………..IPv4

当取值 0x0021 时,该报文携带的是要通讯的数据,后面的Data与链路报文类型IPv4内容一致,去掉PPPoE部分,修改链路头Type为IPv4这就是一个正常的IPv4报文。
注意这一点在后面数据链路通讯时十分重要,是PPPoE真正实现通讯的基本要点。

紧接着的内容,如果不是IPv4,数据组织形式一样:

Code Identifier Length Data
1 Bytes 1 Bytes 2 Bytes x Bytes

Code根据不同类型的有不同的意义,后面分开进行说明。
Identifier作为PPP阶段报文应答标识,用于区别报文应答关系。
Length为全长,包括Code、Identifier、Length占用的长度,不仅仅是Data的长度,也就是说 Length = Data.Length + 4。

LCP Discussion

LCP全称 Link Control Protocol,链路控制协议,控制链路吞吐量,链路通断等链路基本信息。
它的Code有如下取值

Code值 含义 描述
0x01 Configuration Request 链路协商
0x02 Configuration ACK 协商通过
0x03 Configuration NAK 协商拒绝
0x04 Configuration Reject 协商回绝
0x05 Terminate Request 链路终止请求
0x06 Terminate ACK 终止请求确认
0x09 Echo Requeest 心跳请求
0x0A Echo Reply 心跳确认

NAK和Reject的区别是,NAK表示对方的所列出的链路配置恕无法接受,而Reject则表示发过来的消息意义不明或者信息缺失,这边解析不了很迷茫(看不懂你到底要表达啥的意思)。

Data的组织形式为下面结构的多项叠加

Type Length Data
1 Bytes 1 Bytes x Bytes

这里的Length表示全长,包括Type和Length占用的字节,所以Length = Data.Length + 2。

Type取值和含义

0x01…………..MRU(Maximum Receive Unit)
0x02…………..Async-Control-Character-Map
0x03…………..Auth Type
0x05…………..Magic Number
0x06…………..Link Quality Compression/Monitoring
0x07…………..Procotol Field Compression
0x08…………..Address and Control Field Compression

当Type为MRU时,长度为 2 Bytes,表示报文发送方最大可接收的报文大小,一般不超过1484。
当Type为Auth Type时,Data可取值有这些:0xC023表示采用PAP认证、0xC223 + 0x05表示使用MD5挑战方式的CHAP认证。当然也存在其他取值,具体可参阅RFC文档。
当Type为Magic Number时,长度为 4 Bytes,值随机,答复的时候要带上用于辨识答复方数据可靠性。
其他的Type含义参阅RFC文档,这里所说的是几个比较重要的Type值,这几个是实现PPPoE服务器中必须处理和了解的几个值。

LCP Discussion阶段中双方互相发送Configuration Request,相互确认对方的信息,同意回复Configuration ACK并携带对方的Request信息。
如果不同意对方的Request,这时候回复NAK,并且在NAK中携带自己期待的配置信息,收到NAK之后如果接受列出的配置,带上NAK中的配置重新Configuration Request。
如果发现对方报文中存在错误,这时候需要回复Reject,并且携带对方报文中意义不明或者错误的信息内容等待进一步答复。

比如 Configuration Request: Auth Type 0x0000,这时候接收方会回复Configuration Reject: Auth Type 0x0000,相当于该信息我不知道它对不对,反正我这解析不出来,我不管你得换一个。

LCP Discussion过程可能会来回多次,反复确认双方配置(Request–NAK–Request–Reject–Request–…),如果在多次Configuration依旧无法协商完成只能LCP Terminate Request结束这个短暂的邂逅了。虽然这种情况一般很少见,但也不排除,相当于两个人谈一场交易,结果怎么也谈不拢,那交易肯定也没法进行,再死皮赖脸的协商怕不是要打一架了。

其实这个过程看起来就跟两个人在进行一场协商一样的不是吗www?
用自然语言表述这个过程可以编这么一个对话

A:请求:我可接收最大重量为1484的包裹,暗号7A908B06,请确认。
B:OK我方收到,已知阁下可接收最大重量为1484的包裹,答复暗号7A908B06。
B:另外我方最大可接受重量为1400的包裹,认证方式编码C023,暗号7A908B07,请确认。
A:哈?你现在还在用C023认证?你不怕泄密吗?回绝(Reject)认证方式编码C023,你得换一个,答复暗号7A908B07。
B:真是事多……重新请求:我方最大可接受重量为1400的包裹,认证方式编码C223+05,暗号7A908B08,请确认。
A:等等,1400最大重量太小了吧,我这边接受不了,拒绝(NAK),你得把配置换成这样:最大可接受重量为1450的包裹,认证方式编码C223+05,答复暗号7A908B08。
B:(MMP……)行行行,再次请求:我方最大可接受重量为1450的包裹,认证方式编码C223+05,暗号7A908B09,这回可以了吧?
A:OK我方收到,你们最大可接受重量为1450的包裹,认证方式编码C223+05,答复暗号7A908B09,已确认。

Auth(认证)

LCP协商之后接下来就是认证了。
由于认证的方式是在LCP阶段确认的,所以这里根据不同的认证方式有两种数据组织方式

PAP

PAP阶段Code取值有

0x01……….Auth Request
0x02……….Auth ACK
0x03……….Auth NAK

当Code为Auth Request时Data组织形式如下

Peer-ID-Length Peer-ID Password-Length Password
1 Bytes x Bytes 1 Bytes x Bytes

其中Peer-ID就是用户名,Password为密码。两个Length都是指后面数据长,不包括Length所占用的字节。
从这里不难看出,PAP直接携带用户名密码,并且所支持的最大用户名长和密码长都是255字节。
使用PAP方式,客户端直接发送PAP-Auth Request,服务器收到报文后解析用户名密码判断该用户是否合法,认证成功返回Auth ACK,否则返回Auth NAK。

当Code为Auth Ack或者Auth NAK的时候,后面Data就是一个字符串,以0x00结尾,返回一个认证信息给客户端,信息内容可以随意填写,没有要求。

比如你可以在Auth ACK之后跟上信息:Authentication Failed! Rua!,没错就是可以这么傲娇。

CHAP

CHAP阶段Code取值有

0x01……….Challenge
0x02……….Response
0x03……….Success
0x04……….Failure

当Code为Challenge或者Response的时候Data组织形式如下:

Value Size Value Name
1 Bytes x Bytes y Bytes

其中Value Size表示Value长度,一般是16。Name为用户名,以0x00结尾。
Value一般是16字节的数据,各个阶段意义略微有区别。
当时用CHAP认证的时候,服务器首先发送Challenge消息,里面的用户名可以为空。
客户端收到Challenge之后,通过之前商讨的挑战方式,重新计算Value,并携带用户名,发送Response给服务器。
服务器通过客户端答复的Value判断认证是否成功,成功返回Success,否则返回Failure。

同样的当Code为Failure或者Success的时候,后面Data是一个返回给客户端的字符串,表示认证信息。

MD5挑战模式下,Challenge的期望值为:MD5(id + password + value)。
其中id为PPPoE Session阶段携带的Identifier,value为服务器Challenge发过来的值。计算完之后重新放入Value返回给服务器。
服务器收到之后也会用同样的方式处理,对比两者结果是否一致判断用户是否合法。

认证失败一般紧接着就会发送LCP Terminate Request断开链接,释放当前Session。

IPCP Discussion

认证完成之后就是IP协商了。
IPCP全称 IP Control Protocol,IP控制协议,用于控制接入设备的IP配置信息。
IPCP阶段Code可以取值:

0x01……….Configuration Request
0x02……….Configuration ACK
0x03……….Configuration NAK

Data组织形式为:

Type Length IP Address
1 Bytes 1 Bytes 4 Bytes

Type可取值

0x03……….IP
0x81……….DNS1
0x83……….DNS2

Length为总长,Length = 6。
从这里不难发现,PPP接入下没有子网掩码,因为在PPP模式下不存在子网概念,所有设备相互独立,所以客户端一般在配置PPP网络的时候习惯性将子网掩码设置为255.255.255.255。

IPCP流程
服务器首先发出一个IPCP Request报文,只带0x03字段,这个报文告知客户端服务器的IP地址信息。
客户端一般在收到服务器发来的IPCP Request报文之后才发送IPCP Request请求自己的IP地址。
一般情况下,客户端发过来的请求中携带的IP信息为0.0.0.0,也有可能是上次认证时分配到的IP。
服务器收到客户端的IPCP Request之后判断配置信息是否正确,正确回复ACK,否则回复NAK并附上正确的IP配置信息。

这个过程其实跟LCP Discussion过程类似,只是起手动作需要服务器发起,客户端需要先确认服务器IP才会进行接下来的确认。
后续流程除了没有Reject消息,跟LCP Discussion流程是一样的,对了回复ACK,不对回复NAK并携带上所需的信息。

IPCP协商完成之后,PPP链接建立过程结束。

PPP链接建立之后

PPPoE链路建立之后,上文也提到后续的数据依旧是以PPPoE Session方式发送,不过P2P Protocol的值变为0x0021(IPv4)
这时候,一般的网卡是无法解析该消息的,需要把PPP消息中PPPoE部分剔除封装成普通的IPv4报文,再发送给相关设备,这样网卡才能处理该消息。
这个策略可以考虑使用假MAC的方式,PPPoE服务器通过假MAC发送消息给相关设备,相关设备的信息发送回来之后PPPoE服务器截获该消息(其实WinPcap直接就能收到)然后重新用PPP封装在发送给客户端。
换句话说,PPPoE链路建立之后,通讯过程依旧跟不同的IPv4通信相差很大。

其他一些注意事项和技巧

  • WinPcap监听会监听到Destination非自己的报文,包括自己发的,如果不过滤Source会造成报文没有被过滤,自己的报文自己答复接着进入死循环浪费资源。这点需要注意
  • LCP控制报文中如果收到Echo Request需要及时回复Echo Reply,如果没有答复Echo Request,超过一定次数之后会使对方认为链路断开,链接丢失。所写的PPPoE也应该具备这个机制,毕竟Session资源紧张。
  • Session报文的Identifier变化一般有两种思路,当然这个策略也可以自己设计

    1.当没有回复的时候使ID + 1重新发送,直到得到答复之后ID重置为0发送下一个消息。
    2.当Package的类型改变的时候重制ID为0,否则ID递增。

  • LCP的Echo Request心跳报文中,ID应该只随心跳次数递增,双方个自己记录心跳情况。

  • LCP/IPCP都需要双方各一个Request和ACK之后才可配置好链接相关信息。
  • Session建立过程中,如果在某阶段耗时过长即可认为流程超时,断开并清理当前Session。
  • 为了保证报文质量,PPPoE建立过程中,所有报文长度最短应为60字节,不够应当补齐。

写在最后

看完PPPoE协议的内容,是不是有种晕头转向的感觉?
确实DHCP协议与PPPoE协议比起来简直是小巫见大巫,毕竟链路层协议,复杂程度肯定是要上升的。
不过也不需要太敬畏它,PPPoE依旧只是一个协议,一个准则而已,有死板的地方,也有可以搞事的地方(喂)。
总的来看其实PPPoE协议就是一层一层展开的,理解了PPPoE协议其实你也就理解了网络分这么多层到底有什么意义了。
网络报文其实就是约定好的一层一层数据组装到一起,按照一定模式一定能够将其解开,这样的设计还方便了各部分只关注自己所需要关注的部分,省去了很多解析上的麻烦,只能感叹当年这些网络工程师的智慧。
这里面的很多策略都是可以自己发挥的地方,可以尝试一下设计一套自己的高效的策略。
设计PPPoE服务器最关键的地方就是学会链路层编程,理解网络报文这种层级关系,理解PPPoE协议中各个部分所需要遵循的规则(比如CHAP认证时的Challenge规则)。
由于PPPoE服务器在后期通信中依旧担当一个举足轻重的角色,所以PPPoE服务器对服务器要求很高,普通电脑性能不好的话是无法承担这个任务的,这就是为什么很少在PC平台下有PPPoE服务器软件的原因。
目前商用的PPPoE服务器都是各厂商自己设计好的一套解决方案,而不简单是一个软件,里面设计好的各个单元不同分工,这样才有能力承接PPPoE的所有工作。
所以我们设计PPPoE服务器并不是说要在普通PC上实现能用的PPPoE服务器,而是通过写PPPoE服务器的过程,理解链路层编程,理解网络分层结构,这才是最终目的。

可以拓展的地方:不适用WinPcap,使用更底层的C完成PPPoE服务器编程,这样效率更高,说不定性能可以达到和一些PPPoE服务器持平。

希望本文对你有所启发,Thanks for Reading!

相关文献

RFC2561(PPPoE)
RFC1661(PPP)
RFC1570(LCP Etensions)
RFC2484(LCP Option)
RFC1334(PAP)
RFC1994(CHAP)
RFC2865(RADIUS)
RFC1332(IPCP)
RFC1877(IPCP DNS)

加载评论