问题出在本地网络中吗？
排除了端口出现的问题之后，接下来我们就该检查默认网关是否被设置及我们能否对其进行访问。route命令将显示出我们当前的路由表，包括默认网关：
| $ sudo 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 |
以上内容中值得关注的在于最后一行，也就是default那段内容。在这里，大家可以看到主机网关为10.1.1.1.请注意，由于我们在route命令后添加了-n选项，所以命令不会尝试将这些IP地址解析为实际主机名称。这种方式能让命令的运行更迅速，但更重要的是，我们不希望故障排查工作受到任何潜在DNS错误的影响。如果大家没有在这里看到经过配置的默认网关，而我们想要检查的主机处于另一子网之下（例如web1为10.1.2.5），那么问题很可能就出在这里。要将其解决，大家一定要确保网关设置要么处于Debian系统的/etc/network/interfaces路径下、要么是在红帽系统的/etc/-sysconfig/network_scripts/ifcfg-<interface>路径下；如果IP是由DHCP所分配，则确保网关在DHCP服务器中被正确设置。在Debian系统中，我们运行如下命令进行端口重置：
| $ sudo service networking restart |
而在红帽系统中我们需要运行如下命令进行端口重置：
| $ sudo service network restart |
请大家注意，即使是如此基本的操作命令在不同的系统发行版中也存在着差异。
一旦确认网关配置完成，我们可以利用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通网关，这至少意味着大家与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也可能出现问题。
