TCP+IP网络故障诊断的结构化方法大全

TCP+IP网络故障诊断的结构化方法大全本文将描述一种对tcp/ip网络进行故障诊断的结构化方法。此篇能够作为引子，后面的文章我们将讨论本文所涉及到的一些关键问题。那么，在你听到“tcp/ip网络故障诊断”这个词的时候，你想到了什么?许多人可能会看到一张流程图。或者者说想到了操作步骤有几步的问题。还有许多人可能会感到茫然，无从下手。TCP/IP的故障诊断大概看起来简单，毕竟，这仅仅是一个拥有四层协议的体系结构，每一层有多种协议。只是，表面的简单并不意味着故障能够轻松解决。下面我们先看看：传统的故障诊断方法几年前，在笔者第一次学习tcp/ip的网络组建时，懂得了几个简单的故障诊断的流程，这个流程大体涉及到如下的几个方面：键入ipconfig，用以检查IP地址、子网掩码、默认网关是否正确。.运行Ping127.0.0.1,查看网络适配器是否正在工作。.运行Ping探测本机的IP地址是否正确或者合法。.试着Ping同一子网内的任何一台计算机的IP地址，看是否Ping通。.试着Ping一下默认网关（即路由器上将你的子网连接到网络其余部分的接口），看是否Ping通。.试着Ping不一致子网的一台计算机的IP地址.试着Ping外网的一台计算机的IP地址。笔者觉得这种方法有点儿僵化，由于我们几乎能够不用动脑子就能够遵循这些步骤。而且还有点儿效率低下，由于从其过程来看，它先假定你自己的计算机最可能有问题，而且问题极可能离你很近（你的网卡、计算机的IP地址配置、本地子网），然后才是远程计算机的问题。在互联网还没有真正快速进展之前，这个方法也许不错,也就是说，在DNS成为被广泛使用的域名解析系统之前，在防火墙与VPN等成为多数企业的网络部分之前，这个方案也许不错。笔者的意思是：假如你的一个用户说：“我现在不能连接到服务器上。”那么问题会出在哪里呢?我们有必要将用户的这句话分解为几部分，以便于进一步懂得问题。第一部分-“我不能…”：那么，我们应该问一下，是否只有一个用户报告网络问题呢?假如还有其他人，他们出现的问题类似吗?假如是这样的，那么问题很清除了，你不需要使用上述的僵化方法，直接开始对用户的计算机开始故障诊断即能够。否则，问题极有可能出现在其它地方，这可能意味着你的DNS服务器离线了或者你的DNS供应商服务出现了问题。或者者内部网络上的某个路由器出了问题，出现丢包现象。或者许你的用户正试图连接的服务器已经崩溃。或者许你应该停下来，想一想这些出现故障的用户可能存在的共同问题。比如，这些机器都位于相同的子网上吗?假如是这样的话，那么有可能那个子网的默认网关配置错误或者者路由器瘫痪。或者许是某个工作人员将连接子网的工作组交换机到骨干交换机的网络电缆切断了。或者许是某个恶意用户将一个欺诈性的DHCP服务器安装到那个子网上了，这个恶意用户正窃取机器的IP地址，而将一些不可路由的地址分配给那些计算机，从而形成拒绝服务的故障。当然，假如只是一个用户存在着这种问题，那么就需要我们问这样一些问题，如“计算机开机了吗?网络电缆安全地安装到了计算机的后部了吗?”“…连接到…”能够问这位用户这样一个问题“你所说的连接是什么意思?”这是由于“连接”是一个技术性很强的词语，许多用户事实上并不真正懂得所谈论的东西。为什么呢？由于存在着不一致种类的连接，包含MAC级的通信、TCP会话、口令验证、访问权限与特权、跨NAT的连接、防火墙的通过、应用层的会话等等。作为网管员需要明白用户的问题是什么。当这些用户说不能“连接到”服务器时，他们正在做什么？是在访问此服务器上的一个共享吗?在访问时是否收到了一个“拒绝访问”的消息呢?这些用户是否收到一个登录窗口，提示其输入有关凭证呢?（如账户名、口令等）服务器拒绝其凭证了吗?这些用户在找到或者使用活动目录中的共享时发生了问题了吗?他们发现问题的是一个映射驱动器吗?他们是不是正通过浏览网上邻居来查找服务器呢?等等。这些用户仅在连接某台服务器时才出现故障吗?或者者，这些用户是不是在连接到任何网络节点时都出现故障?在这里，决定问题或者故障的范围是很重要的：连接是一个方面或者多个方面呢?“…服务器…”你搞定了这个用户，而且搞定了那台服务器，也搞定了其间的网络。它们仍不能连接?为什么呢?需要注意的是那台服务器到底在什么地方呢?它在用户的子网上吗?在一个相邻的子网上吗?在一个不一致的部门上吗?在一个不一致的楼层上吗?在一个不一致的大楼上吗?是哪种网络将用户与特定的服务器连接起来?是无线以太网吗?是无线局域网吗?是互联网上的VPN通道吗?是拨号的modem连接吗?是线缆modem还是DSLmodem?首先决定用户与服务器之间的连接类型（有可能是几种），然后思考哪个地方有可能出现故障?有可能是CSU/DSU出了故障，能够试着给它重新加电或者与应该监视CSU/DSU的供应商联系。也有可能是某人在打扫卫生时碰到了电源开关，导致某个以太网交换机离线。假如你用的是可网管型交换机，也能够检查网络管理软件的警告信息。也有可能是远程服务器所在的办公室发生了电源中断。能够试着电话咨询一下。用户是仅与一台服务器无法连接，还是无法与多台服务器不能连接?其他人也不能连接到那些服务器上吗?在受影响的服务器之间有什么共同的东西吗?（问题有可能与用户的计算机有关，更有可能与网络架构自身有关）“…现在”时间因素在故障诊断中是至关重要的。应该问一下：问题是刚刚发生吗?上次成功连接到服务器是在什么时候?这种现象持续了多长时间?是连续性的还是间断的?断断续续的网络问题涉及到不可靠的WAN链接与其它一些难于解决的问题，特别是这些问题持续很短暂时间或者偶尔出现时更是这样。时间因素还有可能将问题与可能影响网络的其它情况联系起来。问题是出现在今天上午10点20分吗?彼时你的网络还出现了什么问题?WSUS服务器上打补丁了吗?域服务器上的预定保护实现了吗?结构化的方法笔者自己的TCP/IP网络的结构化故障诊断的方法由三个关键部分构成：决定问题的因素。也就是说要考虑如下方面：客户端：即出现问题的客户端服务器端：客户无法访问的服务器、打印机或者其它的网络资源（如互联网）其间的网络：线缆（假如不是无线的话）、集线器、交换机、路由器、防火墙、代理服务器，与客户端与服务器之间的其它网络架构。环境：可能会影响你的网络的外部情况，如电源的波动、建筑物的保护等等。范围：一个或者多个有关的客户端/服务器端。期间：连续的、间断的，还是偶尔的，何时开始等。出现问题的连接类型：物理层、网络层、传输层还是应用层?身份验证还是访问操纵?等等。标志性信息：客户端机器上的出错消息，登录对话框等等。在考虑到以上问题因素时，决定需要应用什么故障诊断措施，这些措施包含：验证有关客户端、服务器与网络架构硬件的物理媒体。也就是说检查电缆，确保网络适配器正确安装，并进一步查找、验证能够显示媒体断开状态的网络连接。验证有关客户端、服务器、网络架构硬件的TCP/IP配置。在客户端上这意味着检查IP地址、子网掩码、默认网关、DNS设置等等。关于网络架构硬件而言，也就是指路由器上的路由表与Internet网关。验证有关客户端与服务器端的路由选择的连通性。也就是说要使用ping,PathPing,tracert,或者其它类似的工具，便于在网络层上验证端到端的TCP/IP的连接性;使用数据包嗅探以监视传输层会话;使用nslookup,telnet与其它的工具来诊断包含域名解析问题、身份验证等应用层问题。3.懂得之、询问之、测试之:懂得协议如何工作，数据包如何由路由表转发，netdiag.exe等工具能够告诉你什么是非常关键的。成功的TCP/IP故障诊断是建立在懂得TCP/IP如何工作与有关测试工具的基础之上的。假如你从来没有努力懂得网络监视器的跟踪模式，那么你在诊断某些问题时就会遇到困难。问一些恰当的问题关于成功的故障诊断也很关键。要学会何时按部就班，何时以跳跃性思维直奔主题是故障诊断艺术的本质所在，这还括充分使用你的左右脑，即要有充分的想象与缜密的思维。最后，踏踏实实地测试，并隔离问题是很关键的，为此你需要故障诊断的工具箱。而且没有什么比丰富的经验更能帮助你解决复杂问题了。小结诊断TCP/IP网络的故障时可能会使人灰心丧气，只是也充满乐趣。在未来的文章中，我们将祥细阐述故障诊断的措施与工具，以帮助你成功地解决网络中出现的问题。懂得作为基础的网络技术与协议决定问题的不一致元素及其属性决定应该采取什么故障诊断措施与工具来解决问题笔者以为故障诊断问题不是简单的一、两步措施就能够解决的，换句话说，故障的解决更确切地讲是一种艺术（基于直觉）而非科学（基于某种方法）。TCP/IP网络的基础是路由表，这是一种TCP/IP网络上每台主机的数据结构。路由表有下列三个作用：用于存储网络上其它子网的信息，与如何到达这些网络上的主机。为了达到此数据包的最终目的地，路由表能够决定每个数据包如何被转发到某台主机。用于决定哪个网络接口（称之下一跳接口）应该用于转发这个数据包，从而使其到达目的地。能够说，假如你想高效地诊断TCP/IP网络上的路由问题，懂得路由表是很关键的。现在让我们看看路由表是如何工作的，在不一致的情况下路由表的表现是如何的，同时看看在不一致的情况下需要使用什么故障诊断的措施与工具。我们将从检查一个简单的服务器（只有一个网络接口的服务器）的路由表开始，此服务器只分配了一个IP地址。笔者选择这个例子是由于它最易懂得，在笔者的下一篇文章中，我们将看一些更为复杂的例子，包含拥有多个IP地址的服务器（如Web服务器）与拥有多个网络接口的服务器（如既能连接到LAN又能连接到一个用于备份的单独的网络）。只拥有一个IP地址的简单服务器的路由表下面的路由表是在172.16.11.0/24网络上IP地址为172.16.11.30的服务器的路由表:下列是引用片段:IPv4RouteTableInterfaceList

