排查网络故障：登录cacti后单击链接或菜单弹出登录框

 

一. 环境描述

         1. 网络拓扑描述

        

         2. 软件环境描述

          服务端：区域B： cacti 网络监控系统

          客户端: 区域C:  Firefox, IE 浏览器

二. 故障描述

         1. 在区域C的一台电脑上打开区域B的cacti网络监控系统Web页面

           输入用户名和密码后，单击登录按钮，一次或多次，登录成功

      登录后，单击页面的菜单项，或者其他链接，即被弹出，重新出现登录框，等待输入

      有时，点击一个连接即被弹出，有时点击若干个链接后，即被弹出。次数不确定。

        

         2. 疑问：根据上边的故障描述，判断是数据流在某一节点被过滤或者丢弃

       但不能理解，如果数据包被过滤，丢弃，应该是打开缓慢或者无法显示，无法打开

       为什么是每次单击链接被弹到登录框

三. 排查过程

         (1) 范围排查：

         1. 在区域C遇到故障，情况如故障描述内容

         2. 远程桌面到区域B 网络1 (与cacti-web处于同一网段的主机)，多次点击链接未遇到        上述故障，因此判断数据包在区域B是正常的，排查范围扩大至区域A

         3. 远程桌面到区域A，测试，故障现象同区域C, 排查范围收缩至区域B

         4. 远程桌面到区域B 网络2, (与cacti-web处于相邻网段的主机)，故障现象复现

         5. 排查范围限制到区域B， 网络1的上联。此时，具体哪个节点设备影响，不知

        

         (2) 应用分析：抓包分析

         分别在cacti-web上， 区域C的电脑上抓包，目标IP: cacti  端口:80

         1. 客户端浏览器一侧首先向cacti侧发送fin包，然后对端回fin包，最终断开连接

         2. 经过折包发现，浏览器发送fin包之前，收到cacti侧发送的数据包中的http头

      该http头中包括一个字段: connection: close。 这个字段说明：服务器主动告诉客户

           端浏览器：“你断开连接吧”，然后客户端主动发送fin包，以断开连接

           经多次抓包，每次弹出登录框，都有fin包的发送。

           为什么cacti侧总是要求客户端浏览器断开连接呢？

 

         (3) 应用分析: 分析用户登录过程，登录用户访问页面的过程

           1. 当用户打开cacti页面时，即发送一个get   后，从服务器cacti侧下

                  载了登录页面的html.

           2. 然后，输入用户，密码，点击登录，再post给Cacti服务端

      3. 服务端收到用户名，密码后生成一个cookie: 键为cacti, 值为一个随机字串，这个

                   cookie就是登录凭证。因为浏览cacti里的页面链接，都要使用该cookie串，识别

         已经认证过的用户。

           4. 如果已经认证的用户，点击Cacti里有链接，即再次发起新的get请求，获取相关

                  URL资源，发送的包http头中包含认证过的cookie串。如果该cookie串与登录时

        Cacti服务器所给的相同，则允许访问，如不一致，则将用户弹出到登录框

           5. 原理知道了，那就从浏览器cookie方面排查

           6. Firefox 浏览器：菜单【工具】，【页面信息】，【安全】，【查看cookie】可以查看

                  当前页面的cookie, 会发现无论是cacti登录页面，还是登录之后的页面，都有一个

        key为cacti的cookie.

      7. 经过多次反复测试：每次被弹出到登录框后，key=cacti的cookie的值都会变。

        而在区域B的主机上，访问是正常的，查看cookie，无论点击哪个cacti链接，无

        论点击多少次，它的key=cacit的cookie值都不会变，也不会被弹出登录页面

           8. 因此推测，客户端浏览器收到的响应包中http头部分有set-cookie字段，即响应

        包重置了浏览器原有的key=cacit cookie的值。

    (4) 验证推测：继续抓包，拆包

                  1. 客户端浏览器侧抓包，发送从Cacti发回的响应包中的确有set-cookie字段，且

           之后浏览器使用新设置的cookie获取Cacti URL资源

        2. 从Cacti服务器侧抓包，没有找到服务器发送set-cookie包，而且两边抓取的包

           个数明显对不上。

        3. 结论：中间设备，过滤且修改了数据包中应用层部分。经过询问区域B的相关

                                   人员，最近为保护服务器区免受外部攻击，在网络中增加了应用防火墙

                  4. 进一步验证：将Cacti的IP改为同网段的另一个IP地址。区域C，区域A的访

           访问均正常。说明 应用防火墙生成了某些策略，最终影响了Cacti的正常访问

                  5. 稳妥的解决办法：在应用防火墙中，将Cacti加入白名单或者选择适当的策略

 

 

四. 相关知识点

         1. 了解wireshark抓包工具的使用

    2. 了解TCP 3次握手

    3.  了解TCP协议的seq, ack如何计算

                  seq与ack的累加是对内容长度的累加，即TCP层数据段的长度累加

        而不是数据包长度的累加

    4. 了解http协议要加强了解。

       最初不理解，为什么总是客户端浏览器首行发起fin包，终止连接。

       实际上是Cacti 服务端从应用层，即http头的connection: close 字段告诉客户端关闭

       连接的，然后才是客户端发起fin包，终止连接

    5.  了解长连接与短连接，协议规定是一回事，软件实现是另一回事。

                  协议规定大框架，软件实现除了大框架，还要考虑细节，有出入是正常的

        注意apache 2.2.15 默认是不开启长连接，如何需要，须手工打开。

         6.  TCP的滑动窗口：如何进行流量控制

        

五. 收获

   1. 对不完全确定的事情，不能轻易说出口

   2. 对于协议不熟悉，对应用程序内部流程不了解，对系统底层不清楚，是分析，解决问     题的三大障碍，因此，对运维来说，多学点开发知识，多了解系统底层是有益无害的。

   3. 分析问题需要较强的逻辑判断能力和坚决的执行力，不轻易说放弃

   4. 解决问题的方法有两种，一是解决它，搬开脚下的石头， 二是绕过它，实在搬不动，

     就得绕开它。在适当的时候，选择适当的方法！！！