本专栏是关于我最喜欢的主题之一：故障排除系列文章的第三篇。由于我的专栏通常更侧重于技巧和窍门，而不是哲学和设计，因此我不太谈论解决问题的总体方法。相反，在本系列中，我描述了您可能在 Linux 系统上发现的一些常见问题类型，然后我讨论如何使用常见的工具（其中大多数可能已在您的系统上）来隔离和解决每类问题。

在我的上一篇专栏中，我介绍了一些在本地网络上排除网络问题的方法。许多网络问题会超出您的本地网络，延伸到其他本地子网或 Internet 本身。在本专栏中，我将为您提供工具和技术，以解答那个不朽的问题：是 Internet 瘫痪了，还是只有我这样？

我在此处用于测试故障排除技能的场景是每个人都遇到过的情况——您尝试加载一个网站，甚至是一个像 Google 这样可靠的网站，但它无法打开。由于我在上一篇专栏中介绍了本地网络故障排除，因此我假设您已经完成了这些步骤，并准备好超越本地网络。即使此示例处理的是测试对 Internet 的访问，您也可以使用相同的步骤来排除访问任何远程网络的问题。

为了让您的计算机与本地网络之外的任何其他计算机通信，您必须在本地网络上配置网关（路由器），并且您必须能够访问它。在不深入探讨重型网络理论的情况下，路由器连接两个或多个网络，并知道如何在这些网络之间路由数据包。您的 Linux 计算机有一个路由器列表，其中列出了它知道的每个网络的路由器，以及何时应使用这些路由器，所有这些都存储在其路由表中。您可以使用 route 命令来显示计算机当前的路由表

$ route -n
Kernel IP routing table
Destination  Gateway   Genmask         Flags Metric Ref  Use Iface
10.1.1.0     *          255.255.255.0   U     0      0     0 eth0
default      10.1.1.1  0.0.0.0          UG    100    0     0 eth0

在上面的示例中，我定义了一个网关：10.1.1.1。它被列为我的默认网关，这是它在没有为该网络定义任何其他路由器时将使用的路由器。在我的例子中，它也是我的路由表中唯一的路由器。这意味着，任何时候我的机器想要与远程网络通信（在我的示例中，任何不在 10.1.1.0/255.255.255.0 或 10.1.1.1–10.1.1.254 范围内的网络），它都会将数据包发送到 10.1.1.1 进行转发。

现在我知道了我的默认网关，我使用 ping 来测试它是否可用

$ ping -c 5 10.1.1.1
PING 10.1.1.1 (10.1.1.1) 56(84) bytes of data.
64 bytes from 10.1.1.1: icmp_seq=1 ttl=64 time=3.13 ms
64 bytes from 10.1.1.1: icmp_seq=2 ttl=64 time=1.43 ms
64 bytes from 10.1.1.1: icmp_seq=3 ttl=64 time=1.79 ms
64 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 4020ms
rtt min/avg/max/mdev = 1.436/1.966/3.132/0.686 ms

在本示例中，收到了五个 ping 数据包中的四个，因此我可以合理地确定我的网关工作正常。如果我无法 ping 通网关，则可能是我的网络管理员阻止了 ICMP 数据包（我讨厌人们这样做），我的交换机端口设置为错误的 VLAN，或者我的网关真的瘫痪了。如果网关瘫痪了，解决问题可能意味着重启您的 DSL 或无线路由器（如果那是您连接到 Internet 的方式），或者将您的故障排除转移到充当您网关的任何设备。

在我的例子中，我能够 ping 通网关，所以我准备好继续进行 DNS。因为我们大多数人都不通过 IP 地址浏览 Web，所以我们需要 DNS 将我们键入的主机名解析为 IP 地址。如果 DNS 工作不正常，即使我们从技术上可以访问该远程 IP 地址，我们也永远不会知道 IP 地址是什么。

测试 DNS 的基本方法是通过 nslookup 命令

$ nslookup www.linuxjournal.com
Server:	 10.2.2.2
Address:	10.2.2.2#53

Non-authoritative answer:
Name:	www.linuxjournal.com
Address: 76.74.252.198

在本示例中，就我所知，DNS 功能正常。我说就我所知，是因为我假设 76.74.252.198 是 www.linuxjournal.com 的正确 IP 地址。如果它是错误的地址，那很可能就是问题的原因！在本例中，DNS 服务器是 10.2.2.2，但在某些环境中，它可能与您的网关的 IP 地址相同。

