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

iPhone与Multicast DNS

作者：易隐者 发布于：2012-9-21 20:58 Friday 分类：案例讨论

        前两天看到CSNA论坛上有一个求助帖，原帖连接为：http://www.csna.cn/network-analyst-49133-1-1.html，故障现象大致为：网络经常出现断网情况，抓包发现断网时有大量的DNS包，楼主认为是IPHONE或IPAD在连接公司无线网络时出现的数据包。

       我下载了其数据包文件，并选其中的一个数据包文件进行了大致的分析：
1， 在数据包视图中查看其发包频率，如下图： 

点击查看原图

在1秒的时间内 发送了15542个IPv6的多播报文，这种发包频率，足以影响相关无线路由、交换机等设备的处理性能，而接收方对多播报文的处理流程决定了过多的多播报文对网络和主机的影响，大家可参考本人个人博客中《基于UDP组播实施分片攻击的可能性》一文。

2，我们查看其详细解码： 

点击查看原图

IPV6封装UDP 5353端口的DNS请求行为，经网络搜索相关信息，确认为Multicast DNS（组播DNS）报文；

       经查阅相关资料，苹果系列产品在本地局域网内缺少DNS服务器的环境下，使用Multicast DNS，实现名字和IP地址的解析，每个主机都知道自己的名字，并且会自动响应来自多播报文中针对该名字的请求。 使用Multicast DNS的设备大致工作过程如下：

1，在“.local.”子域下，挑选所需的名字；
2，使用Multicast DNS进行名字查询，看是否有主机已经使用了这个名字；
3，如果收到来自与其他主机的名字解析响应，则在“.local.”子域下重新选择一个名字，直至确认本地局域网内无其他设备使用该名字为止。

       大家可参考苹果支持主页中关于“Multicast DNS”的相关页面：http://support.apple.com/kb/TA20999?viewlocale=en_US；

       这些都明确说明这个报文是iPhone发出的Multicast DNS报文，但是异常之处在于设备发包的频率太快了，而楼主反馈说，“不是每次连接都出现这个问题，只是偶尔会出现”，这也从侧面说明这个异常行为应该是属于iPhone本身跟“Multicast DNS”有关的进程异常导致的，可能是iPhone的BUG亦未可知。

       我在搜索相关信息的时候，竟然找到了一篇跟MAC OS相关的DNS异常问题的帖子，应该属于相关内容了，感兴趣的可以自行查看下面连接：http://blog.sina.com.cn/s/blog_539a3a320100q5dq.html

阅读全文>>

标签: 交换机 分片 解码 故障 UDP 多播 DNS iPhone Multicast DNS 多播DNS 组播DNS IPv6

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

ICMP通讯管理性过滤禁止差错报文（type 3，code 13）

作者：易隐者 发布于：2012-9-20 20:10 Thursday 分类：网络分析

ICMP通讯管理性禁止差错报文的产生

       ICMP通讯管理性禁止差错报文是由于中间设备或服务器对该报文的禁止访问策略而产生的，当一个报文经过某中间设备或达到服务器时，如果中间设备或服务器的管理策略禁止该报文的通过，那么，中间设备或服务器会生成一个目的地址为客户端的ICMP通讯管理性禁止报文，其产生过程如下图所示：

点击查看原图

ICMP通讯管理性禁止差错报文产生过程

ICMP通讯管理性禁止差错报文的封装

        ICMP通讯管理性禁止差错报文的封装格式如下图所示： 

点击查看原图


ICMP通讯管理性禁止差错报文的封装（wireshark）

ICMP通讯管理性禁止差错报文在实际网络分析中的作用

       由ICMP通讯管理性禁止差错报文产生的机制决定了其可以帮助我们快速地发现数据报文被丢弃的位置和原因，从而大大提高了我们定位、解决问题的效率。
       但是，ICMP通讯管理性禁止差错报文也是一把双刃剑，它也可以帮助黑客判断一些安全防护设备的策略和位置，正是基于这种考虑，有时一些设备不发送这种ICMP通讯管理性禁止差错报文。

阅读全文>>

标签: icmp差错 ICMP Type 3 Code 13 ICMP通讯管理性禁止差错

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

连接数相关知识

作者：易隐者 发布于：2012-9-19 19:58 Wednesday 分类：网络分析

       连接数是网络中非常重要的一个概念，在我们学习工作的过程中会经常遇到。下面将针对连接数相关的一些知识点做一些描述。

