PPP认证的验证

使用IE机架一台26与一台28进行测试，设备编号为R2和R5，即版本中的R1和R4，最简单的封装ppp使得接口up，直连ping通！

140607786.png


134611928.png


134624903.png


现在测试单向认证，在R1上面开启认证，R4发送密码进行认证！当然还是由R1发起挑战！

  • 当我在R1的接口上键入ppp authentication chap时，邻居立刻挂掉

140627335.png
上图可以看出R1一直在发送挑战，O应该是表示是自己始发，并应该带上了R1这个用户名！
下图可以看到，R4没法和R1进行认证，因为R4这边什么都没配置！
140642505.png
如果说猜测接口下面的sent password没有作用，那这个时候应该是可以发送认证过去的，但是R1没有数据库，那么我配一个数据库给R1，这个数据库只有用户名，user R4，因为R4会默认使用自己的用户名去认证！
然后发现R1和R4上面的现象还是和原来一样，那么截图看上面的就好了。所以说这个时候应该是没有密码发送过去，所以没法认证。

  • 接下来测试，R4有发送密码的情况，先配置接口下命令测试，在R4接口下发送密码cisco之后，由于R1上面数据库只有用户名没有密码，认证失败，所示现象如下

140707811.png


140719909.png

现在显示的结果和之前就不一样了，现在是认证失败，因为我有密码可以发送了，可以看到下面这张截图里面，使用的是接口上的chap密码，用户名未知源，那就是本台设备的名字了。
我继续测试，先测试把R1的本地数据库条目加上密码，测试！
140732329.png


140750172.png

显示认证成功，那么接口也up了，测试能通，如下图。
140804391.png
或者我们接口下不设置密码，也就是说R4接口上不发送密码，但是全局下配置一个数据库，看是否能认证！
140819446.png
直接在R4接口下no掉密码的时候，接口没有挂掉，因为chap认证成功之后，虽然会再发挑战，但是时间是随机的，并不会立刻生效，那么接口关闭之后再打开，接口就会起不来了，如下图！
140832764.png
然后邻居就起不来了，而且提示没办法认证，R1那边就一直在发挑战，没有收到任何回应，因为R4没有任何密码，无法回应。R1如下图显示！
141003420.png
那现在我在R4全局模式下配置一下username R4 password cisco，看能否认证成功！
141019141.png
发现这个时候依然是不行的，而且提示消息是没有密码！所以说，全局模式下面有数据库是没用的！
不信的话，我再测试一下，接口下有密码，然后全局下有数据库的情况！
141208547.png
接口下发送密码和对端不匹配，就算数据库匹配，无效，因为发送的还是接口密码！所以认证失败！所以接口发送密码是有用的！
补充：在这里又出现了一个神奇的情况，总结一下上面的情况是，当R1开启认证，本地数据库有username R4 password cisco，R4接口下没有发送密码，但是全局数据库里面有一个username R4 password cisco的时候，依然是找不到密码去给R1回应，所以R1一直发挑战，情况在上面有显示。后面的一个实验是，R4接口下面配置发送的密码是错误的，即使数据库里面是对的也没用，但是这个时候的数据库的用户名没和R1匹配，所以自然不行。
接下来就是见证奇迹的时刻！
接下来的实验，演示的是，R1上开启认证，有个本地数据库，R2上接口内没有配置密码，但是有个本地数据库，数据库的用户名是R1，也就是说猜测可能是由于R1发过来的挑战，所以R2认为可以使用这个本地数据库里面用户名是R1的这个条目的密码去应答认证，测试之！！！（这个是回家之后才发现的，所以用gns模拟，应该正确！）

141529393.png


141529236.png

这个时候接口能up，而且debug现象能看到是有密码发送的，而且是通过AAA找到的密码！
141627733.png
然后也能测试ping通！
141640559.png
我们刚刚的情况是R2上面配置的本地数据是user R1的，也就是说当R2收到挑战，可以看到挑战是从R1来的，那么R2会去检查本地数据库，发现有用户名R1的条目，用这个条目的密码去认证，接口UP，直连ping通！
再回顾一下，早前做的不能起来的是什么现象，配置修改如下，只修改了R2这个配置

141655535.png


