TCP/IP网络故障诊断的结构化方法(一)

    本文将描述一种对TCP/IP网络进行故障诊断的结构化方法。此篇可以作为引子，后面的文章我们将讨论本文所涉及到的一些关键问题?

    那么，在你听到“TCP/IP网络故障诊断”这个词的时候，你想到了什么?许多人可能会看到一张流程图。或者说想到了操作步骤有几步的问题。还有许多人可能会感到茫然，无从下手。

　　TCP/IP的故障诊断似乎看起来简单，毕竟，这仅仅是一个拥有四层协议的体系结构，每一层有多种协议。不过，表面的简单并不意味着故障能够轻松解决。下面我们先看看：

　　传统的故障诊断方法

　　几年前，在笔者第一次学习TCP/IP的网络组建时，理解了几个简单的故障诊断的流程，这个流程大体涉及到如下的几个方面：

　　键入ipconfig，用以检查IP地址、子网掩码、默认网关是否正确。

　　1. 运行ping 127.0.0.1,查看网络适配器是否正在工作。

　　2. 运行ping 探测本机的IP地址是否正确或合法。

　　3. 试着ping同一子网内的任何一台计算机的IP地址，看是否ping通。

　　4. 试着ping一下默认网关(即路由器上将你的子网连接到网络其余部分的接口)，看是否ping通。

　　5. 试着ping不同子网的一台计算机的IP地址

　　6. 试着ping外网的一台计算机的IP地址。

　　笔者觉得这种方法有点儿僵化，因为我们几乎可以不用动脑子就可以遵循这些步骤。而且还有点儿效率低下，因为从其过程来看，它先假定你自己的计算机最可能有问题，而且问题极可能离你很近(你的网卡、计算机的IP地址配置、本地子网)，然后才是远程计算机的问题。在互联网还没有真正快速发展之前，这个方法也许不错,也就是说，在DNS成为被广泛采用的域名解析系统之前，在防火墙和VPN等成为多数企业的网络部分之前，这个方案也许不错。

　　笔者的意思是：如果你的一个用户说：“我现在不能连接到服务器上。”那么问题会出在哪里呢?我们有必要将用户的这句话分解为几部分，以便于进一步理解问题。

　　第一部分-“我不能…”：

　　那么，我们应该问一下，是否只有一个用户报告网络问题呢?如果还有其他人，他们出现的问题类似吗?如果是这样的，那么问题很清除了，你不需要采用上述的僵化方法，直接开始对用户的计算机开始故障诊断即可以。否则，问题极有可能出现在其它地方，这可能意味着你的DNS服务器离线了或你的DNS供应商服务出现了问题。或者内部网络上的某个路由器出了问题，出现丢包现象。或许你的用户正试图连接的服务器已经崩溃。

　　或许你应该停下来，想一想这些出现故障的用户可能存在的共同问题。例如，这些机器都位于相同的子网上吗?如果是这样的话，那么有可能那个子网的默认网关配置错误或者路由器瘫痪。或许是某个工作人员将连接子网的工作组交换机到骨干交换机的网络电缆切断了。或许是某个恶意用户将一个欺诈性的DHCP服务器安装到那个子网上了，这个恶意用户正窃取机器的IP地址，而将一些不可路由的地址分配给那些计算机，从而形成拒绝服务的故障。

　　当然，如果只是一个用户存在着这种问题，那么就需要我们问这样一些问题，如“计算机开机了吗?网络电缆安全地安装到了计算机的后部了吗?”

　　“…连接到…”

　　可以问这位用户这样一个问题“你所说的连接是什么意思?”这是因为“连接”是一个技术性很强的词语，许多用户其实并不真正理解所谈论的东西。为什么呢?因为存在着不同种类的连接，包括MAC级的通信、TCP会话、口令验证、访问权限和特权、跨NAT的连接、防火墙的通过、应用层的会话等等。作为网管员需要知道用户的问题是什么。当这些用户说不能“连接到”服务器时，他们正在做什么?是在访问此服务器上的一个共享吗?在访问时是否收到了一个“拒绝访问”的消息呢?这些用户是否收到一个登录窗口，提示其输入相关凭证呢?(如账户名、口令等)服务器拒绝其凭证了吗?这些用户在找到或使用活动目录中的共享时发生了问题了吗?他们发现问题的是一个映射驱动器吗?他们是不是正通过浏览网上邻居来查找服务器呢?等等。

　　这些用户仅在连接某台服务器时才出现故障吗?或者，这些用户是不是在连接到任何网络节点时都出现故障?在这里，决定问题或故障的范围是很重要的：连接是一个方面或多个方面呢?

    “…服务器…”