0x1 MS TCPLoopbackinterface0x10003...0003ff25888c......Intel21140-BasedPCIFastEthernetAdapter

(Generic)ActiveRoutes:NetworkDestinationNetmaskGatewayInterfaceMetric

0.0.0.00.0.0.0172.16.11.1172.16.11.3020

127.0.0.0255.0.0.0127.0.0.1127.0.0.11

172.16.11.0255.255.255.0172.16.11.30172.16.11.3020

172.16.11.30255.255.255.255127.0.0.1127.0.0.120

172.16.255.255255.255.255.255172.16.11.30172.16.11.3020

224.0.0.0240.0.0.0172.16.11.30172.16.11.3020

255.255.255.255255.255.255.255172.16.11.30172.16.11.301DefaultGateway:172.16.11.1PersistentRoutes:None为了显示这个路由表，你需要打开一个命令提示窗口，在其中输入routePrint。下面我们对其各个部分逐个分析便于我们懂得它是如何工作的：路由表中每一个路由表项(或者路由)都由五个字段构成：网络目标地址(NetWOrkDeStination)：代表某个可能的目的地址，它是一个IP地址或者子网，即表示IP数据包被转发到何处的地址。掩码(NetmaSk):一个用于将某数据包中的IP地址中的目标地址字段与上面可能的网络地址匹配起来的位模式。网关(GateWay):下一跳的IP地址，数据包务必被转发到此，才能到达特定的目的网络。接口(Interface)：下一跳的接口，这个接口务必用于将数据包进行转发，以达到特定的目的网络。跳数(metric):表示到达目的的过程中通过了多少跳数(路由器数)，即路由的成本。示例一：目标主机在本地子网上关于我们例子而言，假设这个特定的服务器(172.16.11.30)要将数据包发往同一子网内的另一台主机(IP地址为172.16.11.80)。那么这个数据包的源地址为172.16.11.30，目标地址为172.16.11.80。下面我们将展示Windows是如何用其路由表来决定选择使用哪条路由的：Windows首先依次从路由表中取出每一个路由，并将数据包的目标地址(172.16.11.80)与选中路由的掩码执行逻辑“与”运算。下面展示结果，这里，路由表中的每一个路由是通过其网络目的地址确定的：Route<?<?<?<?<?<?<?<?<?<?<?<?<?<<Netmask172.16.11.80ANDNetmask<?<?<?<?<?<?<?<?<?<?<?<?<?<?<?0.0.0.0I0.0.0.00.0.0.0127.0.0.0255.0.0.0172.0.0.0172.16.11.0255.255.255172.16.11.0.0172.16.11.30 255.255.255 172.16.11.8.255 0172.16.255.255 255.255.255 172.16.11.8.255 0224.0.0.0 224.0.0.0 160.0.0.0255.255.255.255 255.255.255 172.16.11.8.255 0对每一个路由来说，这个“与”运算的结果要与路由的网络目标地址比比较，而二者的一次匹配意思着这条路由可被用于将数据包转发到其目标地址。假如发现不只有一个匹配，Windows就会选用拥有最长匹配的路由（即1的位数最高的路由）。假如这并不有产生唯一的路由，Windows就任意地选用一个作为路由。从上面的列表中，这个“与”运算的结果导致了两个匹配（路由1与3），因此Windows选择了拥有最长匹配的路由，即第三行的那个。其结果是Windows明白了使用哪个路由将数据包传送到目的地。下面是这条路由在服务器的路由表中看起来的样子：NetworkDestinationNetmaskGatewayInterfaceMetric172.16.11.0 255.255.255.0172.16.11.30 172.16.11.3020Windows现在要使用下面的算法来决定下一步做什么：a）假如路由的网关字段与服务器上的一个网络接口的地址相匹配（或者者假如网关是空的话），那么Windows就会用在路由中指定的接口将数据包直接发送到目标地址。b)假如路由的网关字段并不与服务器上网络接口的任意地址相匹配，Windows将会把数据包转发给路由中的网关字段的地址。很明显，这里符合条件a,路由的网关字段(172.16.11.30)即为分配给服务器单个网卡的地址。Windows因此会作出决定认为目标地址位于本地子网上，这也就是说Windows不需要将数据包发送到任何路由器，而是直接发送给其目的地址。在此例中，Windows使用服务器的172.16.11.30的网络接口,简单地将数据包发送给172.16.11.80,接收主机得到了数据包。示例二：目标主机在远程子网上现在,让我们继续同样的过程,只是这次我们假定服务器想把数据包发往一个不一致子网上的一台主机(IP地址为172.16.10.200)。换句话说，数据包的源地址为172.16.11.30,目标地址为172.16.10.200。下面我们看一下Windows是如何利用路由表决定选择哪条路由的：Windows从路由表中取出每一条路由，将数据包的目标地址(172.16.10.200)与路由中的掩码进行“与”运算。运算结果如下：RouteNetmask172.16.10.200ANDNetmask0.0.0.00.0.0.00.0.0.0127.0.0.0255.0.0.0172.0.0.0172.16.11.0255.255.255.0172.16.10.0172.16.11.30255.255.255.255172.16.10.200172.16.255.255255.255.255.255172.16.10.200224.0.0.0224.0.0.0160.0.0.0255.255.255.255255.255.255.255172.16.10.200关于每一条路由来说，“与”运算的结果要与路由中网络目标地址相比较，二者匹配意味着这条路由可被用于将数据包转发到其目标地址。从我们上面的第二张路由表，你能够看出这次只有一个匹配，也就是说是第一行，这个路由的网络目地字段(0.0.0.0)与“与”运算的结果匹配。因此Windows用来将数据包转发到其目标地址的路由即为下面的路由：NetworkDestinationNetmaskGatewayInterfaceMetric0.0.0.00.0.0.0 172.16.11.1172.16.11.30203.然后Windows就会使用前述的算法来决定下一步做什么，这次符合条件b，由于路由的网关字段(172.16.11.1)与分配给服务器的单独网卡的地址(172.16.11.30)并不匹配。Windows因此会决定目标地址位于一个远程子网上，将数据包转发给路由器，路由器通过继续转发数据包将其传送到目的地。在此例中，Windows使用服务器的172.16.11.30网络接口，将数据包发送到在网关字段中所显示的地址。一旦位于172.16.11.1的路由器收到了数据包，它会决定下一步需要采取什么步骤，才能将数据包转发到其最后的目标地址172.16.10.200，而这又依靠于172.16.11.10/24网络是172.16.11.11/24(由单个路由器连接)或者一个远程网络的邻近子网(由几个中间网络之间的路由器连接)。故障诊断小技巧在上述的过程中哪里会出问题呢?首先，Windows有可能无法选择一条网络目的地址字段与“与”运算的结果（即路由的掩码字段与数据包的目标字段“与”运算的结果）相匹配的路由。假如发生这种情况，你就会收到一个路由选择错误，这通常会通过一些运行在服务器上的网络应用程序指示给你。通常情况下，Windows会使用TCP来通知网络堆栈的上层，说明数据包不能送达，就会导致某种错误消息。在这种情况下，你的路由表可能已经损坏，或者者说，你的路由表中有一个非法的持久性路由。持久性路由指的是你通过使用route-Padd手动命令添加到路由表中的路由，这种路由需要重启才能够使用，由于其值是存储在注册表中的。假如你添加了非法的路由，就会产生惊奇的结果。（尽管这种非法路由多数情况下会导致数据通信被莫名其妙地丢弃。）另外一方面，假如目标主机位于一个远程子网上，Windows会将数据包转发给一个路由器（默认的网关地址），而这个路由器又不能选择一个路由，那么这种情况就会发生：路由会将把一个ICMP（网际操纵报文协议）消息：“目标不可达到（DeStinationUnreaChable）-主机不可到达（HoStUnreaChable）”返回给发送此数据包的主机。止匕例中，TCP会通知上层协议，然后就会显示某种错误消息。不管何种情况，一个处理问题的有用方法是在发送方主机上检查路由表，还要检查数据包在到达目的地的过程中沿途通过的路径所连接的路由器，查看这些路由表是否一致或者已经损坏。一个损坏的路由表能够通过重置TCP/IP堆栈进行恢复（至少在Windows计算机上是这样），具体方法是使用netshintipreset命令，大家能够参考微软的KB299357查找祥细资料。只是，需要注意，这种重置操作并不可能清除你手动添加到路由表中的路由。结论我们讨论了路由表是如何工作的，同时阐述了如何诊断路由表的故障，下一篇文章我们将讨论几个更为复杂的例子，比如看看拥有多个地址与多个网卡的服务器的情况。这是网络故障诊断结构化方法的第三篇，本文谈的是如何利用Windows平台的网络连接修复特性。成功的故障诊断依靠于三个重要支柱：缜密的逻辑思维、对技术与技巧的懂得、诊断工具的使用经验。我们的文章要紧以这三个支柱为基础。比如，在笔者的首篇文章中，我们概要地描述了一种结构化的方法，展示如何从逻辑上诊断Windows系统网络的TCP/IP网络故障。在第二篇文章中，我们重点从技术上讨论了路由表是如何工作的，并讨论了路由表问题的故障诊断技巧。今天的这篇文章中，我们将懂得Windows的网络修复特性如何修复常见的网络连接问题。后面我们还有文章讨论上述的三大支柱，以帮助读者成为更为专业的故障诊断高手。修复特性是一个强有力的工具，尽管大家很少用它（你用得很多吗?），由于许多人没有真正地懂得它。使用这个特性是相当简单的，只需要在网络连接上右击，从弹出的快捷菜单中选择“修复”即可。如图：禁用⑪状奇③）打开网络连接在我们这样操作时，就会弹出一个对话框，连续地显示一系列的消息,这些消息表现了修复活动的工作过程。如图：在上面的图中，我们看到的正在进行的修复操作是“清除DNS缓存”，这仅是一个修复操作而已。背后，Windows执行的是一些命令行操作，图中的每一个过程的消息（如“清除DNS缓存”）都指明了其中的一个命令被执行了。那么，在我们使用“修复”功能时，到底系统运行了什么命令，执行了什么操作呢?这些命令做了什么？它们对系统产生了如何的影响?为什么要执行这些操作或者命令?下面我们一一道来:第一步：DHCP更新(DHCPRenew)假如你配置了网络连接使其能够通过DHCP自动地接收IP地址，就会需要这一步。假如你手动配置了连接，使用的是静态的IP地址与其它的TCP/IP配置，就不需要这一步了。此处执行的这个命令行操作类似于但不一致于下面的命令：下列是引用片段：ipconfig/renew这个命令会试图与DHCP服务器(计算机先前的IP地址就是从此租用的)联系。假如能够联系到DHCP服务器，计算机就会确认其目前的TCP/IP配置是合法的。只是，在这个命令通过“修复”功能执行时，与通过命令行方式启动它的行为是不一样的。如今，并不是向获取其IP地址与有关DHCP配置的服务器发送一个单播的DHCP更新消息，而是向网络中的任何可用的DHCP服务器发送一个DHCP更新消息的广播包。如此做的原因在于，假如计算机目前的TCP/IP配置是非法的，计算机就能够通过要求一个新的地址租用，从任何可用的DHCP服务器那儿获取新的TCP/IP配置。执行“修复”网络连接这个操作有两个方面的影响：一是解决客户端上的DHCP配置问题，二是在无需与一个特定的DHCP服务器联系的情况下解决问题。小提示：通过实施网络上的DHCP服务器的冗余机制，来防止由于DHCP服务器不可用所造成的网络问题。现在网上有很多这样的文章，读者可自己用google等搜寻。第二步：清空ARP缓存这一步执行的命令行操作如下所示：下列是引用片段：

