某怪异网络故障现象解决案例

孤独的意尹者 · 发表于 2006-12-25 08:40:36

某怪异网络现象解决一例
一、网络环境：
见附件一。

环境说明：
1、县局内网全部为143.76.14X..0/24网段，网关全部指向143.76.14X..250（防火墙内网接口地址）；
2、防火墙工作在混合模式下，县局内网—》INTERNET走NAT的路由模式，县局内网—》税务专网走桥接（交换）模式；
3、防火墙路由表： 143.0.0.0 255.0.0.0 143.76.14X.254
0.0.0.0 0.0.0.0 61.X.X.X
4、县局核心交换机只启用了2层交换功能；

二、故障现象：
1、县局内网用户无法访问市局的服务器（我们测试时用市局某FTP服务器143.76.3X..2/24），但却可以访问省局服务器（我们测试时用省局某WEB服务器143.16.X..1/24）；
2、县局内网用户把网关改为直接指向专网路由器内部接口地址143.76.14X.254，则市局服务器、省局服务器访问都正常；
三、分析和解决过程：
1、首先为验证用户所说故障现象，我们针对市局、省局的服务器做了测试，确实存在如上所述故障；
2、登陆防火墙查看配置，确认防火墙访问控制策略、路由等配置无误；
3、没有明显的配置问题，那么为什么市局的服务器在县局都无法访问呢？
为确认此问题，当县局内网机器访问市局FTP服务器时，我们就telnet到防火墙上抓一下这些数据包，看看这些数据包通过防火墙到底是怎么走的。
（1），在防火墙内网口使用命令：tcpdump –i eth2 host 143.76.3X.2；
（2），在防火墙专网出口使用命令：tcpdump –i eth0 host 143.76.3X.2；
备注：由于是使用用户处的机器抓包的，所以没有留下抓包内容
我们发现，县局内网发往市局FTP服务器的SYN请求包发送到了防火墙内网接口ETH2上，但是在防火墙专网出口ETH0上却没有发现这些SYN请求包，而是由防火墙内网接口地址143.76.14X.250发送的关于143.76.3X.2的ARP请求包；
（3），正常情况下，防火墙应该根据自己的路由表将这些SYN请求包转发给专网路由器才对，为什么防火墙没有转发该包，而是自己直接发送143.76.3X.2的ARP请求包呢？难道防火墙认为143.76.3X.2跟自己是在同一网段的？
4、为验证上面的推论，我们登上防火墙查看其内网接口地址，发现内网接口分配的地址为：143.76.14X.250/255.255.0.0，靠！16位的掩码！难怪防火墙会认为143.76.3X.2是自己直连的网段；
5、接下来的事情就简单了，修改防火墙内网接口地址的掩码为255.255.255.0，保存，测试，一切正常了！
四、结论：
1、怪异现象的背后总是有原因的，当我们尝试着去分析和解决这类怪异问题时，需要有扎实的理论基础，在该例中，就需要对数据包的转发流程以及各种常用通讯协议（ARP）比较熟悉；
2、掌握几种经典工具的使用方法，对我们解决故障将有莫大的帮助（此例中tcpdump的使用）；
3，此例的怪异程度只是一般，遇到怪异程度高的故障，如果我们解决不了，最好能够取得相关设备的厂家的技术支持，因为：首先，不同的网络设备处理数据包的流程是不一样的，有些厂商的设备在数据包的处理上并不符合我们所熟悉的正常的流程（他们很可能不按照套路出牌，呵呵！），例如天融信防火墙NGFW4000的2.6.40的版本，当防火墙工作在桥接模式下时，则默认限制ARP数据包穿透防火墙；其次，任何设备都有存在BUG的可能，以前在用户处就遇到过FORTINET防火墙的BUG问题；

BTW:效率！？
坐车来回需要5小时，等用户花了2小时，解决问题花了5分钟，此次解决问题的效率为：
5/[(5+2)*60+5]＝0.011764705882352941176470588235294

[ 本帖最后由孤独的意尹者于 2006-12-25 09:00 编辑 ]

孤独的意尹者 · 发表于 2006-12-25 08:58:42

