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的连接、防火墙的通过、应用层的会话等等。作为网管员需要知道用户的问题是什么。当这些用户说不能“连接到”服务器时，他们正在做什么?是在访问此服务器上的一个共享吗?在访问时是否收到了一个“拒绝访问”的消息呢?这些用户是否收到一个登录窗口，提示其输入相关凭证呢?(如账户名、口令等)服务器拒绝其凭证了吗?这些用户在找到或使用活动目录中的共享时发生了问题了吗?他们发现问题的是一个映射驱动器吗?他们是不是正通过浏览网上邻居来查找服务器呢?等等。

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