arp-d*这个命令清空本地计算机上地址解析协议（ARP）缓存中的内容。ARP是一个用于将IP地址解析为MAC地址（固化到局域网网卡内）的协议。ARP缓存包含着最近一段时间以来解析的网络节点的MAC地址。这些MAC地址被储存到计算机的缓存中，目的是与这些节点（IP地址）的通信无需重复解析就能够实现。假如ARP缓存中的一个或者多个项目不正确，那么与某些IP地址的网络通信就会失败。假如某个不正确的缓存项目属于本地子网的一个点，那么与那个节点的通信就会失败。假如默认网关的缓存项目不正确，那么与远程子网节点的通信就会失败。这种类型的网络通信失败（不管是位于本地子网还是远程子网）都能够指明哪一个ARP缓存项目是不正确的（假设不正确的ARP缓存项目是问题所在）。第三步：清空NetBIOS缓存这一步执行的命令行操作如下所示：下列是引用片段：nbtstat-R这个命令会清空本地计算机上的NetBIOS缓存内容。运行这个命令还会将LMHOSTS文件中的任何项目预先装载到缓存中。在多数基于Windows的网络中，包含那些部署了活动目录与DNS域名解析的网络，老的NetBIOS名字解析仍可用于某些功能。由于可通过查询一个WINS服务器或者通过运用NetBIOS广播将远程主机的NetBIOS名字解析为其有关的IP地址，这些主机到IP地址的映射就被添加到本地计算机的NetBIOS缓存中，从而与远程主机的通信在无需反复多次解析的情况下就能够实现。假如NetBIOS缓存中的一个或者多个项目不正确，与网络中的某些IP主机的通信就会失败。假如本地子网主机的缓存项目不正确，那么与此主机的通信就失败。假如默认网关的缓存项目不正确，那么远程子网上的主机通信就会失败。这种网络通信失败（不管主机是在本地子网或者远程子网上）能够指明NetBIOS缓存中的哪个项目不正确（假设不正确的NetBIOS缓存项目是问题所在）。不正确的NetBIOS缓存项目有的时候是由WINS服务器上WINS数据库中的过时项目引起的。这是由于在实施WINS后，WINS要优先于NetBIOS广播的名字解析，因此损坏的或者过时的WINS项目就会用不正确的项目重新注入NetBIOS缓存，即使在缓存被清空以后也是如此。这种情况的解决方案是要在WINS数据库中永久性地标记不正确的记录，再次清空NetBIOS缓存内容，然后用nbtstat-c命令监视缓存，用以确保这些不正确的项目不可能再被加裁到缓存中。第四步：清空DNS解析程序缓存这一步执行