“连接数”是什么

       不同产品对“连接数”的理解有一些差别，但是主流认为网络中交互双方的五元组信息决定了一个连接。所谓五元组信息是指源地址、源端口、目的地址、目的端口以及协议类型。连接数就是网络连接的数目。基本上TCP/UDP应用根据五元组信息都可以很好的对应于一个连接，但是对于ICMP协议，不同的产品会有一些不同的处理，考虑到ICMP报文在实际工作环境下非常少，相对于TCP、UDP应用的连接数基本上可以忽略，因此不针对此做深入的描述。

并发连接数

       并发连接数是指同时在连接表中的连接数目。端系统和中间系统在处理这些连接时都会设置一个连接超时时间，在超时时间溢出之前，系统会为这些连接分配相应的存储资源。而我们熟知的Syn flood DOS攻击正是利用这个特性来达到攻击效果的。一般而言，并发连接数是衡量一个中间系统性能的指标之一。

每秒新建连接数

       每秒新建连接数是一般是指中间设备在单位时间内（1秒内）所能建立连接的数量，这个参数的大小直接影响中间系统在单位时间内所能建立的最大连接数量，其也是衡量中间系统性能的一个重要指标。

 连接数限制

       连接数限制主要是指端系统或中间系统基于安全（防攻击）、管理（流量控制）等方面的需要而对某些IP的网络连接数量限制在某一范围内的策略。如windows系统中的连接数限制，防火墙路由器等中间系统上的“连接数限制”功能等。
       端系统中的主机防火墙（如linux下的iptables）、操作系统本身、应用程序（Apche、IIS、数据库等）等都可能针对连接数进行限制，而现在常见的中间设备（防火墙、路由器等）基本上都支持连接数限制的功能，大家可以根据实际环境中的设备自行查阅相关手册的连接数有关功能的设置。
       我们随便找个路由器上连接数限制功能设置的截图看看： 

点击查看原图

        我们再来看看IIS连接数限制功能设置的截图：

点击查看原图


连接数限制对网络的影响

       连接数限制策略实施之后，当被限制连接数的IP超出限制的范围，其后续的网络连接将会被端系统或中间系统过滤丢弃，这将导致这些IP在进行网络交互时速度变慢、丢包等情况发生。因此，连接数限制是管理策略性导致网络交互异常的原因之一。
       另外值得注意的是，在实际环境下，虽然端系统或中间系统可能会由于连接数限制功能丢弃部分报文，但是并不是所有设备在丢弃这些报文之后会向源主机发送ICMP差错通告报文，这给我们分析定位带来了一些难度。

阅读全文>>

标签: TCP 五元组 ICMP 连接数 连接数限制 并发连接数 每秒新建连接数

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

一切皆有可能

作者：易隐者 发布于：2012-9-18 17:11 Tuesday 分类：网络分析

       由于故障现场环境的复杂性、设备的多样性、系统本身的不稳定性以及网络运行情况的不确定性，一个故障的产生，可能存在各种各样的原因，有些甚至超乎我们平日的想象。而我们在遇到疑难故障时，经常会主观的认为设备是不会出问题的、运营商是不可能出问题的、业务程序是不存在问题的……但是，事实上，这些都有可能是导致故障产生的根源所在。我们在分析、定位、解决故障的过程中，一定要在严密推理的情况下大胆假设，站在网络交互的本质层面小心求证。

       我们要明白，在网络的世界里，一切皆有可能发生！

阅读全文>>

标签: 疑难故障 故障 稳定 交互 业务

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

关于vista系统机器无法通过防火墙上网的故障分析解决案例

作者：易隐者 发布于：2012-9-17 13:53 Monday 分类：网络分析

【说在之前】：

1，该案例为误开启ARP代理功能导致的疑难故障；

2，该故障的触发是由于XP与vista操作系统发送的免费ARP报文格式不一致导致的；

3，关于ARP代理请参考本博客《ARP代理（Proxy ARP）》一文；关于免费ARP，请参考《免费ARP（gratuitousARP）》一文；

4，跟这个案例分析的原因有关的类似故障案例还有netyourlife论坛上的《为什么VISTA不能穿过ASA》，大家可自行查看比较；

