【实验】PPP 的 CHAP 单双向认证配置(用真机做)

 如需注册 @ccie.engineer、@ccde.engineer、@ccar.engineer、@hcie.engineer、@rhce.engineer 和 @cissp.engineer 邮箱,请点击这里

实验前的一些描述:

PPP的CHAP单双向认证配置的网络拓扑
PPP的CHAP单双向认证配置的网络拓扑

1、CHAP 认证命令:

cisco(config)#interface s0/0
cisco(config-if)#encapsulation ppp
cisco(config-if)#ppp authentication chap // 该命令只用于开启认证的服务器端,代表在接口
下开启 PPP CHAP 认证;如做双向认证,则双方都要配置该命令

2、CHAP 单向认证:(R1 为服务器端,R2 为客户端)

R1:CHAP 单向认证

conf t

username R2 password R2

int s 0/0
ip add 12.1.1.1 255.255.255.0
encapsulation ppp
ppp authentication chap

R2:CHAP 单向认证

conf t

int s 0/0
ip add 12.1.1.2 255.255.255.0
encapsulation ppp
ppp chap hostname R2
ppp chap password R2

3、CHAP 双向认证:

在 CHAP 双向认证中,可以设置认证的用户名为对方设备的 hostname,并设置相同的密码,这样就不需要在端口上配置命令 ppp chap hostname xx 和 ppp chap password xx 了。例如:

R1:CHAP 双向认证

conf t

username R2 password CCIE.LOL

int s 0/0
ip add 12.1.1.1 255.255.255.0
encapsulation ppp
ppp authentication chap

R2:CHAP 双向认证

conf t

username R1 password CCIE.LOL

int s 0/0
ip add 12.1.1.2 255.255.255.0
encapsulation ppp
ppp authentication chap

如果设置的用户名不是对方设备的 hostname 也是可以的,只要保证两边设置的密码相同即可,例如:

R1:CHAP 双向认证

conf t

username B password CCIE.LOL

int s 2/0
ip add 12.1.1.1 255.255.255.0
encapsulation ppp
ppp authentication chap
ppp chap hostname A
no sh

R2:CHAP 双向认证

conf t

username A password CCIE.LOL

int s 2/0
ip add 12.1.1.2 255.255.255.0
encapsulation ppp
ppp authentication chap
ppp chap hostname B
no sh

那能不能像下面这样配置呢?两边的用户名不相同,密码也不相同?

R1:CHAP 双向认证

conf t

username R2 password R2

int s 0/0
ip add 12.1.1.1 255.255.255.0
encapsulation ppp
ppp authentication chap
ppp chap hostname R1
ppp chap password R1

R2:CHAP 双向认证

conf t

username R1 password R1

int s 0/0
ip add 12.1.1.2 255.255.255.0
encapsulation ppp
ppp authentication chap
ppp chap hostname R2
ppp chap password R2

答案是不可以!

为什么两边的用户名和密码都不相同的时候,CHAP 建立不起来?

答:这是由 CHAP 的工作机制决定的。简要说来,CHAP 验证阶段是这样的:

  1. 服务器端主动发送验证请求,验证请求包格式:自己的主机名 | 随机码;
  2. 客户端接收到服务器端发送的验证请求后,会将请求包中的主机名和随机码提取出来,在自己的本地账号和密码中,查找与主机名匹配的密码。将匹配的密码和收到的随机码一起 hash 得到一个 hash 值,然后将自己的主机名和 hash 值发送给服务器端。
  3. 服务器端收到客户端的回应后,首先提取出主机名,查找与主机名匹配的本账号中的密码,将此密码和随机码一起 hash 得到一个 hash 值,这个 hash 值如果与接收到的 hash 值一样则验证通过。

因为 CHAP 在认证过程中,是不传递密码的,传递的是 hash 值,如果两边算得的 hash 值一致,则认证成功。既然两边都要使用密码来做 hash,所以就要求两边输入的密码必须一致。

