如大家所见，我们已经能够正确ping通网关，这至少意味着大家与10.1.1.0网络能够进行通信。如果无法ping通网关，那么原因可能分以下几种。首先，这可能表示我们的网关自动阻断ICMP数据包。如果是这样，请告诉网络管理员阻断ICMP是种讨厌的坏习惯，由此带来的安全收益也微乎其微。然后尝试ping同一子网下的另一台Linux主机。如果ICMP没有被阻断，那么可能是主机交换机端口的VLAN设置有误，所以我们需要进一步检查接入的交换机。

　　DNS能正常工作吗?

　　一旦确认了与网关之间的通信能力，下面要做的就是测试DNS功能是否正常。nslookup与dig两款工具都能用于排查DNS方面的问题，但由于在本实例中大家只需要进行一基础测试，因此我们建议使用nslookup命令可查看服务器能否将web1正确解析为IP地址：

　　$ nslookup web1

　　Server: 10.1.1.3

　　Address: 10.1.1.3#53

　　Name: web1.example.net

　　Address: 10.1.2.5

　　如上所示，实例中的DNS服务器能够正常工作。web1主机扩展为web1.example.net且被解析为10.1.2.5地址。当然，大家别忘了确认解析出的IP地址与web1应该使用的IP地址相匹配。在本实例中，因为DNS没有问题，所以我们可以直接跳到下一部分;但有时候DNS也可能出现问题。

　　没有配置过的名称服务器或无法访问名称服务器

　　如果大家看到如下错误，这可能意味着要么我们的主机没有配置过的名称服务器，要么这些服务器无法进行访问：

　　$ nslookup web1

　　;; connection timed out; no servers could be reached

　　在这两种情况下，我们都需要检查/etc/resolv.conf文件以确认是否存在已配置的名称服务器。如果我们在这里找不到任何已配置的IP地址，则需要在文件中添加一个名称服务器。相反，如果我们看到如下所示的内容，则需要通过ping命令对主机与名称服务器之间的连接进行排查：

　　search example.net

　　nameserver 10.1.1.3

　　如果无法ping通名称服务器，且其IP地址与我们的主机处于同一子网下(在本实例中，10.1.1.3代表处于同一子网下)，则代表名称服务器本身可能已经崩溃。如果无法ping通名称服务器且其IP地址与我们的主机处于不同子网下，则直接跳转至"我能路由至远程主机吗?"章节，选择其中与名称服务器IP故障排查相关的内容加以执行。如果通过ping通名称服务器但对方无响应，则跳转至"远程端口是否打开?”章节。

　　缺少搜索路径或名称服务器的问题

　　在运行nslookup命令后，我们还可能得到以下错误信息：

　　$ nslookup web1

　　Server: 10.1.1.3

　　Address: 10.1.1.3#53

　　** server can't find web1: NXDOMAIN

　　在这里大家可以看到服务器没有响应，因为它给出的回应表明：服务器无法找到web1。这可能意味着两种可能性：第一，这可能代表web1这一域名并不在DNS搜索路径当中。这部分搜索设置内容位于/etc/resolv.conf文件当中。推荐一种比较好的测试方式，即执行同样的nslookup命令，但只使用全称域名(在本实例中为web1.example.net)。如果能够被正确解析，则要么在命令中始终使用全称域名，要么在/etc/resolv.conf中将主机名称添加到搜索路径当中(如果大家懒得重复输入)。

　　如果连全称域名也不能奏效，那么问题肯定出在名称服务器上。这里我们汇总了一些DNS问题的故障排查指南。如果名称服务器保存有记录，则需要对其配置进行检查。如果使用的是递归名称服务器，我们则必须通过查找其它一些域来测试名称服务器的递归机制是否正常。如果其它域都能被正确列出，我们就要看看问题是不是出在包含上述区域的远程名称服务器端。

　　我能路由至远程主机吗?

　　在排除了DNS问题并看到web1被正确解析为IP 10.1.2.5之后，大家需要测试自己能否路由至远程主机。假如我们的网络启用了ICMP，那么最快捷的测试办法是ping web1。如果该主机能被ping通，我们就知道数据包已经被路由至目的地，这样的话可以直接跳转至"远程端口打开了吗?"章节。如果无法ping通web1，则尝试与网络中的另一台主机通信看看能否ping通。如果我们无法在远程网络中ping通任何主机，就说明数据包无法被正确路由。最好的路由问题测试工具这一就是traceroute。一旦与一台主机建立起路由追踪，它会测试我们与主机之间的每一次数据包跳转。举例来说，dev1与web1之间的一次成功路由追踪流程将如下所示：

　　$ traceroute 10.1.2.5

　　traceroute to 10.1.2.5 (10.1.2.5), 30 hops max, 40 byte packets

　　1 10.1.1.1 (10.1.1.1) 5.432 ms 5.206 ms 5.472 ms

　　2 web1 (10.1.2.5) 8.039 ms 8.348 ms 8.643 ms

