《TCP/IP详解》实验(四)-用GNS3模拟ADSL拨号
《TCP/IP详解》学习笔记,这次来做ADSL拨号实验,使用GNS3模拟实验,加深了对PPPoE协议的理解,将这个过程记录下来。
一。GNS3安装及配置
GNS3是一款具有图形化界面可以运行在多平台(包括Windows, Linux, and MacOS等)的网络虚拟软件,关于GNS3的安装和配置参照这里。
二。ADSL拨号实验
这次实验拓扑图如下所示
其中R7为拨号客户端,R5和R6上搭建网桥连接以太网和ATM网络,R8是模拟运营商服务器。
路由器均采用c7200模拟,注意选择124版本的。
R5和R6加一个PA-A1的ATM接口,如下图所示
交换机配置如下图所示
R7(拨号客户端)配置
R7#ena
R7#conf t
R7(config)#int dialer 1 //新建虚拟接口
R7(config-if)#encapsulation ppp //ppp封装
R7(config-if)#ip address negotiated
R7(config-if)#dialer pool 1
R7(config-if)#ppp authentication chap callin
R7(config-if)#ppp chap hostname admin
R7(config-if)#ppp chap password cisco
R7(config-if)#int f0/0
R7(config-if)#no ip add
R7(config-if)#pppoe-client dial-pool-number 1 //绑定实体端口
R7(config-if)#no sh
R7(config-if)#exit
R7(config)#do wr
R7(config)#exit
R7#sh ip int br
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 unassigned YES manual up up
SSLVPN-VIF0 unassigned NO unset up up
Dialer1 unassigned YES manual up up
R5配置
R5#ena
R5#conf t
R5(config)#bridge 1 protocol ieee
R5(config)#int a1/0.35 point-to-point
R5(config-subif)#pvc 0/35
R5(config-if-atm-vc)#exit-vc
R5(config-subif)#exit
R5(config)#int a1/0
R5(config-if)#no sh
R5(config-if)#exit
R5(config)#int a1/0.35 point-to-point
R5(config-subif)#bridge-group 1
R5(config-subif)#int f0/0
R5(config-if)#bridge-group 1
R5(config-if)#no sh
R5(config-if)#exit
R5(config)#do wr
R5(config)#exit
R5#sh ip int br
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 unassigned YES unset up up
ATM1/0 unassigned YES unset up up
ATM1/0.35 unassigned YES unset up up
SSLVPN-VIF0 unassigned NO unset up up
R5#
R6配置
R6#ena
R6#sh ip int br
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 unassigned YES unset administratively down down
ATM1/0 unassigned YES unset administratively down down
SSLVPN-VIF0 unassigned NO unset up up
R6#conf t
R6(config)#bridge 1 protocol ieee
R6(config)#int a1/0.38 point-to-point
R6(config-subif)#pvc 0/38
R6(config-if-atm-vc)#exit-vc
R6(config-subif)#exit
R6(config)#int a1/0
R6(config-if)#no sh
R6(config-if)#int a1/0.38 point-to-point
R6(config-subif)#bridge-group 1
R6(config-subif)#int f0/0
R6(config-if)#bridge-group 1
R6(config-if)#no sh
R6(config-if)#exit
R6(config)#do wr
Building configuration...
[OK]
R6(config)#
R6(config)#exit
R6#sh ip int br
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 unassigned YES unset up up
ATM1/0 unassigned YES unset up up
ATM1/0.38 unassigned YES unset up up
SSLVPN-VIF0 unassigned NO unset up up
R6#
R8配置
R8#ena
R8#sh ip int br
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 unassigned YES unset administratively down down
SSLVPN-VIF0 unassigned NO unset up up
R8#conf t
R8(config)#int virtual-template 1
R8(config-if)#ip add 41.1.1.1 255.255.255.0
R8(config-if)#exit
R8(config)#username admin password cisco
R8(config)#aaa new-model
R8(config)#aaa authentication ppp default local
R8(config)#int virtual-template 1
R8(config-if)#ppp authentication chap default //虚拟接口用于在ATM网络上封装PPP
R8(config-if)#exit
R8(config)#bba-group pppoe CLIENT_ADSL
R8(config-bba-group)#virtual-template 1 //关联虚拟接口
R8(config-bba-group)#exit
R8(config)#int f0/0
R8(config-if)#no sh
R8(config-if)#pppoe enable group CLIENT_ADSL
R8(config-if)#exit
R8(config)#ip local pool POOL_ADSL 41.1.1.100 41.1.1.254 //分配拨号地址池
R8(config)#int virtual-template 1
R8(config-if)#peer default ip address pool POOL_ADSL
R8(config-if)#exit
R8(config)#do wr
Building configuration...
[OK]
R8(config)#
R8(config)#exit
R8#
R8#sh ip int br
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 unassigned YES unset up up
SSLVPN-VIF0 unassigned NO unset up up
Virtual-Access1 unassigned YES unset down down
Virtual-Template1 41.1.1.1 YES manual down down
Virtual-Access2 unassigned YES unset up up
Virtual-Access2.1 41.1.1.1 YES TFTP up up
注意:bba-group是一个虚拟拨号组,先前的IOS(12.2(13)T之前)中,PPPOE的拨号是被嵌入到VPDN中,但是后来思科将PPPOE从VPDN中移植出来,嵌入到bba组中;virtual-template是设备所使用的虚拟访问接口,一个PPPOE的拨号连接就是属于虚拟访问的一种,该接口上存放着与虚拟访问有关的三层和二层信息,通常,需要把这个virtual-template与bba-group关联起来,或者在思科的英文文档中叫“cloning(克隆)”该接口到bba组中。
配完后,为了抓到报文,重启一下拨号端口
R7#conf t
R7(config)#int dialer 1
R7(config-if)#sh //关闭接口,再开启,重新拨号
R7(config-if)#no sh
R7(config-if)#exit
R7(config)#exit
R7#sh ip int br
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 unassigned YES manual up up
SSLVPN-VIF0 unassigned NO unset up up
Virtual-Access1 unassigned YES unset up up
Dialer1 41.1.1.100 YES IPCP up up
R7#
三。抓包分析
PPPoE分为两个阶段:
1.PPPoE发现
由于传统的PPP连接是创建在串行链路或拨号时创建的ATM虚电路连接上的,所有的PPP帧都可以确保通过电缆到达对端。但是以太网是多路访问的,每一个节点都可以相互访问。乙太帧包含目的节点的物理地址(MAC地址),这使得该帧可以到达预期的目的节点。 因此,为了在以太网上创建连接而交换PPP控制报文之前,两个端点都必须知道对端的MAC地址,这样才可以在控制报文中携带MAC地址。PPPoE发现阶段做的就是这件事。除此之外,在此阶段还将创建一个会话ID,以供后面交换报文使用。
2.PPP会话
一旦连接的双方知道了对端的MAC地址,会话就创建了。
PPPoE发现阶段(PPPoED)
尽管传统的PPP是点对点协议,但是由于多个主机可以通过一个单独的物理连接连接到一个服务提供者,因此PPPoE本身就是一个客户端-服务器的关系。 发现过程包含四个步骤。主机作为客户端,ISP端的访问集中器作为服务器。这四步在下面详述。最后一步第五步是关闭一个现存会话的方法。
客户端到服务器:Initiation(PADI)
PADI为PPPoE Active Discovery Initiation的缩写。
如果一个用户想要使用DSL拨号连入Internet,那么他的计算机必须首先在其ISP的网络服务提供点(POP)找到DSL访问集中器(DSL-AC)。在以太网上通讯只能通过MAC地址。由于计算机不知道DSL-AC的MAC地址,于是就在以太网上广播一个PADI报文。这个报文中包含发送者的MAC地址。
PADI报文示例:
服务器到客户端:Offer (PADO)
PADO为PPPoE Active Discovery Offer的缩写。
一旦用户计算机发送了PADI报文,DSL-AC就会使用PADI中提供的MAC地址回复一个PADO报文。PADO报文中包含了DSL-AC的MAC地址、名称以及服务名。如果多于一个POP的DSL-AC回复了PADO报文,用户计算机就使用提供的名称和服务来从中选择一个。
PADO报文示例:
客户端到服务器:Request(PADR)
PADR为PPPoE Active Discovery Request的缩写。
当用户计算机收到一个来自DSL-AC的可接受的PADO报文后,就会发送一个PADR报文给DSL-AC,用来确认接受发送PADO报文的DSL-AC所提供的PPPoE连接。
PADR报文示例:
服务器到客户端:Session-confirmation(PADS)
PADS为PPPoE Active Discovery Session-confirmation的缩写。
上面的PADR报文由DSL-AC的PADS报文进行确认,并在其中携带一个会话ID。用户计算机与此DSL-AC的连接现在就完整创建了。
PADS报文示例:
数据传输使用PPP协议
PPP(Point-to-Point Protocol点到点协议)是为在同等单元之间传输数据包这样的简单链路设计的链路层协议。这种链路提供全双工操作,并按照顺序传递数据包。
下面来介绍PPP会话阶段:
用户主机与接入集中器根据在发现阶段所协商的PPP会话连接参数进行PPP会话。一旦PPPoE会话开始,PPP数据就可以以任何其他的PPP封装形式发送。所有的以太网帧都是单播的。PPPoE会话的SESSION-ID一定不能改变,并且必须是发现阶段分配的值。
PPP协议的六个阶段
链路不可用阶段: 初始阶段
链路建立阶段: LCP协商,(协商认证方式等)
验证阶段: PAP/CHAP验证
网络层协议阶段:NCP协商
PPP会话维持阶段: 维持PPP会话, 定时发送Echo Request报文,并等待Echo Reply报文
网络终止阶段: 终止PPP会话,回到链路不可用阶段。
下面的抓包呈现了整个过程
下面逐一来分析
客户端发往服务器
服务器发往客户端
AcK回应报文,表示完全接受对端发来的参数
NaK回应报文,表示对端发来的某些参数不被认可
收到Nak后会重发请求报文,修正参数。
CHAP(Challenge-Handshake Authentication Protocol)验证为三次握手验证,密码为密文(密钥)。
CHAP验证过程如下:
(1)Challenge:验证方主动发起验证请求,验证方向被验证方发送一些随机产生的报文,并同时将本端的用户名附带上一起发送给被验证方;
(2)Response:若被验证方接到验证方的验证请求后,检查本端接口上是否配置了缺省的CHAP密码,如果配置了则被验证方利用报文ID、该缺省密码和MD5算法对该随机报文进行加密,将生成的密文和自己的用户名发回验证方;若被验证方检查发现本端接口上没有配置缺省的CHAP密码,则被验证方根据此报文中验证方的用户名在本端的用户表查找该用户对应的密码,如果在用户表找到了与验证方用户名相同的用户,便利用报文ID、此用户的密钥(密码)和MD5算法对该随机报文进行加密,将生成的密文和被验证方自己的用户名发回验证方;
(3)result:验证方用自己保存的被验证方密码和MD5算法对原随机报文加密,比较二者的密文,根据比较结果返回不同的响应。
接下来到IPCP阶段
经过一系列协商分配获得IP
参考文档:
https://blog.csdn.net/xinyuan510214/article/details/79635015
https://www.jianshu.com/p/be7cc2a5a1e2