请教关于封状ppp及验证协议的问题由Anonymous于星期四,08/02/2007-22:30发表作实验时遇到这样一个问题：登录的是０.８的台子为什么ppp封完后都

标题：请教关于封状ppp及验证协议的问题

由 Anonymous 于 星期四, 08/02/2007 - 22:30 发表

作实验时遇到这样一个问题： 

登录的是０.８的台子

1. 为什么ppp封完后都起用chap能通，而同是pap则不同？


2. 同封chap后，连路通，将一端换成pap后仍通；但若开始封不同的验证协议则链路不通．是不是因为链路通之后就无须验证所以换pap已经构不成影响？请教！

杀人游戏哪位仁兄看到过俺的眼镜和实验手册 ?

mj2154 

由 mj2154 在 星期四, 08/02/2007 - 22:43 发表。

没有试验配置，调试记录的问题贴，基本上很难给你正确的答复

harry 

由 harry 在 星期五, 08/03/2007 - 02:00 发表。

是不是因为链路通之后就无须验证所以换pap已经构不成影响？请教！

其它问题由于没有实验具体配置及拓扑，在此不能给你解决，但以上说法是不正确的。不存在这样的现象。

admin 

由 admin 在 星期五, 08/03/2007 - 03:11 发表。

----R1(s1/0)------------(s2/0)R2------ 

R1:

R1(config)#int s1/0
R1(config-if)#encapsulation ppp
R1(config-if)#ppp authentication pap
R1(config-if)#end

R2:

R2(config)#int s2/0
R2(config-if)#en
R2(config-if)#encapsulation ppp

R2(config-if)#ppp  authentication pap
R2(config-if)#end

这样就不通,如果都换成chap就通了,通了再换成pap或者一端换成pap还是通的

由 Anonymous 在 星期五, 08/03/2007 - 03:13 发表。

----R1(s1/0)------------(s2/0)R2------ 

R1:

R1(config)#int s1/0
R1(config-if)#encapsulation ppp
R1(config-if)#ppp authentication pap
R1(config-if)#end

R2:

R2(config)#int s2/0
R2(config-if)#en
R2(config-if)#encapsulation ppp

R2(config-if)#ppp  authentication pap
R2(config-if)#end

这样就不通,如果都换成chap就通了,通了再换成pap或者一端换成pap还是通的

由 Anonymous 在 星期五, 08/03/2007 - 20:07 发表。

高手请指点一下,是台子有问题吗 ?

由 Anonymous 在 星期五, 08/03/2007 - 22:26 发表。

楼主的配置有问题。

PAP认证服务器的配置分为两个步骤：建立本地口令数据库、要求进行PAP认证。

 

如果我们进行单项认证的话配置应该如下

R1:（服务器端）

conf t

ho R1

username R1 password 123----------------建立本地口令数据库

int s1/0

ip add 1.1.1.1 255.255.255.0

no sh

en ppp

ppp authen pap

R2:（客户端）

conf t

ho R2

int s2/0

ip add 1.1.1.2 255.255.255.0

en ppp

ppp pap sent-username R1 password 123-----------发送用户名和密码

 

此时双方都可以通信。我这里是单项认证，双向认证配置方法同单向认证类似，只不过需要将通信双方同时配置成为认证服务器和认证客户端。

由 Anonymous 在 星期五, 08/03/2007 - 22:46 发表。

哦,我配的是双向认证,而且俩边的密码还必须一样的!这单向的还是头次见,非常感谢!可是配双向如果是pap还是不通的!而换chap就通了,是pap与chap的验证机制不同?我只知道 pap是明文传送密码,而chap是经过md5加密的!到低什么原因呢? 还请指教!

由 Anonymous 在 星期五, 08/03/2007 - 22:49 发表。

双向认证的话在两端都要配置建立本地口令数据库，我一会做个实验给你看看 

 

还有就是我刚才做实验发现如果开始两端都一起起chap时，也是不通的，也就是说还是需要数据库的

由 Anonymous 在 星期五, 08/03/2007 - 22:53 发表。

哦,那天忘把用户密码配置粘上去了,真是不好意思!

由 Anonymous 在 星期五, 08/03/2007 - 22:55 发表。

pap的双向认证 

R1:

conf t

ho R1

