人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

Apacheにローカルホストからアクセスすると接続ができないトラブルが発生しています。
なお、サイトそのものは正常にアクセスできており、ブラウザ上でも表示が遅いなどはありません。

サーバはCentOS6で、Apache+PHP(5.3)でサービスは構成されております。

複数のサーバで同じ設定にしているのですが、なぜか1台だけが、サーバ自身からアクセスするとタイムアウトになってしまいます。

例えば・・・

wget http://example.com/
--2013-06-12 02:09:55-- http://example.com/
Resolving example.com... XXX.XXX.XXX.XXX
Connecting to example.com|XXX.XXX.XXX.XXX|:80... failed: Connection timed out.
Retrying.

--2013-06-12 02:10:17-- (try: 2) http://example.com/
Connecting to example.com|XXX.XXX.XXX.XXX|:80... failed: Connection timed out.
Retrying.

--2013-06-12 02:10:40-- (try: 3) http://example.com/
Connecting to example.com|XXX.XXX.XXX.XXX|:80... failed: Connection timed out.
Retrying.

このようになりアクセスできない状況です。

特にアクセス制限等はかけておらずどこから手を付ければいいか全くわからず困っております。

どうすればアクセス可能な状態にできるでしょうか。

●質問者: 匿名質問者
●カテゴリ:インターネット ウェブ制作
○ 状態 :終了
└ 回答数 : 1/1件

▽最新の回答へ

1 ● 匿名回答1号
ベストアンサー

Connecting to example.com|XXX.XXX.XXX.XXX|:80... failed: Connection timed out.


タイムアウトだと、この example.com の IP アドレスは本当に自ホストのアドレスを指しているか? という事を疑いたくなります。

もし、本当に自ホストのアドレスだったすると、仮に Apache 側の設定の問題等で、その IP アドレスで待ち受けしていない(例えば、127.0.0.1 のみで LISTEN している)というであれば Connection refused になるし、iptables の問題だとしても、CentOS の標準的な設定であれば icmp-host-prohibited で拒否するので、タイムアウトにはなりません。

とりあえず、example.com に対する名前解決はできているようですので、wget が表示している IP アドレスが自ホストのアドレスとあっているか、ping の応答はあるか、あるいは、環境変数に http_proxy や wgetrc ファイルで Proxy が設定されていないか、設定されていた場合、その proxy からこのホストに接続できるか、といった辺りを確認してみて下さい。


匿名質問者さんのコメント
ご回答ありがとうございます。 IPアドレスの方は数度確認しておりますが、間違いない状態です。 (つまりXXX.XXX.XXX.XXXは間違いなく、自身のグローバルアドレスです) また、Proxyの方はいずれも設定されていない状態を確認ずみです。 一方でPingについてですが、正常に表示されるサーバとされないサーバで違いがありました。 まず、前提条件としてpingは外部から受け付けない設定(iptablesにより)になっています。 その前提で「ping localhost」の場合、すべてのサーバで応答がありました。 一方で、「ping example.com」とした場合、wgetで正常に応答するサーバはpingが通り、 逆にwgetで応答の無いサーバはpingについても応答はありませんでした。 何れの場合も、pingの実行後ドメイン名の横に表示されるIPアドレスは正常に対象ドメインのグローバルIPが正しく表示されています。 (つまり自分自身のグローバルIPということです)

匿名質問者さんのコメント
上記の現象から、合わせてtracerouteも実行しました。 「traceroute localhost」の場合、いずれのサーバは1度目に自身のサーバが表示され正常に終了しました。 「tracert example.com」の場合、wgetに応答のあるサーバは1度目に自信のサーバが表示されますが、一方でwgetに応答の無いサーバは延々と*のルートが表示され終了しました。 proxyの設定はないのですが、なぜか外部経由になっているようです・・・ 何れのサーバも仮想サーバなのですが、ホストの提供会社が異なる為何か違いがあるのでしょうか・・・

