Wget、Curl、Yum失敗しますが、Pingは機能します-CentOS 5
現在、3つのWebサーバーがあります。
サーバー1と2は動作しますが、3番目のサーバーで実際に問題が発生しています。
wget、curlおよびyumはすべて接続に失敗します。つまり、ホストを解決して接続を試みた後、すべてがハングします。
例（さまざまな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です）のすべてをブロックしている可能性があります。以下を確認してください。iptables -L ErikAが上で指摘したように。
ハードウェアファイアウォールの問題である可能性もあります-サーバーはCiscoファイアウォールの背後にありますか？ロケートシステム管理者に相談してください。他のマシンからカールできる場合は、：80が開いています。可能性は高いですが、可能性は低いですが、彼らがあなたをブロックしている可能性がありますが、何も（グーグルでさえ）カールできない場合は、あなたの側です。
まあ、pingはICMPを使用しますが、これらすべてのHTTPクライアントはTCPポート80を使用します。送信元と宛先の間でブロックされる可能性はありますか？
私の場合、問題は古いDNSキャッシュが原因でした。以下が役立ちました：
# service nscd restart
これをどのようにテストしようとしているのか完全に理解できませんが、これはEC2インスタンスですか？その場合は、他のサーバーと同じ「セキュリティグループ」にあること、またはグループ内のポリシーがポート80などを許可していることを確認してください。
誤動作しているサーバーとrpm.pbone.netの間の何かがブロックしていますTCP rpm.pbone.netポート80を宛先として、誤動作しているサーバーによって開始された接続。攻撃者はサーバー自体である可能性がありますrpm.pbone.net自体、またはその間のルーター/ファイアウォールそしてブロックされるのは、接続確立パケットまたはその応答である可能性があります。
調査の最初のステップは、トラフィックをブロックしている人物を特定することです。 tcptraceroute rpm.pbone.net 80は、パケットの到達距離を示します。
tcpdumpを実行して、ポート80への発信接続を開始するときに、SYNパケットに対してなんらかの応答（ACK、ICMP、または何か奇妙なもの）が返されるかどうかを確認すると役立つ場合とそうでない場合があります。
ポート80で何かがリッスンしていること、およびテストしているIPアドレスからポート80へのトラフィックをブロックするファイアウォールルールがないことを確認してください。
ポート80で何かがリッスンしているかどうかを確認するには、Webサーバー自体から次のコマンドを実行します。
$ netstat -lan | egrep LISTEN
出力で、このような行が表示された場合は、何かがポート80でリッスンしています。
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
何かisが実際にポート80でリッスンしている場合、ファイアウォールルールがトラフィックをブロックしている可能性があります。ファイアウォールルールを確認するには、ウェブサーバーで$ iptables --listを実行します。