username R1 password 123

int s1/0

ip add 1.1.1.1 255.255.255.0

no sh

en ppp

ppp authen pap

ppp pap send-username R2 password 123

 

R2:

conf t

ho R2

username R2 password 123

int s2/0

ip add 1.1.1.2 255.255.255.0

no sh

en ppp

ppp authen pap

ppp pap send-username R1 password 123

 

这样配置才是可以通的，你可以在试试看。

由 Anonymous 在 星期六, 08/04/2007 - 00:04 发表。

pap的双向认证 

R1:

conf t

ho R1

username R2 password 123

int s1/0

ip add 1.1.1.1 255.255.255.0

no sh

en ppp

ppp authen pap

ppp pap send-username R1 password 123

 

R2:

conf t

ho R2

username R1 password 123

int s2/0

ip add 1.1.1.2 255.255.255.0

no sh

en ppp

ppp authen pap

ppp pap send-username R2 password 123

我的配置是这样的,红色是和你的不一样的地方你看不你的有问题,我这样配通了!

chap为什么不用加ppp pap send-username R2 password 123这一句呢?我看视频没说有这一句,不过上边讲的好象只配了一下是chap!

那用chap配通以后再换一边为pap怎么还是通的呢?

由 Anonymous 在 星期六, 08/04/2007 - 00:10 发表。

你这样配是可以的，只要R1 send的username和R2上的口令数据库的username相互匹配的就可以了。

由 Anonymous 在 星期六, 08/04/2007 - 00:15 发表。

必须的加ppp pap send-username R2 password 123对不对? 

chap不用加?

后边哪个问题--也那用chap配通以后再换一边为pap怎么还是通的呢

能不能顺便给解决一下?Thank you

由 Anonymous 在 星期六, 08/04/2007 - 00:43 发表。

pap是明文认证, 

而chap是加密的方式认证,

一边是chap,一边是pap当然不通了

由 Anonymous 在 星期六, 08/04/2007 - 00:50 发表。

不对,一边是chap ,另一边是pap是可以通的,我作实验验证了 

待会再告诉你为什么?????????

我先吃饭

由 Anonymous 在 星期六, 08/04/2007 - 00:56 发表。

你说的这个问题就是pap和chap的区别 

 

pap是通过验证远端的用户名和密码是否匹配来进行验证

chap则是发送一个挑战包，然后远端通过自己的数据库的用户名和密码利用md5进行计算后返还一个数值，然后在发送方验证这个数值是否和自己计算出来的数值是否一致进行验证，所以不需要那条命令。

 

而对于chap通后一边换pap还是通的问题，我们可以做一个实验看看

 

配置我就不做了，我们配置完chap后，将一端改为pap，然后把那个端口shutdown后在no shutdown，这时就发现已经不通了。

 

我们打开debug ppp authen信息，发现当chap验证成功后，话端口换成pap，并没有新的验证包产生，也就是说在ppp连通之后，就无需再次进行验证，除非端口断开或者出现故障。当我们把端口打开后，就有PPP: Authorization required这样的信息。所以说验证只是在ppp链路还没有建立起来时启用，当ppp链路已经建立起来后，就不会再有新的验证，即使你的两端验证不是同一类型的。

 

 

以上问题的结论是我通过实验证明的，还未查找相关的书籍进行理论上的验证。等我查好后如果不是这样的情况我会再次说明。

由 Anonymous 在 星期六, 08/04/2007 - 00:59 发表。

我一开始就是这么想的,应该就这么回事儿,通了就无须再验证了

由 Anonymous 在 星期六, 08/04/2007 - 02:01 发表。

总觉得怪怪的，没有道理说会有这种事情。不知道是不是计时器或者最大错误允许范围导致这个现象，但是又没有找到相关的资料。。。不知道什么时候才会down掉，等了快一个小时了还是没有反应？难道真的不用在验证了？

由 Anonymous 在 星期六, 08/04/2007 - 02:02 发表。

PPP可以在任何时候终止链路，这可能是由于载波信号的丢失、验证不通过、链路质量不好、定时器超时或管理员关闭链路。PPP通过交换终止链路的数据包来关闭链路，当交换结束时，应用就告诉物理层拆除连接从而强行终止链路。但验证失败时，发出终止请求得一方必须等到收到终止应答或者重起计数器超过最大终止计数次数才断开连接。收到终止请求的一方必须等对方先断开连接，而且在发送终止应答之后必须等至少一次重起计数器超时之后才能断开连接。之后PPP回到链路不可用状态。 

 

 

 

