1、PPPoe的LCP协商
在这个阶段客户端也就是拨号的发起端会发送PADI报文,也就是发现报文,于是NAS会对其进行响应,然后就是类似DHCP的交互过程,总共涉及四个报文,四个报文的目的就是协商出PPPoe的会话ID。
详细讲解看我的这个:(78条消息) PPPoe的抓包分析(详细)_Mllllk的博客-CSDN博客_pppoe报文抓包
2、PPP的LCP协商
在通过了PPPoe的互相发现的阶段后,客户端与NAS进行进一步的协商,当然第一步就是PPP中的LCP协商,主要就是MRU,魔术字,以及是否进行验证一些与链路相关的参数进行协商。这个阶段完成后如果有验证,那么就是一些验证的报文交互。
3、L2TP隧道建立
当NAS与客户端之间的LCP和验证阶段完成后,就到了网络层的协商,一般是IPCP进行网络层的协商。在普通的PPPoe中,PPP的整个协商由NAS的VT接口全部完成,但是在这种场景下,NAS是不会进行IPCP的协商的,以至于在NAS的VT接口上甚至不用配置IP地址,于是当NAS接收到IPCP的报文后会将该报文交给L2TP的功能模块进行隧道封装,然后将封装后的报文转交给事先人为定好的LNS,报文结构如下图所示:
所以在进行IPCP的报文转发前需要建立L2TP的隧道,这就涉及六个报文,SCCRQ,SCCRP,SCCCN,ICRQ,ICRP,ICCN,这六个报文的作用就是协商隧道ID和隧道会话,隧道ID和隧道会话的主要作用就是区分到达LNS上的流量。隧道建立完成后就可以进行IPCP报文的转发了。
4、IPCP网络层协商
可以看到封装的报文中有效载荷仅只有我用红框框住的地方,其他都是L2TP的隧道封装。该报文到达LNS后,LNS通过报文的拆解发现要将该报文转交给L2TP功能模块,然后L2TP功能再次解封后发现要将该报文转交给VT接口,VT接口最后拿到的就是我上面框住的内容,LNS的VT接口上是一定要配置IP地址的,因为它有的时候不仅要为对端分配地址,而且还要承载着与客户的IPCP报文进行协商的职责。VT接口发现该报文时IPCP的请求协商报文,于是就会对该报文进行响应,然后将该IPCP响应报文发送给L2TP功能模块,然后L2TP功能模块进行隧道封装,然后进行转发。该报文转发到NAS后,NAS会将该报文上传给VT接口,然后VT接口以他自己的名义,也就是以自己为创建该报文的人对客户进行IPCP协商回应。于是通过这么几次的协商,客户最终会得到LNS分配给它的IP地址。如果客户是主机,那么它将会生成默认路由,没有下一条IP,出口就是拨号接口,也就是只要有流量全部从拨号接口出去,这就意味着在这种网络场景下,流量的双方只能是LNS和客户端,当然客户端也可以手动的设置路由,只有目的地址为xxx的时候才从拨号接口出去,如果是其他的普通流量就从正常的上网口出去。如果是网络设备,比如路由器防火墙,那么不会生成默认路由,需要人为手动的设置路由。
当LNS把地址分配出去后会在自己设备上生成对应的主机路由,其中目的地址就是分配出去的IP地址,32位掩码,下一条位VT接口。其实也很好理解,这些回包需要将其发送给VT接口进行PPP的相关的封装才能被NAS的VT接口识别。
可选:
在NAS-Initiated场景中,用户身份认证有两种方案,一种是仅使用NAS对用户做身份认证,另一种是NAS和LNS分别对用户做身份认证(也叫二次认证)。认证方案的选择由LNS侧的配置控制。
- 代理认证
表示仅使用NAS进行用户认证,LNS不对用户再进行二次身份认证。这种方式下,LNS侧的VT接口下不用配置用户认证方式。
- 强制CHAP认证
表示NAS认证完用户身份以后,LNS要求用户使用CHAP方式重新进行身份认证,该方式属于二次身份认证。如果使用强制CHAP认证时,VT接口下的认证方式也要配置CHAP方式。
- LCP重协商
表示LNS不信任NAS的认证结果,要求用户重新与LNS进行LCP协商并进行身份认证,该方式属于二次身份认证。
如果使用LCP重协商时,VT接口下也要配置与拨号用户侧相同的认证方式。
5、数据转发
在上述的协商后,客户端终于得到了LNS分配的地址,客户端此时因为先前已经通过PPPoe协商出了PPPoe的会话ID,所以当它从拨号接口将流量发送出去的时候,NAS接收到后就会知道需要将该报文进行L2TP的隧道封装,然后将该报文进行转发。于是就有下图这样的报文封装:
总结:
这么麻烦的实现,要实现的仅仅是一个验证,而且该隧道没有配备任何的安全加密。在这种NAS inital的网络场景我觉得把应该部署场景不是在企业,因为没有企业的网络接入点是PPPoe拨号的,如果是运营商通过这种PPPoe,然后将远端认证设备放在远处还算说得过去,如果是企业的话就太离谱了。