我们目前有三个networking服务器。
服务器一和二的行为，但我有第三个真正的问题。
wget ， curl和yum都无法build立连接 – 也就是说，在parsing主机并尝试连接之后，它们全部挂起。
例子（我尝试了很多不同的url）：
# wget http://rpm.pbone.net/index.php3/stat/4/idpl/13941547/dir/centos_5/com/httpd-2.2.3-43.el5.centos.i386.rpm.html --2010-09-02 20:00:26-- http://rpm.pbone.net/index.php3/stat/4/idpl/13941547/dir/centos_5/com/httpd-2.2.3-43.el5.centos.i386.rpm.html Resolving rpm.pbone.net... 85.14.85.4 Connecting to rpm.pbone.net|85.14.85.4|:80...
挂起
# curl -v http://rpm.pbone.net/index.php3/stat/4/idpl/13941547/dir/centos_5/com/httpd-2.2.3-43.el5.centos.i386.rpm.html * About to connect() to rpm.pbone.net port 80 * Trying 85.14.85.4...
挂起
#yum -d9 update Loading "fastestmirror" plugin Config time: 0.052 Running "init" handler for "fastestmirror" plugin Yum Version: 3.2.22 COMMAND: yum -d9 update Installroot: / Setting up Package Sacks Running "postreposetup" handler for "fastestmirror" plugin Loading mirror speeds from cached hostfile
挂起
但：
# ping rpm.pbone.net PING gepard.pbone.net (85.14.85.4) 56(84) bytes of data. 64 bytes from gepard.pbone.net (85.14.85.4): icmp_seq=1 ttl=49 time=449 ms 64 bytes from gepard.pbone.net (85.14.85.4): icmp_seq=2 ttl=49 time=448 ms 64 bytes from gepard.pbone.net (85.14.85.4): icmp_seq=3 ttl=49 time=444 ms 64 bytes from gepard.pbone.net (85.14.85.4): icmp_seq=4 ttl=49 time=445 ms 64 bytes from gepard.pbone.net (85.14.85.4): icmp_seq=5 ttl=49 time=457 ms
我远离服务器专家，有没有人有任何指示，在哪里开始解决这个问题？
编辑：
# netstat -lan | egrep LISTEN tcp 0 0 0.0.0.0:941 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN tcp 0 0 :::80 :::* LISTEN tcp 0 0 :::22 :::* LISTEN unix 2 [ ACC ] STREAM LISTENING 7451 /tmp/.font-unix/fs7100 unix 2 [ ACC ] STREAM LISTENING 7678 @/tmp/fam-root- unix 2 [ ACC ] STREAM LISTENING 5824 @/var/run/hald/dbus-3hUBzR5e9e unix 2 [ ACC ] STREAM LISTENING 5087 /var/run/audispd_events unix 2 [ ACC ] STREAM LISTENING 5825 @/var/run/hald/dbus-rDLe61j4bM unix 2 [ ACC ] STREAM LISTENING 5545 /var/run/dbus/system_bus_socket unix 2 [ ACC ] STREAM LISTENING 5616 /var/run/sdp unix 2 [ ACC ] STREAM LISTENING 5749 /var/run/pcscd.comm unix 2 [ ACC ] STREAM LISTENING 5782 /var/run/acpid.socket unix 2 [ ACC ] STREAM LISTENING 7075 /var/run/cups/cups.sock unix 2 [ ACC ] STREAM LISTENING 7585 /var/run/avahi-daemon/socket unix 2 [ ACC ] STREAM LISTENING 7389 /dev/gpmctl
# iptables --list Chain INPUT (policy ACCEPT) target prot opt source destination RH-Firewall-1-INPUT all -- anywhere anywhere Chain FORWARD (policy ACCEPT) target prot opt source destination RH-Firewall-1-INPUT all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain RH-Firewall-1-INPUT (2 references) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT icmp -- anywhere anywhere icmp any ACCEPT esp -- anywhere anywhere ACCEPT ah -- anywhere anywhere ACCEPT udp -- anywhere 224.0.0.251 udp dpt:mdns ACCEPT udp -- anywhere anywhere udp dpt:ipp ACCEPT tcp -- anywhere anywhere tcp dpt:ipp ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:http REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
您有适当的防火墙规则阻止端口80出站，或拒绝相互入站的响应。 这些可能是软件防火墙规则可能是专门阻止端口80或TCP（PING是ICMP）的所有，请检查：
正如ErikA所指出的那样， iptables -L 。
这也可能是一个硬件防火墙问题 – 思科防火墙背后的服务器？ 请咨询您的系统pipe理员。 如果你可以从其他机器curl，他们有：80打开。 这也可能，但不太可能，他们阻止你是他们的一方，但如果你不能curl任何东西（甚至谷歌），这是你的一面。
那么，ping使用ICMP，而所有这些HTTP客户端使用TCP端口80.可以阻止源和目标之间？
在我的情况下，这个问题是由陈旧的DNScaching引起的。 以下帮助：
# service nscd restart
我将如何检查端口80上正在监听的内容，并且没有防火墙规则可阻止来自我正在testing的IP的oprt 80stream量？
确保某个端口正在侦听端口80，并且没有防火墙规则可阻止来自您正在testing的IP地址的到端口80的stream量。
要检查端口80上是否正在侦听，请从Web服务器本身运行以下命令：
$ netstat -lan | egrep LISTEN
在输出中，如果你看到这样的一行，那么在端口80上正在监听。
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
如果某个端口确实正在监听80端口，那么防火墙规则可能会阻止这个stream量。 您可以通过在Web服务器上运行$ iptables --list来检查防火墙规则。
我不完全了解你如何testing这个，但是这是一个EC2实例吗？ 如果是这样，请确保它与其他服务器位于同一个“安全组”中，或者组中的策略允许端口80等。
你的行为不端的服务器和rpm.pbone.net之间的东西阻止你的行为exception的服务器发起的TCP连接以rpm.pbone.net端口80作为目的地。 罪犯可以是你自己的服务器， rpm.pbone.net本身，或者rpm.pbone.net任何路由器/防火墙。 而被阻塞的可能是连接build立数据包或其答复。
调查的第一步是找出谁阻止了stream量。 tcptraceroute rpm.pbone.net 80应该告诉你数据包可以走多远。
它可能会也可能不会帮助你运行tcpdump并且当你开始一个到80端口的外出连接时，看看你的SYN数据包是否得到某种types的回复（ACK，ICMP，或者其他更奇怪的东西）。