141710393.png
修改之后R2这边又没办法发送回应了，因为不知道使用什么密码，本地数据库找不到，接口下又没有配置，同样的，R1由于收不到认证回应，会一直在发挑战！
141725125.png
好，接下来我再测试一个，当接口下有配置发送密码，然后也有本地数据库能匹配挑战发送者的用户名时，会使用哪个密码进行认证回应！
又把R2本地数据库还原成user R1 pass cisco，然后接口下发送密码！
141738905.png
这个时候接口下的密码是错误的，但是本地数据库的密码是正确的，使用的是aaa的密码，如下图所示！
141802331.png
接着我把接口下改成正确的，但是本地数据库错误看看！

141820304.png


141833729.png
发现是使用AAA的，而不是线路密码，所以本地数据库密码错误，线路密码对了也没用！！！！
此处很神奇！！！目测是因为发送的挑战带了服务器端的用户名！！！然后客户端如果有本地数据库的话就会去查找本地数据库是否有匹配的用户名，有，则一定会用本地数据库相同用户名后面的密码去回应认证！如果没有才会去看接口下是否使用了密码！！！

  • 现在要测试的就是，当我R4发送的用户名是R1的用户名，且R1的数据库内有的是R1的数据库。认证也会不成功！测试如下！

141850199.png


141901419.png
这时R4没有本地账户，借口下发送的账户名和密码能和R1端数据库匹配，但是结果如下！
141916465.png
接口可以起来，但是会挂掉，后面又会再起来再挂掉！
142001596.png
R4接口在抖动，然后能看到debug消息提示这个挑战被忽略了，因为是用了和我本地一样的用户名！所以R1一直收不到回应，现象如下！
142032793.png
因为没有回应认证不成功，所以一直再发挑战！
142047804.png
接下来我修改接口发送账户R4或者说删掉接口发送用户名，因为那样就会使用默认用户名，那这个时候肯定不会忽略，然后提示认证失败！如下图显示！
142108793.png


142135415.png

我接下来要尝试的是，讲R1的名字也改成R4，看是否会被忽略！
142148934.png
果然忽略的情况出现了！下面是真R4的截图！一直在忽略！
142204101.png
被修改为R4的名字的R1如下图显示，就一直在收不到回应，所以在一直发挑战，而不是认证不成功！
142222558.png
而且这个时候一样，接口会抖动，但是就算是up的也不会通，我们的iou模拟器，接口会一直up，但是也不会通的！
142251229.png
该部分实验到此结束！

  • 由于gns3模拟器实验现象和ppp完全一致！然后我又下班了！下面的双向认证，回家用gns3测试！！！

根据以上论述，基本上双向认证也差不多了，如下图所示！

142345135.png


142402597.png
上图中，R1和R2接口上都要求认证，且都发送密码，但是接口下密码和对端都不匹配，最终认证却能成功，因为其实就是两次单向认证，和上面红字描述一样，通过本地数据库认证成功！效果如下图！
142414939.png


142429129.png

所以这样的互相使用对端的用户名来建立本地数据库的话，密码必须要一样啊！！！！借口下的就无所谓了！！！
接下来测试最后一个，如果本地数据库不使用对端路由器名字来建立！

142445313.png


142459871.png
这样配置突然想起来也是起不来的，现象果然是起不来，如下图！因为这里不仅用到了上面红字内容的结果，还用到了忽略情况的结果（就是当接口下有发送密码时，认为我的用户名是这个，发送挑战带的也是这个）！！
142512980.png


142532415.png

这样的话，认证失败是必然的，因为两边配置的数据库密码不一样啊，但是又都匹配到用本地数据库密码来回应挑战！所以改成密码一样试试！

142600480.png


142600664.png


然后邻居建立成功！如下图所示！
142618832.png
R2上面效果一样，我就不截图了！
所以由此推断！双向认证必须本地数据库密码一样！反正我推断出来是这样的，大半夜的思维也混乱了，但是想想应该是这样的！！！

  • 我会说我还有一个测试么，就是因为双向认证想到的测试，在单向认证时，服务器端借口下ppp chap hostname xx会影响发送的挑战么？

142640427.png
R1做服务器端，有本地数据库，也有发送密码！R2在接口下发送了匹配账户的用户名和密码！其实这个实验匹配与否不重要，就看R1发送的挑战是form什么的！R1配置如下！
142652966.png
然后关闭接口打开接口看debug！现象如下！
142711134.png
果然，这条命令生效了！挑战发送出去的时候带的是huawei而不是R1了！！！
所有测试完毕！！！可能理论上还有点跟不上！！！但是现象完全是清楚了！！！
你弄清楚了么？！！！少年！！！哈哈哈哈！！！！