随帖附上
1，Fishyxq的《掩码配置错误时ping测试结果分析》方便大家学习掩码配置错误时出现的各种情况；
2，记得在坛子里见过tcpdump使用的资料，但是为了方便大家下载，我就将tcpdump的使用语法一并附在此；
tcpdump为linux下的抓包工具，一些厂家在其设备上集成了tcpdump功能，例如：天融信防火墙、F5负载均衡等,其他厂家不明，有清楚的兄弟请在下面跟帖说明，
方便大家在以后遇到这些设备时使用该功能，谢谢。
CISCO、华为等设备带有debug命令也可以查看数据流，但是其主要是以记录日志的方式，没有tcpdump直观、实时、可过滤。。。。。

[ 本帖最后由孤独的意尹者于 2006-12-25 09:00 编辑 ]

lingyungong79 · 发表于 2006-12-25 11:21:27

牛人啊！！收不收小弟？

菜鸟人飞 · 发表于 2006-12-25 11:59:20

非常不错的分析案例，楼主的分析思路清晰，所以才能在如此短的时间内解决问题，佩服。
鼓励原创，加为精华！

libin125_0 · 发表于 2006-12-25 12:11:07

佩服佩服,看似简单的问题,没有坚实的基本功底是很难找到的。能见到255.255.0.0的掩码也够人郁闷的了，呵呵。
谢谢分享经验~~~

rixtdm · 发表于 2006-12-25 13:11:35

tcpdump是个判断网络问题的好东西。另外LZ算工作效率的算法比较搞笑，呵呵！

san980 · 发表于 2006-12-25 13:55:40

厉害呀，怎样学习才能到达楼主的那种水平哟？

tomchen1977 · 发表于 2006-12-30 22:11:26

不错不错，学习学习，呵呵

sivalei · 发表于 2006-12-30 23:26:29

效率=价值/时间

lz 思路清晰还是不错滴~

viviviva · 发表于 2006-12-31 10:03:45

掩码设置不当,导致报文转发不可达!

fs999 · 发表于 2007-1-7 15:44:34

做IT的，很难计算效率的

exp. · 发表于 2007-1-10 10:51:57

学习中~~~

zzxzyp · 发表于 2007-1-11 09:22:44

分析的很到为
有知识

艾一客崖 · 发表于 2007-1-23 06:36:23

咳。要是我碰到这种问题,肯定先找三层的问题。三层通了，再查高层。三层不通,开始查三层以下的底层。

这种问题,可以trace 一下啊。

harker · 发表于 2007-1-23 17:59:06

佩服，学习，理解中，顶！！！

红盟过客 · 发表于 2007-1-24 16:52:14

非常不错的分析案例，楼主的分析思路清晰，所以才能在如此短的时间内解决问题，佩服。
鼓励原创，加为精华

skyer_upc · 发表于 2007-3-21 17:17:26

分析透彻！学习一下。。

l71952006 · 发表于 2007-4-2 20:59:35

顶...
初来乍到　多多指教～．～！！！

golddragon · 发表于 2007-4-3 16:03:06

真是强人啊。不得不佩服。

jianci · 发表于 2007-4-4 10:55:29

谢谢楼主的经验哦~非常感谢哦~

xiao805csna · 发表于 2007-4-11 09:54:13

菜鸟来顶顶你菜鸟来顶顶你菜鸟来顶顶你菜鸟来顶顶你

gtl · 发表于 2007-4-11 12:44:40

强人啊

tyh2000 · 发表于 2007-4-11 15:16:19

不错不错，值得学习，提倡楼主共享精神。

hopehands · 发表于 2007-4-16 17:20:43

不错。。。很有启发～～

w3924686 · 发表于 2007-6-18 22:00:13

楼主，真功夫啊

kernel32 · 发表于 2007-6-19 08:34:08

基础知识真的很重要啊。

suzhe · 发表于 2007-6-19 11:42:16

不错不错,真的很佩服

秋水寒 · 发表于 2007-6-19 15:45:57

有时候掩码设错了，烦人啊，顶一下了。

designtide · 发表于 2007-6-19 16:26:11

好的，绝对支持下………………

lcylcyll · 发表于 2007-6-23 08:47:11

只能明白一点点啊！！

某怪异网络故障现象解决案例

本帖子中包含更多资源

本帖子中包含更多资源

菜鸟来顶顶你

回复 #1 孤独的意尹者的帖子

某怪异网络故障现象解决案例

本帖子中包含更多资源

本帖子中包含更多资源

菜鸟来顶顶你

回复 #1 孤独的意尹者 的帖子

回复 #1 孤独的意尹者的帖子