【实验】PPP 的 CHAP 单双向认证配置（用真机做） – CCIE 工程师社区 |
您所在的位置：网站首页 › 谷歌双向认证什么意思啊 › 【实验】PPP 的 CHAP 单双向认证配置（用真机做） – CCIE 工程师社区 |
【实验】PPP 的 CHAP 单双向认证配置（用真机做） – CCIE 工程师社区
如需注册 @ccie.engineer、@ccde.engineer、@ccar.engineer、@hcie.engineer、@rhce.engineer 和 @cissp.engineer 邮箱，请点击这里。
实验前的一些描述：
 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 验证阶段是这样的： 服务器端主动发送验证请求，验证请求包格式：自己的主机名 | 随机码； 客户端接收到服务器端发送的验证请求后，会将请求包中的主机名和随机码提取出来，在自己的本地账号和密码中，查找与主机名匹配的密码。将匹配的密码和收到的随机码一起 hash 得到一个 hash 值，然后将自己的主机名和 hash 值发送给服务器端。 服务器端收到客户端的回应后，首先提取出主机名，查找与主机名匹配的本账号中的密码，将此密码和随机码一起 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 页
接下来 Ricky 会用真机来做上述几个 CHAP 实验，来验证一下哪些是可以的，而哪些是不可以的。 实验环境： 使用两台 Cisco 2811 路由器，IOS 是目前最新的 c2800nm-adventerprisek9-mz.151-4.M10.bin 【实验】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 信息也显示验证失败，可能验证的时候，还是需要两边的密码必须保持一致！
本文完。如有疑问，欢迎在下方留言；如本文有什么错误，欢迎在下方留言指正，谢谢。 打赏分享 |
【本文地址】
今日新闻 |
推荐新闻 |