(PS:上述验证过程摘自:http://bbs.hh010.com/thread-398405-1-1.html)

在《 CCNA 学习指南:Cisco 网络设备互连(ICND2)(第三版)》(2008 年 9 月第 1 版)这本书的第 254 页,也说明了这个问题:

《 CCNA 学习指南:Cisco 网络设备互连(ICND2)(第三版)》(2008 年 9 月第 1 版)第 254 页
《 CCNA 学习指南:Cisco 网络设备互连(ICND2)(第三版)》(2008 年 9 月第 1 版)第 254 页

接下来 Ricky 会用真机来做上述几个 CHAP 实验,来验证一下哪些是可以的,而哪些是不可以的。

实验环境:

【实验】PPP 的 CHAP 单双向认证配置(用真机做)
【实验】PPP 的 CHAP 单双向认证配置(用真机做)

实验需求:

在 R1 和 R2 上做单双向 CHAP 认证。其中在做单向 CHAP 认证时,R1 是服务器端,R2 是客户端。

实验 1 —— CHAP 单向认证:

R1:CHAP 单向认证

conf t

username R2 password R2

int s 0/0/0
ip add 12.1.1.1 255.255.255.0
encapsulation ppp
ppp authentication chap
no sh

R2:CHAP 单向认证

conf t

int s 0/0/0
ip add 12.1.1.2 255.255.255.0
encapsulation ppp
ppp chap hostname R2
ppp chap password R2
no sh

看下 R2 是否能 ping 通 R1:

R2#p 12.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

可以,没问题!

实验 2 —— CHAP 双向认证(用户名使用对端 hostname,密码两边相同):

R1:CHAP 双向认证

conf t

username R2 password CCIE.LOL

int s 0/0/0
ip add 12.1.1.1 255.255.255.0
encapsulation ppp
ppp authentication chap
no sh

R2:CHAP 双向认证

conf t

username R1 password CCIE.LOL

int s 0/0/0
ip add 12.1.1.2 255.255.255.0
encapsulation ppp
ppp authentication chap
no sh

看下 R2 是否能 ping 通 R1:

R2#p 12.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

可以,没问题!

实验 3 —— CHAP 双向认证(用户名两边自行定义,密码两边相同):

R1:CHAP 双向认证

conf t

username B password CCIE.LOL

int s 0/0/0
ip add 12.1.1.1 255.255.255.0
encapsulation ppp
ppp authentication chap
ppp chap hostname A
no sh

R2:CHAP 双向认证

conf t

username A password CCIE.LOL

int s 0/0/0
ip add 12.1.1.2 255.255.255.0
encapsulation ppp
ppp authentication chap
ppp chap hostname B
no sh

看下 R2 是否能 ping 通 R1:

R2#p 12.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

可以,没问题!

实验 4 —— CHAP 双向认证(用户名使用对端 hostname,密码两边不相同):

R1:CHAP 双向认证

conf t

username R2 password R2

int s 0/0/0
ip add 12.1.1.1 255.255.255.0
encapsulation ppp
ppp authentication chap
ppp chap hostname R1
ppp chap password R1
no sh

R2:CHAP 双向认证

conf t

username R1 password R1

int s 0/0/0
ip add 12.1.1.2 255.255.255.0
encapsulation ppp
ppp authentication chap
ppp chap hostname R2
ppp chap password R2
no sh

看下 R2 是否能 ping 通 R1:

R2#p 12.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.1.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

ping 不通了!

我们现在打印 debug 信息来看一下。

因为是真机实验,要想 debug 信息能输出到 telnet 上,还需要这么做:

Telnet 到 Cisco 设备的终端模式无法显示本地串口模式下的 debug 信息,需要使用以下命令:

打开终端显示:
R7#terminal monitor

打开日志功能:
R7(config)#logging on

设置日志级别为 debug 模式(7 为 debug 模式):
R7(config)#logging monitor 7

通过以上三条命令就可以在 Telnet 终端下看到 debug 的打印信息了。

很快,你就能看到接口在不断地 up 和 down:

*Jan 15 13:26:54.939: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0,
 changed state to up
*Jan 15 13:26:54.947: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0,
 changed state to down
*Jan 15 13:27:03.067: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0,
 changed state to up
*Jan 15 13:27:03.075: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0,
 changed state to down
*Jan 15 13:27:17.243: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0,
 changed state to up
*Jan 15 13:27:17.251: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0,
 changed state to down
*Jan 15 13:27:23.295: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0,
 changed state to up
*Jan 15 13:27:23.331: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0,
 changed state to down
*Jan 15 13:27:29.435: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0,
 changed state to up
*Jan 15 13:27:29.443: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0,
 changed state to down

然后 debug 一下 CHAP:

R2#debug ppp authentication

很快,我们就能看到以下关于 CHAP 认证失败的 debug 信息:

R2#
*Jan 15 13:30:34.307: Se0/0/0 PPP: Using default call direction
*Jan 15 13:30:34.307: Se0/0/0 PPP: Treating connection as a dedicated line
*Jan 15 13:30:34.307: Se0/0/0 PPP: Session handle[3A0000A6] Session id[164]
*Jan 15 13:30:34.335: Se0/0/0 CHAP: O CHALLENGE id 1 len 23 from "R2"
*Jan 15 13:30:34.335: Se0/0/0 CHAP: I CHALLENGE id 1 len 23 from "R1"
*Jan 15 13:30:34.335: Se0/0/0 PPP: Sent CHAP SENDAUTH Request
*Jan 15 13:30:34.335: Se0/0/0 PPP: Received SENDAUTH Response PASS
*Jan 15 13:30:34.335: Se0/0/0 CHAP: Using hostname from interface CHAP
*Jan 15 13:30:34.335: Se0/0/0 CHAP: Using password from AAA
*Jan 15 13:30:34.339: Se0/0/0 CHAP: O RESPONSE id 1 len 23 from "R2"
*Jan 15 13:30:34.339: Se0/0/0 CHAP: I RESPONSE id 1 len 23 from "R1"
*Jan 15 13:30:34.339: Se0/0/0 PPP: Sent CHAP LOGIN Request
*Jan 15 13:30:34.343: Se0/0/0 PPP: Received LOGIN Response FAIL
*Jan 15 13:30:34.343: Se0/0/0 CHAP: O FAILURE id 1 len 25 msg is
 "Authentication failed"
*Jan 15 13:30:36.351: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0,
 changed state to up
*Jan 15 13:30:36.355: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0,
 changed state to down
R2#
*Jan 15 13:30:38.355: Se0/0/0 PPP: Using default call direction
*Jan 15 13:30:38.355: Se0/0/0 PPP: Treating connection as a dedicated line
*Jan 15 13:30:38.355: Se0/0/0 PPP: Session handle[C10000A7] Session id[165]
*Jan 15 13:30:38.367: Se0/0/0 CHAP: O CHALLENGE id 1 len 23 from "R2"
*Jan 15 13:30:38.367: Se0/0/0 CHAP: I CHALLENGE id 1 len 23 from "R1"
*Jan 15 13:30:38.367: Se0/0/0 PPP: Sent CHAP SENDAUTH Request
*Jan 15 13:30:38.367: Se0/0/0 PPP: Received SENDAUTH Response PASS
*Jan 15 13:30:38.367: Se0/0/0 CHAP: Using hostname from interface CHAP
*Jan 15 13:30:38.367: Se0/0/0 CHAP: Using password from AAA
*Jan 15 13:30:38.367: Se0/0/0 CHAP: O RESPONSE id 1 len 23 from "R2"
*Jan 15 13:30:38.371: Se0/0/0 CHAP: I RESPONSE id 1 len 23 from "R1"
*Jan 15 13:30:38.371: Se0/0/0 PPP: Sent CHAP LOGIN Request
*Jan 15 13:30:38.375: Se0/0/0 PPP: Received LOGIN Response FAIL
*Jan 15 13:30:38.375: Se0/0/0 CHAP: O FAILURE id 1 len 25 msg is
 "Authentication failed"
*Jan 15 13:30:40.383: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0,
 changed state to up
*Jan 15 13:30:40.387: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0,
 changed state to down

实验 5 —— CHAP 双向认证(用户名使用对端 hostname,密码两边不相同,但密码两边都有):

根据 CHAP 验证机制来看,实验 4 之所以验证失败,是因为本端的数据库里没有对端的密码,从而无法进行 hash 造成的。那如果本端的数据库有对端的密码呢?

R1:CHAP 双向认证

conf t

username R1 password R1
username R2 password R2

int s 0/0/0
ip add 12.1.1.1 255.255.255.0
encapsulation ppp
ppp authentication chap
ppp chap hostname R1
ppp chap password R1
no sh

R2:CHAP 双向认证

conf t

username R1 password R1
username R2 password R2

int s 0/0/0
ip add 12.1.1.2 255.255.255.0
encapsulation ppp
ppp authentication chap
ppp chap hostname R2
ppp chap password R2
no sh

看下 R2 是否能 ping 通 R1:

R2#p 12.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.1.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

还是不可以!端口照样在不断地 up 和 down,debug 信息也显示验证失败,可能验证的时候,还是需要两边的密码必须保持一致!

 

本文完。如有疑问,欢迎在下方留言;如本文有什么错误,欢迎在下方留言指正,谢谢。

这篇文章对你有帮助吗?

相关文章

发表评论?

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据