　　这里我们会看到数据包从dev1到达其网关(10.1.1.1)，然后再跳转至web1。这代表着起始位置与目标主机可能都采用10.1.1.1网关。如果大家的操作环境中存在更多路由中转点，那么显示的结果可能与上述内容有所不同。如果无法ping通web1，那么输入结果将如下所示：

　　$ traceroute 10.1.2.5

　　traceroute to 10.1.2.5 (10.1.2.5), 30 hops max, 40 byte packets

　　1 10.1.1.1 (10.1.1.1) 5.432 ms 5.206 ms 5.472 ms

　　2 * * *

　　3 * * *

　　一旦我们在输出结果中看到星号，就说明问题出在网关方面。大家需要从路由器着手，看看为什么它无法在两套网络之间路由数据包。通过追踪，大家会看到如下内容：

　　$ traceroute 10.1.2.5

　　traceroute to 10.1.2.5 (10.1.2.5), 30 hops max, 40 byte packets

　　1 10.1.1.1 (10.1.1.1) 5.432 ms 5.206 ms 5.472 ms

　　1 10.1.1.1 (10.1.1.1) 3006.477 ms !H 3006.779 ms !H 3007.072 ms

　　在这种情况下，我们发现ping操作在网关环节出现了超时，这说明该主机可能已经崩溃或无法通过同一子网进行访问。有鉴于此，如果大家还没有从同一子网下的其它设备访问过web1，请尝试ping及其它测试。

　　注意：如果某套烦人的网络仍然在阻断ICMP，不用担心，我们仍然有办法进行路由排查工作。大家只需要安装tcptraceroute软件包(sudo apt-get install tcptraceroute)然后运行相同的路由追踪命令，惟一的区别是用tcptraceroute来代替traceroute 。

　　远程端口打开了吗?

　　现在我们已经能够路由至目标设备，但仍然无法在端口80上访问web服务器。接下来的测试意在检查端口是否打开。要实现这一目的，我们可以选择的方案很多。选择其一，我们可以尝试telnet：

　　$ telnet 10.1.2.5 80

　　Trying 10.1.2.5...

　　telnet: Unable to connect to remote host: Connection refused

　　如果大家看到连接被拒绝，那么端口很可能处于关闭状态(可能是Apache未能运行在远程主机上或没有侦听该端口)，也可能是防火墙阻断了我们的访问。如果telnet能够连接，那么恭喜各位，现在大家已经解决了所有网络问题。但如果web服务的工作状态与我们的预期不符，则需要检查web1上的Apache配置(web服务器的故障排查工作在本文的其它章节会谈到)。

　　但相对于telnet，我个人更偏向使用nmap来进行端口测试，因为它往往能够检测到防火墙的影响。如果大家还没有安装nmap，可以使用软件包管理器快速安装nmap软件包。要对web1进行测试，请输入以下内容：

　　$ nmap -p 80 10.1.2.5

　　Starting Nmap 4.62 ( http://nmap.org ) at 2009-02-05 18:49 PST

　　Interesting ports on web1 (10.1.2.5):

　　PORT STATE SERVICE

　　80/tcp filtered http

　　nmap果然不负众望，它一般都能发现所谓"关闭的端口"到底是直接处于关闭状态、还是在防火墙后处于关闭状态。通常情况下，nmap会将真正关闭的端口报告为"关闭"，而将防火墙后的端口报告为"过滤"。在我们的测试中它报告其状态为"过滤"，意味着期间有防火墙作梗并忽略掉了我们的数据包。如此一来，大家就需要检查网关(10.1.1.1)以及web1上的全部防火墙规则，看看端口80是否处于阻断状态。

　　在本地测试远程主机

　　到了这里，摆在我们面前的就有两种可能性：要么将故障范围缩小为网络问题，要么认定毛病出在主机自身。如果大家认定毛病出在主机自身，我们可以通过一系列操作检查端口80是否可用。

　　侦听端口测试

　　我们在web1上要做的第一件事就是测试端口80是否处于侦听状态。大家可以使用netstat -lnp命令来列出所有打开且处于侦听状态的端口。我们当然可以直接运行这条命令并从输出结果中筛选出自己想要的结论，但效率更高的方式则是利用grep指定显示端口80的侦听状态：

　　$ sudo netstat -lnp | grep :80

　　tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 919/apache

　　第一列内容显示出端口所使用的传输协议。第二及第三列则显示接收及发送队列(这里两者都被设置为0)。现在我们要注意的是第四列，因为它列出了主机所侦听的本地地址。此处的0.0.0.0：80告诉我们该主机正侦听所有端口80流量中与其IP有关的数据。如果Apache只侦听web1的以太网地址，我们将在输出结果中看到10.1.2.5：80。

　　最后一列显示的是哪个进程令端口处于开放状态。这里我们看到是运行中的Apache正在进行侦听。如果大家在自己的netstat输出结果中没有看到这部分内容，则需要启动Apache服务器。



(责任编辑：IT)