即使 DNS 服务器工作正常，但因为我想展示如何排除 DNS 故障，所以我需要一些 DNS 可能发生故障的示例。为了说明这一点，让我展示一些失败的 nslookup 命令

$ nslookup www.linuxjournal.com
;; connection timed out; no servers could be reached

此错误告诉我 nslookup 无法与我的 DNS 服务器通信。这可能是因为我的系统上没有配置任何名称服务器，或者我只是无法访问它们。要查看我是否配置了任何名称服务器，我将检查我的 /etc/resolv.conf 文件。此文件跟踪我应该使用的名称服务器。在我的例子中，它看起来像这样

search example.net
nameserver 10.2.2.2

如果您的 resolv.conf 文件没有名称服务器条目，您就找到了问题所在。您需要在此处添加您的名称服务器的 IP 地址。因为我确实在 resolv.conf 中定义了名称服务器，所以下一步是尝试使用与上面用于网关的 ping 命令相同的 ping 命令来 ping 名称服务器的 IP。如果您无法 ping 通名称服务器，则可能是防火墙阻止了 ICMP（那些讨厌的网络管理员！），或者您与名称服务器之间存在路由问题。为了排除后者，请使用一个名为 traceroute 的工具。Traceroute 测试您与远程 IP 地址之间的路由。要使用它，请键入traceroute后跟您要访问的 IP 地址。在我的例子中，我将使用 10.2.2.2

$ traceroute 10.2.2.2
traceroute to 10.2.2.2 (10.2.2.2), 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  10.2.2.2 (10.2.2.2)  8.039 ms  8.348 ms  8.643 ms

在本示例中，我可以成功路由到 10.2.2.2。为了到达那里，我的数据包首先发送到 10.1.1.1，然后直接移动到 10.2.2.2。这告诉我 10.1.1.1 很可能是两个网络的网关。如果您和远程服务器之间有更多路由器，那么您将有更多的跃点。另一方面，如果您确实遇到路由问题，则您的输出可能更像以下内容

$ traceroute 10.2.2.2
traceroute to 10.2.2.2 (10.2.2.2), 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 在网关处超时，因此远程主机可能已关闭、未插拔或无法访问，因此您需要排除其与网络的连接故障。

注意：traceroute 依赖于 ICMP，因此如果您的网络上阻止了 ICMP，请安装一个名为 tcptraceroute 的工具，以通过 TCP 执行类似的测试（语法相同，您只需键入tcptraceroute而不是traceroute).

如果您可以 ping 通名称服务器，但它没有响应您，请返回到我的上一篇专栏，并执行所有故障排除步骤，以测试远程端口是否在远程主机上打开且可访问。但请记住，DNS 服务器在 TCP 和 UDP 上使用端口 53。同样，如果您不确定服务使用哪个端口，请检查您系统上的 /etc/services 文件。它列出了您将使用的大多数常用服务。

您可能遇到的另一个常见的 nslookup 错误是这个

$ nslookup web1
Server:      10.2.2.2
Address:     10.2.2.2#53

** server can't find web1: NXDOMAIN

在这里，我的名称服务器在 10.2.2.2 处响应了我，但告诉我它找不到服务器 web1 的记录。此错误可能意味着我的 DNS 搜索路径中没有 web1 的正确域名。如果您没有指定主机的完全限定域名（例如，web1.mysite.com），而是使用主机名的简写形式，则您的系统将检查 /etc/resolv.conf 以查找 DNS 搜索路径中的域。然后，它将逐个将这些域添加到您的主机名末尾，以查看它是否解析。DNS 搜索路径是 /etc/resolv.conf 中以单词开头的行search:

search example.net example2.net
nameserver 10.2.2.2

在我的例子中，当我搜索 web1 的 IP 地址时，我的系统将首先搜索 web1.example.net，如果该地址没有记录，它将搜索 web1.example2.net。如果您想测试这是否是问题所在，只需再次运行 nslookup，但使用完全限定域名（例如 web1.mysite.com）。如果它解析，请确保您在访问该服务器时始终使用完全限定域名，或者将该域添加到 /etc/resolv.conf 中的搜索路径。