匿名回答1号さんのコメント
> 「tracert example.com」の場合、wgetに応答のあるサーバは1度目に自信のサーバが > 表示されますが、一方でwgetに応答の無いサーバは延々と*のルートが表示され > 終了しました。 ん、なにか特殊なルーティングをしている雰囲気...。 route コマンドを実行してみて、自ホストの IP を別にゲートウェイに送るような設定になっている、とか、あるいは iptables の nat テーブルや mangle テーブルに何か書かれているか。 ちなみに、iptables の nat テーブルや mangle テーブルの状態は、 iptables -L -v -t nat といった具合に、-t の後ろにテーブル名を指定すれば表示されます。

匿名質問者さんのコメント
追加でわかったことがあります。 前述したとおり、複数のサーバは異なるホスティング会社のサービス(仮想サーバ)を利用しているのですが、NGとなるサーバはインターフェースにローカルIPが指定されていることがわかりました。 ※おそらくVMwareをホストに利用しており、その内部ネットワーク用のアドレスと思われます。 つまり「inet addr:192.168.XXX.XXX」というような感じです。 (逆に正常に通る方は、グローバルIP自身が設定されていました)

匿名質問者さんのコメント
「iptables -L -v -t nat」の結果は、いずれのサーバも以下の通りでした。 Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 一見すると特に特殊な設定はないように感じますがいかがでしょうか。

匿名質問者さんのコメント
「iptables -L -v -t mangle」の結果も、何れも以下の通りでした。 Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination

匿名質問者さんのコメント
routeの内容は以下の通りでした。 正常なサーバ Destination Gateway Genmask Flags Metric Ref Use Iface (グローバルIP) * 255.255.254.0 U 0 0 0 eth0 link-local * 255.255.0.0 U 1002 0 0 eth0 default (グローバルIP) 0.0.0.0 UG 0 0 0 eth0 タイムアウトするサーバ Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.XXX.0 * 255.255.255.0 U 0 0 0 eth3 link-local * 255.255.0.0 U 1002 0 0 eth3 default 192.168.XXX.1 0.0.0.0 UG 0 0 0 eth3 やはり、設定内容が基盤の違いであるようです。 ただ、基盤にかかわる部分は変更できないのでどうすればよいものかと・・・

匿名回答1号さんのコメント
とりあえず、iptables はシロですね。 で、問題のホストは、OS としてはプライベートアドレスが割り当てられていて、それが、どこかのルータで NAT されている状態ですね。 これだと、結論としては「仕方がない」です。 このパターンはよくある話で、原理的に解決が難しいです。 例えば、仮にこのホストに割り当てられているプライベートアドレスを 192.168.1.1、NAT 後のグローバルアドレスを 1.2.3.4 として、このホストが 1.2.3.4 へパケットを送信すると、 ・宛先 1.2.3.4 のパケットをルータへ投げる。 ・ルータはこのパケットを宛先 192.168.1.1 へ変更して送信する。 ・これを受け取ったホスト(つまり、送信したホスト)から見ると 宛先:192.168.1.1、送信元 192.168.1.1 のパケットに見える。 ・このパケットに応答するパケットを送ろうとすると、自分の IP アドレス宛へ 送信する事になる。 ・このパケットがもし、TCP のパケットだとすれば、 送信した宛先は 1.2.3.4 戻ってきたパケットは 192.168.1.1 となるので、TCP のコネクションが成立しない。 (そもそも、前に送信したパケットの戻りだと認識できない) という動きになります。ポイントは、戻りのパケットが NAT の処理をするルータを介さず、自ホストに戻ることになる点です。同じ事は、自ホストだけでなく、同一セグメントの他のホストにも言えて、例えば、192.168.1.2 という別のホストから 1.2.3.4 へつなごうとしても繋がりません。 で、それでも example.com という名前でつながる必要がどうしてもあれば、/etc/hosts に 192.168.1.1 example.com と書いてしまうのが手っ取り早いです。

匿名質問者さんのコメント
ご回答ありがとうございます。 また詳しい説明助かりました。現状起きている現象を把握いたしました。 取り急ぎご助言いただいた内容で対応し解決いたしました。 細かい部分までご指示いただきまして助かりました。 本当にありがとうございました。
関連質問

●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