欢迎关注:1,欢迎关注本博客,你可点击右手边的【QQ邮件订阅】订阅本博客!2,本博客推出江湖救急计划,主要为工作中遇到疑难杂症的兄弟提供远程技术支持和分析,如有需要,请在江湖救急计划页面给我留言!

谁叫的区块链,来门口取一下!

作者:甜瓜 发布于:2018-3-8 22:09 Thursday 分类:参考资料

  对于要制作虚假交易,除非你说服了全网里超过51%的矿工都更改某一笔账目,否则你的篡改都是无效的。网络中参与人数越多,实现造假可能性越低。这也是集体维护和监督的优越性,伪造成本最大化。说服51%的人造假还是灰常灰常难的。

对于要制作虚假交易,除非你说服了全网里超过51%的矿工都更改某一笔账目,否则你的篡改都是无效的。网络中参与人数越多,实现造假可能性越低。这也是集体维护和监督的优越性,伪...

阅读全文>>

标签: 区块链

评论(0) 引用(0) 浏览(386)

某单位用户接入认证慢故障分析报告

作者:甜瓜 发布于:2018-1-29 9:36 Monday 分类:网络分析

情况概述

1.1  情况简介

某单位的用户在接入内网的时候需要在终端上安装接入认证客户端并进行认证,用户反映认证时间较长需要一分钟左右的时间,认证时间超出了用户体验。


1.2 分析思路

从用户反映的情况初步怀疑是终端认证出了问题,现选取一台终端安装认证接入客户端进行认证操作并且同时抓包还原整个交换过程,对问题进行确认。

分析具体流程

2.1 整个报文过程简述

在安装好客户端后点击认证,大约一分钟后认证成功,通过wireshark过滤会话,截图如下:

                整个交互过程

根据交互行为,从手指点击认证开始到认证成功共产生了9个报文,大约经过了60.6635秒后,INFO信息里面反映Success认证成功,这说明在经过了一分钟后认证才成功,那时间到底是在哪里耽误的,具体分析如下:

2.2 第一次30延时分析

在手指点击认证的时候客户端先发送了一个报文后等待了30.016秒后又发送了一个广播报文。

 

第一个报文是一个携带认证协议的二层的单播包,源MAC是客户端地址,目的MAC是为01:80:c2:00:00:03,暂时不清楚是什么设备的MAC

 

30.016秒后客户端又发出了一个报文广播的内容,源MAC为客户端地址,目前MAC是全F广播地址,携带认证start开始信息。

 

紧接着认证服务器就发起了Request Identity请求报文,这第三个报文

该报文具体内容:源MAC是华为核心交换机的网关MAC,说明认证服务器在收到了广播包后迅速做出了回应,发送了认证请求。

 

 

 

2.3 第二次30延时

客户端在收到了服务器发送的558Request Identity请求报文后又向MAC地址01:80:c2:00:00:03回应了一个包号为559的应用信息是Response Identity的报文,意思是回应认证,但是我们发现MAC地址不是华为核心的地址,而且这个目的MAC与第一个8号报文的目的MAC相同。

由于目的地址错误导致认证服务器没有收到,认证服务器在30秒后重新发送了认证请求980号报文,这时客户端向正确的目的地址华为核心MAC进行了回应,发送了981号报文。

 

后面984985990号报文的延时时间也非常小,984985是客户端与服务器进行MD5校验过程,990是认证服务器告知客户端认证成功。

 

2.4 小结

客户端的发送第一个8号报文是一个二层单播MAC,目的MAC地址01:80:c2:00:00:03和本次认证过程无关,导致30秒后客户端发送了557号广播报文,核心应该是开启了代理功能代收并转发了二层广播包给认证服务器,认证服务器向客户端发送了认证请求报文558号,而客户端收到后却发送了目的MAC01:80:c2:00:00:03559号的认证回应报文,按道理目的地址应该是网关的MAC,所以网关没有收到该认证回应报文,所以又耽误了30秒。通过分析认定第一个8号和559号目的MAC地址01:80:c2:00:00:03是客户端主动发出的。

 

 

 

3     结论

通过认证过程的报文交互行为分析,认证慢的原因是认证客户端在认证过程中发送了与认证不相关的目的MAC地址01:80:c2:00:00:03导致的,认证客户端自身存在问题。


 

4     解决办法

把客户端设置选项中的发送方式由之前的智能识别改成广播后,认证时间由原来的一分钟变成了30多秒。

 

认证报文数量由原来的9个变成了8个,认证时间变成了30.06秒。

             修改配置后的交互 

 

我们发现客户端在向认证服务器回应的时候还是发送了错误的MAC地址01:80:c2:00:00:03,报文号是285,导致产生了接近30秒的延时

产生该现象应该和认证客户端配置文件有关,需要和认证软件厂家的研发进行协作,让厂家修改客户端配置文件解决这30秒的延时,如果修改成功可以再减少30秒的延时

阅读全文>>

标签: 疑难故障 二层认证 接入认证 接入认证慢 认证故障

评论(1) 引用(0) 浏览(490)

某教育平台链接打开慢分析过程

作者:甜瓜 发布于:2017-9-12 10:08 Tuesday 分类:网络分析

某教育平台链接打开慢分析过程

况描述

  用户反映在登录某市教育资源公共服务平台后点击打开基础教育资源的时候页面出来的非常的慢。而打开别的教学资源非常的快,通过了解基础教育资源是该平台的一个链接。


1


阅读全文>>

标签: 链接 重定向 URI HTTP 302

评论(0) 引用(0) 浏览(901)

某集团公司内网访问业务慢分析报告

作者:甜瓜 发布于:2017-7-28 10:21 Friday 分类:网络分析

 

1情况概述

1.1  网络拓扑结构

某集团公司的服务器通过代理服务器向内外网用户提供业务访问,用户每次访问都是与反向代理服务器交互数据,代理服务器是透明模式部署,每次用户进行访问代理服务器的时候代理服务器都会向真实服务器调用业务资源。

      

拓扑示意图

1.2 情况简介

用户反映办公网楼层的用户在访问业务会出现卡顿现象,时间大约都在十几秒左右,外网登录只需要5秒之内。

1.3 分析思路

前期用户在反向代理服务器同一网段的位置部署了一台测试客户端,发现登录时间正常没有出现卡顿现象,整个登录时间大概都控制在5秒之内。说明该故障是局部性的,所以我们对问题区域到业务区域的路径进行梳理,逻辑结构如下:

该区域用户在访问业务的时候产生的报文会先经过楼层交换机,经过楼层核心再经过IPS、防毒墙、Juniper防火墙等安全设备再到反向代理服务器,反向代理服务器收到客户端请求后会把请求再进行转发,转发后的请求再次经过Juniper防火墙到主核心再到真实服务器。真实服务器对请求进行响应,响应数据从源路径返回。

    

 

业务路径图


 

2分析具体流程

2.1 抓包位置选取

在问题区域选取一台PCIP地址是XX.XX.4.78进行登录测试,并且在测试PC<