如果您针对完全限定域名尝试 nslookup，但仍然收到上面的相同 NXDOMAIN 错误，则您的问题出在名称服务器本身。排除 DNS 服务器问题的全部范围有点超出我可以在本专栏中合理容纳的范围，但以下是一些帮助您入门的步骤。如果您知道您的 DNS 服务器配置为拥有您正在查找的记录本身，则需要检查其区域记录以确保该特定主机名存在。另一方面，如果您正在搜索您知道它没有记录的域（例如，www.linuxjournal.com），则可能是您的 DNS 服务器不允许来自您的主机或任何主机的递归查询。您可以通过尝试解析 Internet 上的其他一些远程主机来测试这一点。如果它没有解析，则可能是递归设置。如果它解析，则问题很可能出在该远程站点的 DNS 服务器上。

如果在所有这些测试之后，您发现您的 DNS 服务器工作正常，但您仍然无法访问远程服务器，则最后一步是执行另一个 traceroute，就像上面一样，只是直接针对远程服务器。例如，如果您想测试到 www.linuxjournal.com 的路由，则 traceroute 可能如下所示

$ traceroute www.linuxjournal.com
traceroute to www.linuxjournal.com (76.74.252.198), 30 hops max, 
 ↪60 byte packets
1  10.1.1.1 (10.1.1.1)  1.016 ms  2.222 ms  2.308 ms
2  75-101-46-1.dsl.static.sonic.net (75.101.46.1)  6.916 ms  
 ↪7.389 ms  8.386 ms
3  921.gig0-3.gw.sjc2.sonic.net (75.101.33.221)  11.265 ms  
 ↪12.435 ms  13.050 ms
4  108.ae0.gw.equinix-sj.sonic.net (64.142.0.73)  13.846 ms  
 ↪15.233 ms  15.390 ms
5  GIG2-0.sea-dis-2.peer1.net (206.81.80.38)  35.149 ms  
 ↪36.272 ms  36.944 ms
6  oc48.so-2-1-0.sea-coloc-dis-1.peer1.net (216.187.89.190)  
 ↪37.340 ms  27.884 ms  27.266 ms
7  10ge.ten1-2.sj-mkp16-dis-1.peer1.net (216.187.88.202)  
 ↪28.421 ms  29.014 ms 29.688 ms
8  10ge.ten1-2.sj-mkp2-dis-1.peer1.net (216.187.88.134)  
 ↪30.903 ms  31.015 ms 31.804 ms
9  10ge-ten1-3.la-600w-cor-1.peer1.net (216.187.88.130)  
 ↪40.840 ms  41.279 ms 42.069 ms
10  10ge.ten1-1.la-600w-cor-2.peer1.net (216.187.88.146)  
 ↪42.587 ms  43.710 ms 44.921 ms
11  10ge-ten1-2.dal-eqx-cor-1.peer1.net (216.187.124.122)  
 ↪81.702 ms  82.959 ms 83.934 ms
12  10ge-ten1-1.dal-eqx-cor-2.peer1.net (216.187.124.134)  
 ↪74.876 ms  72.454 ms 72.798 ms
13  10ge-ten1-3.sat-8500v-cor-2.peer1.net (216.187.124.178)  
 ↪80.224 ms  81.872 ms  82.569 ms
14  216.187.124.110 (216.187.124.110)  83.499 ms  84.162 ms  
 ↪85.048 ms
15  www.linuxjournal.com (76.74.252.198)  85.484 ms  86.461 ms  
 ↪87.153 ms

在本示例中，我距离 www.linuxjournal.com 服务器有 15 个跃点（或路由器）。这是一个成功查询的示例，但是如果您运行相同的查询并注意到许多行星号从未到达您的目的地 并且 您无法直接 ping 通 www.linuxjournal.com，则问题可能是您与远程网络之间的 Internet 路由问题。不幸的是，这可能是一些您无法控制的事情，但幸运的是，这些类型的问题往往会很快自行解决，因此只需不断尝试即可。

另一方面，如果您的 traceroute 命令成功，但远程站点仍然无法工作，请返回到我在上一篇专栏中讨论的步骤，了解如何使用 telnet 和 nmap 来测试远程端口是否打开。实际上可能是远程服务器已关闭（嘿，这种情况发生在最好的人身上），或者有人配置了防火墙来阻止您访问该远程服务器。

我希望本系列文章激发（或重新点燃）您对 Linux 下故障排除的兴趣。我喜欢 Linux 的一点是，它对您隐藏了很少关于其工作原理的信息，并且在出现问题时提供了许多故障排除工具。如果这引起了您的兴趣，那么还有更多的故障排除途径供您探索——从我上面提到的 DNS 服务器，到排除几乎任何类型的服务故障。此外，如果您有任何其他用于跟踪这些问题的出色工具或技术，请给我留言。我一直在寻找更快解决问题的工具。