1、Linux服务器故障排查实用指南由于造成网络问题的因素多种多样，因此网络故障排查技能就成了每位服务器或网络服务负责人必不可少的重要素质。Linux为我们提供了大量网络故障排查工具，在本文中，我们将讨论一些常见的网络问题，并介绍如何利用某些Linux工具追踪意外状况发生的根本原因。问题：服务器A无法与服务器B通信可能大家在实际工作中最常见的网络故障就是一台服务器无法与另一台网络上的服务器进行通信。本小节将通过实例讲解具体处理办法。在实例中，一台名为dev1的服务器无法访问另一台名为web1的服务器中的网络服务（端口80）。导致这一现象的原因相当繁杂，因此我们需要一步步测试操作活动，进而通过排除法
2、找到故障的根源。一般说来，在对这样的问题进行故障排查时，大家可能会跳过某些初始步骤（例如检查链接等），因为接下来的某些测试环节能起到同样的诊断作用。举例来说，如果我们测试并确认DNS能够正常工作，那么就证明我们的主机是能够与本地网络进行通信的。但在本次实例解析中，我们将本着谨慎的态度执行每一个步骤，借以理解各个级别的不同测试方式。 问题出在客户机还是服务器端？大家可以利用一项快速测试缩小造成故障的范围，即通过同一网络中的另一台主机尝试访问对应服务器。在本实例中，我们姑且将另一台与dev1同处一套网络环境下的服务器命名为dev2，并尝试通过它访问web1。如果dev2也不能正常访问web1，那么
3、显然问题很可能出在web1或者是dev1、dev2及web1之间的网络身上。如果dev2能够正常访问web1，那么我们就可以断定dev1出问题的机率较大。首先，我们假设dev2能够访问web1，因此我们开始将故障排查的重点放在dev1这边。 线缆插好了吗？故障排查的第一步要在客户机上进行。大家首先要确认自己客户机的网络连接没有问题。要做到这一点，我们可以使用ethtool程序（通过ethtool工具包安装）对链接（即以太网设备与网络构成物理连接）情况加以检测。如果大家无法确定自己使用的是哪个端口，那么请运行/sbin/ifconfig命令将所有可用的网络端口及其设定列出。我们假设自己的以太网设
4、备在eth0端口上，那么：代码： $ sudo ethtool eth0Settings for eth0: Supported ports: TP Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/H
5、alf 1000baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: pg Wake-on: d Current message level: 0x000000ff (255) Link detected: yes在最后一行中，大家可以看到检测结果显示链接设置为“yes”，所以dev1已经与网络构成物理连接。如果这项检测的结果为“
6、no”，那么我们需要亲自检查dev1的网络连接，并将线缆插实到位。在确定物理连接没有问题之后，执行下面的步骤。注意：ethtool绝不仅仅是一款用于检测链接状况的工具，它还能够诊断并纠正双工问题。当Linux服务器与网络连通时，通常会与网络自动协商以获取传输速度信息以及该网络是否支持全双工。在本实例中，传输速度经ethtool检测为100Mb/秒，且该网络支持全双工机制。如果大家发现主机的网络传输速度缓慢，那么速度及双工设定是首先需要关注的重点。如前文所示运行ethtool，若大家发现双工被设定为一半，则运行以下命令：$ sudo ethtool -s eth0 autoneg off dup
7、lex full意思是利用自己的以太网设备代替eth0。端口正常吗？一旦确认了服务器与网络之间物理连接的完好性，接下来就是判断主机上的网络端口是否配置正确。在这方面，最好的检查方式就是运行ifconfig命令并将端口作为参数后缀。因此要测试eth0的设置，大家应该运行以下内容：代码：$ sudo ifconfig eth0eth0 Link encap:Ethernet HWaddr 00:17:42:1f:18:be inet addr:10.1.1.7 Bcast:10.1.1.255 Mask:255.255.255.0 inet6 addr: fe80:217:42ff:fe1f:18
8、be/64 Scope:Link UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:1 errors:0 dropped:0 overruns:0 frame:0 TX packets:11 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:229 (229.0 B) TX bytes:2178 (2.1 KB) Interrupt:10 在上述输出结果中，第二行可能最值得我们关注，因为其内容是解释我们的主机已经被配置了一套IP地址（1
9、0.1.1.7）与子网掩码（255.255.255.0）。现在，大家需要确认这样的设置结果是否正确。如果端口未受配置，请尝试运行sudo ifup eth0，然后再次运行ifconfig重新检查端口是否出现。如果设置错误或端口未出现，则检查/etc/network/interfaces路径（Debian系统）或/etc/-sysconfig/-network_scripts/ifcfg-路径（红帽系统）。在这些文件中，大家可以修正网络设置中存在的所有错误。现在如果主机通过DHCP获得自身IP，我们则需要将故障排查转移到DHCP主机处，找出为什么我们没有正确获得IP租用周期。 问题出在本地网络中
10、吗？排除了端口出现的问题之后，接下来我们就该检查默认网关是否被设置及我们能否对其进行访问。route命令将显示出我们当前的路由表，包括默认网关：代码：$ sudo route -nKernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Iface10.1.1.0 * 255.255.255.0 U 0 0 0 eth0default 10.1.1.1 0.0.0.0 UG 100 0 0 eth0以上内容中值得关注的在于最后一行，也就是default那段内容。在这里，大家可以看到主机网关为10.1.1.1.
11、请注意，由于我们在route命令后添加了-n选项，所以命令不会尝试将这些IP地址解析为实际主机名称。这种方式能让命令的运行更迅速，但更重要的是，我们不希望故障排查工作受到任何潜在DNS错误的影响。如果大家没有在这里看到经过配置的默认网关，而我们想要检查的主机处于另一子网之下（例如web1为10.1.2.5），那么问题很可能就出在这里。要将其解决，大家一定要确保网关设置要么处于Debian系统的/etc/network/interfaces路径下、要么是在红帽系统的/etc/-sysconfig/network_scripts/ifcfg-路径下；如果IP是由DHCP所分配，则确保网关在DHCP
12、服务器中被正确设置。在Debian系统中，我们运行如下命令进行端口重置：$ sudo service networking restart而在红帽系统中我们需要运行如下命令进行端口重置：$ sudo service network restart请大家注意，即使是如此基本的操作命令在不同的系统发行版中也存在着差异。一旦确认网关配置完成，我们可以利用ping命令来确认与网关的通信效果：代码：$ ping -c 5 10.1.1.1PING 10.1.1.1 (10.1.1.1) 56(84) bytes of data.64 bytes from 10.1.1.1: icmp_seq=1 ttl
13、=64 time=3.13 ms64 bytes from 10.1.1.1: icmp_seq=2 ttl=64 time=1.43 ms64 bytes from 10.1.1.1: icmp_seq=3 ttl=64 time=1.79 ms64 bytes from 10.1.1.1: icmp_seq=5 ttl=64 time=1.50 ms- 10.1.1.1 ping statistics -5 packets transmitted, 4 received, 20% packet loss, time 4020msrtt min/avg/max/mdev = 1.436/1.
14、966/3.132/0.686 ms如大家所见，我们已经能够正确ping通网关，这至少意味着大家与10.1.1.0网络能够进行通信。如果无法ping通网关，那么原因可能分以下几种。首先，这可能表示我们的网关自动阻断ICMP数据包。如果是这样，请告诉网络管理员阻断ICMP是种讨厌的坏习惯，由此带来的安全收益也微乎其微。然后尝试ping同一子网下的另一台Linux主机。如果ICMP没有被阻断，那么可能是主机交换机端口的VLAN设置有误，所以我们需要进一步检查接入的交换机。DNS能正常工作吗？一旦确认了与网关之间的通信能力，下面要做的就是测试DNS功能是否正常。nslookup与dig两款工具都能用
15、于排查DNS方面的问题，但由于在本实例中大家只需要进行一基础测试，因此我们建议使用nslookup命令可查看服务器能否将web1正确解析为IP地址：代码：$ nslookup web1Server: 10.1.1.3Address: 10.1.1.3#53Name: Address: 10.1.2.5如上所示，实例中的DNS服务器能够正常工作。web1主机扩展为且被解析为10.1.2.5地址。当然，大家别忘了确认解析出的IP地址与web1应该使用的IP地址相匹配。在本实例中，因为DNS没有问题，所以我们可以直接跳到下一部分；但有时候DNS也可能出现问题。没有配置过的名称服务器或无法访问名称服务
16、器如果大家看到如下错误，这可能意味着要么我们的主机没有配置过的名称服务器，要么这些服务器无法进行访问：代码：$ nslookup web1; connection timed out; no servers could be reached在这两种情况下，我们都需要检查/etc/resolv.conf文件以确认是否存在已配置的名称服务器。如果我们在这里找不到任何已配置的IP地址，则需要在文件中添加一个名称服务器。相反，如果我们看到如下所示的内容，则需要通过ping命令对主机与名称服务器之间的连接进行排查：代码：search nameserver 10.1.1.3如果无法ping通名称服务器，且
17、其IP地址与我们的主机处于同一子网下（在本实例中，10.1.1.3代表处于同一子网下），则代表名称服务器本身可能已经崩溃。如果无法ping通名称服务器且其IP地址与我们的主机处于不同子网下，则直接跳转至我能路由至远程主机吗？章节，选择其中与名称服务器IP故障排查相关的内容加以执行。如果通过ping通名称服务器但对方无响应，则跳转至远程端口是否打开？”章节。缺少搜索路径或名称服务器的问题在运行nslookup命令后，我们还可能得到以下错误信息：代码：$ nslookup web1Server: 10.1.1.3Address: 10.1.1.3#53* server cant find web1
18、: NXDOMAIN在这里大家可以看到服务器没有响应，因为它给出的回应表明：服务器无法找到web1。这可能意味着两种可能性：第一，这可能代表web1这一域名并不在DNS搜索路径当中。这部分搜索设置内容位于/etc/resolv.conf文件当中。推荐一种比较好的测试方式，即执行同样的nslookup命令，但只使用全称域名（在本实例中为）。如果能够被正确解析，则要么在命令中始终使用全称域名，要么在/etc/resolv.conf中将主机名称添加到搜索路径当中（如果大家懒得重复输入）。如果连全称域名也不能奏效，那么问题肯定出在名称服务器上。这里我们汇总了一些DNS问题的故障排查指南。如果名称服务器
19、保存有记录，则需要对其配置进行检查。如果使用的是递归名称服务器，我们则必须通过查找其它一些域来测试名称服务器的递归机制是否正常。如果其它域都能被正确列出，我们就要看看问题是不是出在包含上述区域的远程名称服务器端。我能路由至远程主机吗？在排除了DNS问题并看到web1被正确解析为IP 10.1.2.5之后，大家需要测试自己能否路由至远程主机。假如我们的网络启用了ICMP，那么最快捷的测试办法是ping web1。如果该主机能被ping通，我们就知道数据包已经被路由至目的地，这样的话可以直接跳转至远程端口打开了吗？章节。如果无法ping通web1，则尝试与网络中的另一台主机通信看看能否ping通。
20、如果我们无法在远程网络中ping通任何主机，就说明数据包无法被正确路由。最好的路由问题测试工具这一就是traceroute。一旦与一台主机建立起路由追踪，它会测试我们与主机之间的每一次数据包跳转。举例来说，dev1与web1之间的一次成功路由追踪流程将如下所示：代码：$ traceroute 10.1.2.5traceroute to 10.1.2.5 (10.1.2.5), 30 hops max, 40 byte packets1 10.1.1.1 (10.1.1.1) 5.432 ms 5.206 ms 5.472 ms2 web1 (10.1.2.5) 8.039 ms 8.348 m
21、s 8.643 ms这里我们会看到数据包从dev1到达其网关（10.1.1.1），然后再跳转至web1。这代表着起始位置与目标主机可能都采用10.1.1.1网关。如果大家的操作环境中存在更多路由中转点，那么显示的结果可能与上述内容有所不同。如果无法ping通web1，那么输入结果将如下所示：代码：$ traceroute 10.1.2.5traceroute to 10.1.2.5 (10.1.2.5), 30 hops max, 40 byte packets1 10.1.1.1 (10.1.1.1) 5.432 ms 5.206 ms 5.472 ms2 * * *3 * * *一旦我们在
22、输出结果中看到星号，就说明问题出在网关方面。大家需要从路由器着手，看看为什么它无法在两套网络之间路由数据包。通过追踪，大家会看到如下内容：代码；$ traceroute 10.1.2.5traceroute to 10.1.2.5 (10.1.2.5), 30 hops max, 40 byte packets1 10.1.1.1 (10.1.1.1) 5.432 ms 5.206 ms 5.472 ms1 10.1.1.1 (10.1.1.1) 3006.477 ms !H 3006.779 ms !H 3007.072 ms在这种情况下，我们发现ping操作在网关环节出现了超时，这说明该主
23、机可能已经崩溃或无法通过同一子网进行访问。有鉴于此，如果大家还没有从同一子网下的其它设备访问过web1，请尝试ping及其它测试。注意：如果某套烦人的网络仍然在阻断ICMP，不用担心，我们仍然有办法进行路由排查工作。大家只需要安装tcptraceroute软件包(sudo apt-get install tcptraceroute)然后运行相同的路由追踪命令，惟一的区别是用tcptraceroute来代替traceroute 。远程端口打开了吗？现在我们已经能够路由至目标设备，但仍然无法在端口80上访问web服务器。接下来的测试意在检查端口是否打开。要实现这一目的，我们可以选择的方案很多。选择
24、其一，我们可以尝试telnet：代码：$ telnet 10.1.2.5 80Trying 10.1.2.5.telnet: Unable to connect to remote host: Connection refused如果大家看到连接被拒绝，那么端口很可能处于关闭状态（可能是Apache未能运行在远程主机上或没有侦听该端口），也可能是防火墙阻断了我们的访问。如果telnet能够连接，那么恭喜各位，现在大家已经解决了所有网络问题。但如果web服务的工作状态与我们的预期不符，则需要检查web1上的Apache配置（web服务器的故障排查工作在本文的其它章节会谈到）。但相对于telnet
25、，我个人更偏向使用nmap来进行端口测试，因为它往往能够检测到防火墙的影响。如果大家还没有安装nmap，可以使用软件包管理器快速安装nmap软件包。要对web1进行测试，请输入以下内容：代码：$ nmap -p 80 10.1.2.5Starting Nmap 4.62 ( http:/nmap.org ) at 2009-02-05 18:49 PSTInteresting ports on web1 (10.1.2.5):PORT STATE SERVICE80/tcp filtered httpnmap果然不负众望，它一般都能发现所谓关闭的端口到底是直接处于关闭状态、还是在防火墙后处于关
26、闭状态。通常情况下，nmap会将真正关闭的端口报告为关闭，而将防火墙后的端口报告为过滤。在我们的测试中它报告其状态为过滤，意味着期间有防火墙作梗并忽略掉了我们的数据包。如此一来，大家就需要检查网关（10.1.1.1）以及web1上的全部防火墙规则，看看端口80是否处于阻断状态。在本地测试远程主机到了这里，摆在我们面前的就有两种可能性：要么将故障范围缩小为网络问题，要么认定毛病出在主机自身。如果大家认定毛病出在主机自身，我们可以通过一系列操作检查端口80是否可用。侦听端口测试我们在web1上要做的第一件事就是测试端口80是否处于侦听状态。大家可以使用netstat -lnp命令来列出所有打开且处
27、于侦听状态的端口。我们当然可以直接运行这条命令并从输出结果中筛选出自己想要的结论，但效率更高的方式则是利用grep指定显示端口80的侦听状态：代码：$ sudo netstat -lnp | grep :80tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 919/apache第一列内容显示出端口所使用的传输协议。第二及第三列则显示接收及发送队列（这里两者都被设置为0）。现在我们要注意的是第四列，因为它列出了主机所侦听的本地地址。此处的0.0.0.0：80告诉我们该主机正侦听所有端口80流量中与其IP有关的数据。如果Apache只侦听web1的以太网地址，我们将在输出结果
28、中看到10.1.2.5：80。最后一列显示的是哪个进程令端口处于开放状态。这里我们看到是运行中的Apache正在进行侦听。如果大家在自己的netstat输出结果中没有看到这部分内容，则需要启动Apache服务器。防火墙规则如果进程正在运行且侦听端口80，那就说明可能是web1中某种形式的防火墙导致了问题的发生。利用iptables命令列出全部现有防火墙规则。如果我们的防火墙已被禁用，那么输出结果应如下所示：代码：$ sudo /sbin/iptables -LChain INPUT (policy ACCEPT)target prot opt source destinationChain F
29、ORWARD (policy ACCEPT)target prot opt source destinationChain OUTPUT (policy ACCEPT)target prot opt source destination请注意，默认政策被设置为ACCEPT。尽管规则本身没有问题，但防火墙仍然有可能默认弃用所有数据包。如果属于这类情况，大家会看到如下所示的输出内容：代码：$ sudo /sbin/iptables -LChain INPUT (policy DROP)target prot opt source destinationChain FORWARD (policy D
30、ROP)target prot opt source destinationChain OUTPUT (policy DROP)target prot opt source destination另一方面，如果某条防火墙规则阻断了端口80，那么输出结果则应如下所示：代码：$ sudo /sbin/iptables -L -nChain INPUT (policy ACCEPT)target prot opt source destinationREJECT tcp - 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 reject-with(icmp-port-unreachabl
31、eChain FORWARD (policy ACCEPT)target prot opt source destinationChain OUTPUT (policy ACCEPT)target prot opt source destination在后一种情况下，我们显然需要修改防火墙规则，以允许服务器接收来自端口80的主机数据流量。网络缓慢状况的故障排查从某种角度来说，网络无法工作的问题更容易解决。当一台主机无法访问，我们可以执行前面讨论过的故障排查步骤直到一切恢复正常。但如果仅仅是网络缓慢，追查其根本原因往往变得更为棘手。本章节将讨论一些相关技巧，帮助大家追踪导致网络速度缓慢的各种原因
32、。DNS问题虽然DNS在网络出现问题时常常蒙冤受责，但在导致网络性能不佳方面，DNS倒真该被优先检查一番。举例来说，如果我们为某个域名配置了两台DNS服务器，那么在第一台出现问题时，我们发出的DNS请求会等待30秒之后才传输至第二台DNS服务器。虽然当我们使用像dig或nslookup这样的工具时此类情况显得一目了然，但对于日常使用来说，DNS故障往往会以令人意外的方式造成网络缓慢；这是因为有太多服务需要借助DNS实现将主机名称解析为IP地址的工作。这些问题甚至有可能影响到我们的网络故障诊断工具。Ping、tracerouter、oute、netstat甚至包括iptables在内的多款网络故障排查工具都会受到DNS问题的牵连而导致速度缓慢。在默认情况下，上述所有工具都会尽可能尝试将IP地址解析为主机名称。一旦DNS服务器有了毛病，这些命令就会在查找IP地址的过程中停滞不前并最终导致执行失效。在ping或traceroute方面，问题表现为整个ping应答周期耗时相当长