5，针对该案例做的相关实验，请大家参考本博客《关于防火墙的arp代理功能对不同格式的arp报文的处理情况的实验》一文；

【我的案例】：

故障环境

1 网络拓扑 

点击查看原图


2 说明

1、内部机器全部在同一网段，经过一个二层交换机接入防火墙，通过防火墙的NAT访问互联网；
2、以前内部办公机器都是xp操作系统，现在新采购了一批vista操作系统新机器。

故障现象

1、 vista操作系统的办公机器在接入网络时，本地连接便显示网络连接正在识别，提示找不到网络；
2、 使用ifconfig/all命令查看vista系统的ip地址情况如下图所示： 

点击查看原图

       通过上图，我们发现：vista系统的首选地址变成了169.254.180.208，而不是先前收到设置的192.168.0.23了；
3、 用户反馈，如果vista系统的办公机器只接入交换机不会出现这种情况，但一旦接入防火墙，故障现象就会出现。
4、 XP系统的办公机器一切正常。

故障分析

1、 首先根据用户反馈的故障现象，从自己的经验出发，个人认为这个跟网络应该没有什么关系，估计是操作系统的问题，于是打microsoft OEM厂商的800电话咨询关于vista系统ip地址“突变”的原因，得到的回复是：从未出现过此类问题，可能跟现场环境有关。
2、 根据用户反馈的情况测试：首先，设好vista系统机器的ip地址后，将其接入一台普通的交换机，查看vista机器的ip地址，的确正常，如下图所示： 

点击查看原图

       难道真的跟防火墙有关？
3、 既然怀疑跟防火墙有关，我们便将注意力放到防火墙上来，telnet到防火墙上，使用使用tcpdump –i eth2 host 192.168.0.23 –n命令抓取测试vista主机的数据包。
4、 重启vista主机，发现vista主机在系统启动后，发送了一个源ip为0.0.0.0、目的ip为其配置的ip的arp请求包，同时，防火墙回应了该arp请求包，如下图所示： 

点击查看原图

5、防火墙为什么会回应该数据包？我们检查防火墙配置，发现防火墙上手动将内部办公网段设为静态arp代理。跟用户确认该问题，原来用户误认为该功能可能会解决arp欺骗问题，尝试设置后，忘记将其删除了。

故障解决

       删除防火墙上手动添加的arp代理项，故障现象消失，故障解决。

引申问题

1、通过抓取数据包，我们可以发现vista系统与xp系统在网卡引导阶段发送的“免费”arp报文格式的差别：
VISTA 系统发送的免费ARP请求包格式为：

点击查看原图

下图为wireshark抓取的vista系统网卡引导阶段发送的arp数据包格式：                      
 

点击查看原图

XP系统中发送的免费ARP请求包格式为：

点击查看原图

下图为xp系统发送的免费arp包格式： 

点击查看原图

       为什么VISTA系统在网卡地址加载期间发送这种格式的ARP数据包呢？关于这个问题已经有人做过相关的测试，我也验证了这个实验，下面为实验的过程，引用自netexpert的gwdwx：
“A机－B机两台xp对联测试：
1）按照xp的arp包格式（源ip＝目的ip＝a机ip），用sniffer伪造arp包向b机发包，b机不断提示ip冲突；
2）按照vista的arp包格式（源ip＝0.0.0.0），用sniffer伪造arp包向b机发包，b机不提示。
这就是最明显的区别，看来vista比xp还谦虚，它不仅让出ip，而且还不让对方发现有ip冲突，宁可牺牲自己”。

关于这个问题的详细讨论，可以参考如下链接：
http://www.netexpert.cn/viewthread.php?tid=19463&pid=125237&page=1&extra=page%3D1#pid125237

2、细心的兄弟应该会发现这样一个问题：既然是防火墙启用了针对内部办公网段的arp代理功能，使得vista在网卡加载地址期间发生了ip地址冲突，导致了vista系统机器无法访问互联网，那么，为什么xp系统在网卡加载地址期间没有出现地址冲突呢？
       实验证明：防火墙虽然启用了针对办公网段的arp代理功能，但是，防火墙只响应vista系统格式的arp请求报文，而不响应xp系统网卡加载地址时发送的免费arp报文。

阅读全文>>

标签: 疑难故障 ARP 防火墙 免费ARP ARP代理 VISTA

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

Powered by 易隐者 基于emlog 皖ICP备12002343号-1