查到了上面的信息，但是没有具体说明计数器的时间和最大终止计数的次数。。。

由 Anonymous 在 星期六, 08/04/2007 - 02:15 发表。

为什么我将它shutdown之后在打开 

他还是通呀！！！！！！！！！！！！！！！

求救！！！！！！！！！！！！！！！！

由 Anonymous 在 星期六, 08/04/2007 - 02:17 发表。

要先把认证模式改成pap后在shutdown    no shutdown

由 Anonymous 在 星期六, 08/04/2007 - 02:21 发表。

我是那么作的呀我把现象发过去！！！！！！！！！！！！！！！ 

我用的１９２.１６８.０.１１

 

由 Anonymous 在 星期六, 08/04/2007 - 02:26 发表。

Ｒ１上信息

r1#sh run
Building configuration...

Current configuration : 872 bytes
!
version 12.2
no service single-slot-reload-enable
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname r1
!
logging rate-limit console 10 except errors
enable secret 5 $1$RmSI$ag2/0QP2W25IAmvPdJJhJ.
!
username r2 password 0 123
ip subnet-zero
no ip finger
!
no ip dhcp-client network-discovery
!
!
!
!
interface Ethernet0
 no ip address
 shutdown
!
interface Serial0
 no ip address
 shutdown
!
interface Serial1
 ip address 1.1.1.1 255.255.255.0
 encapsulation ppp
 clockrate 64000
 ppp authentication pap
 ppp pap sent-username r1 password 7 055A545C
!
interface BRI0
 no ip address
 shutdown
 isdn x25 static-tei 0
 cdapi buffers regular 0
 cdapi buffers raw 0
 cdapi buffers large 0
!
ip kerberos source-interface any
ip classless
ip http server
!
!
!
line con 0
 transport input none
line aux 0
line vty 0 4
!
end

Ｒ２上信息interface Ethernet0
 no ip address
 shutdown
!
interface Serial0
 no ip address
 shutdown
!
interface Serial1
 ip address 1.1.1.2 255.255.255.0
 encapsulation ppp
 ppp authentication chap
 ppp pap sent-username r2 password 7 075E731F
!
ip kerberos source-interface any
ip classless
ip http server

 

然后将Ｒ１的Ｓ１口shutdown后在打开

r1(config)#int s1
r1(config-if)#shut
r1(config-if)#
02:51:42: %LINK-5-CHANGED: Interface Serial1, changed state to administratively down
02:51:43: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to down
r1(config-if)#no shut

然后做Ｐ测试

r1#p 1.1.1.2

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

？？？？？？？？为什么呀！

由 Anonymous 在 星期六, 08/04/2007 - 02:30 发表。

这是在Ｒ１上打开deb ppp authen 后看到的现象！！！！！！ 

02:59:15: Se1 PPP: Treating connection as a dedicated line
02:59:15: Se1 CHAP: I CHALLENGE id 4 len 23 from "r2"
02:59:15: Se1 PAP: I AUTH-REQ id 4 len 11 from "r2"
02:59:15: Se1 CHAP: O RESPONSE id 4 len 23 from "r1"
02:59:15: Se1 PAP: Authenticating peer r2
02:59:15: Se1 PAP: O AUTH-ACK id 4 len 5
02:59:15: Se1 CHAP: I SUCCESS id 4 len 4

由 Anonymous 在 星期六, 08/04/2007 - 02:45 发表。

是通的,我刚才也做了，可能跟ppp pap sent-username r2 password 7 075E731F这句有关!如果r1 r2 都不加这一句,关了再开是不通的!

由 Anonymous 在 星期六, 08/04/2007 - 03:02 发表。

是的,我认为chap和pap是可以兼容的!!!!!!!!!!!!!!

R2发信息ppp pap sent-username r2 password 7 075E731F给R1并且R1运行的是pap,R2可以通过R1的认证,

而R1有发信息给R2,也可以通过认证,故可以通!!!!!!!!!!!

这可以看成是两个单向认证的组合