　　你搞定了这个用户，而且搞定了那台服务器，也搞定了其间的网络。它们仍不能连接?为什么呢?需要注意的是那台服务器到底在什么地方呢?它在用户的子网上吗?在一个相邻的子网上吗?在一个不同的部门上吗?在一个不同的楼层上吗?在一个不同的大楼上吗?是哪种网络将用户与特定的服务器连接起来?是无线以太网吗?是无线局域网吗?是互联网上的VPN通道吗?是拨号的modem连接吗?是线缆modem还是DSL modem?首先决定用户和服务器之间的连接类型(有可能是几种)，然后思考哪个地方有可能出现故障?有可能是CSU/DSU出了故障，可以试着给它重新加电或与应该监视CSU/DSU的供应商联系。也有可能是某人在打扫卫生时碰到了电源开关，导致某个以太网交换机离线。如果你用的是可网管型交换机，也可以检查网络管理软件的警告信息。也有可能是远程服务器所在的办公室发生了电源中断。可以试着电话咨询一下。

　　用户是仅与一台服务器无法连接，还是无法与多台服务器不能连接?其他人也不能连接到那些服务器上吗?在受影响的服务器之间有什么共同的东西吗?(问题有可能与用户的计算机有关，更有可能与网络架构自身有关)

　　“…现在”

　　时间因素在故障诊断中是至关重要的。应该问一下：问题是刚刚发生吗?上次成功连接到服务器是在什么时候?这种现象持续了多长时间?是连续性的还是间断的?断断续续的网络问题涉及到不可靠的WAN链接以及其它一些难于解决的问题，特别是这些问题持续很短暂时间或偶尔出现时更是这样。

　　时间因素还有可能将问题与可能影响网络的其它情况联系起来。问题是出现在今天上午10点20分吗?彼时你的网络还出现了哪些问题?WSUS服务器上打补丁了吗?域服务器上的预定维护实现了吗?

　　结构化的方法

　　笔者自己的TCP/IP网络的结构化故障诊断的方法由三个关键部分组成：

　　1. 决定问题的因素。也就是说要考虑如下方面：

　　客户端：即出现问题的客户端
　　
    服务器端：客户无法访问的服务器、打印机或其它的网络资源(如互联网)等。
　　
    其间的网络：线缆(如果不是无线的话)、集线器、交换机、路由器、防火墙、代理服务器，以及客户端和服务器之间的其它网络架构。
　　
    环境：可能会影响你的网络的外部情况，如电源的波动、建筑物的维护等等。
　　
    范围：一个或多个有关的客户端/服务器端。
　　
    期间：连续的、间断的，还是偶尔的，何时开始等。
　　
    出现问题的连接类型：物理层、网络层、传输层还是应用层?身份验证还是访问控制?等等。
　　
    标志性信息：客户端机器上的出错消息，登录对话框等等。
　　
    2. 在考虑到以上问题因素时，决定需要应用哪些故障诊断措施，这些措施包括：

　　验证有关客户端、服务器和网络架构硬件的物理媒体。也就是说检查电缆，确保网络适配器正确安装，并进一步查找、验证可以显示媒体断开状态的网络连接。

　　验证有关客户端、服务器、网络架构硬件的TCP/IP配置。在客户端上这意味着检查IP地址、子网掩码、默认网关、DNS设置等等。对于网络架构硬件而言，也就是指路由器上的路由表和Internet网关。

　　验证有关客户端和服务器端的路由选择的连通性。也就是说要使用ping，pathping，tracert，或其它类似的工具，便于在网络层上验证端到端的TCP/IP的连接性;采用数据包嗅探以监视传输层会话;使用nslookup，telnet和其它的工具来诊断包括域名解析问题、身份验证等应用层问题。

　　3.理解之、询问之、测试之:

　　理解协议如何工作，数据包如何由路由表转发，netdiag.exe等工具能够告诉你什么是非常关键的。成功的TCP/IP故障诊断是建立在理解TCP/IP如何工作和有关测试工具的基础之上的。如果你从来没有努力理解网络监视器的跟踪模式，那么你在诊断某些问题时就会遇到困难。

　　问一些恰当的问题对于成功的故障诊断也很关键。要学会何时按部就班，何时以跳跃性思维直奔主题是故障诊断艺术的本质所在，这还括充分使用你的左右脑，即要有充分的想象和缜密的思维。

　　最后，踏踏实实地测试，并隔离问题是很关键的，为此你需要故障诊断的工具箱。而且没有什么比丰富的经验更能帮助你解决复杂问题了。

　　小结

　　诊断TCP/IP网络的故障时可能会使人灰心丧气，不过也充满乐趣。在未来的文章中，我们将祥细阐述故障诊断的措施和工具，以帮助你成功地解决网络中出现的问题。