- PR -

プロバイダによって、HP閲覧可能/不可能

1
投稿者投稿内容
crahadoll
常連さん
会議室デビュー日: 2005/01/20
投稿数: 45
投稿日時: 2005-09-13 09:29
おはようございます。

自宅にapache2.0を利用しwebサーバを立てまして、
HPを公開しています。
(OSはredhat9)
プロバイダはybbです。
プロバイダの対抗先がybbの場合、
インターネットを通してHPの閲覧が可能なのですが、
ybb以外のプロバイダの場合、
HPを閲覧できるプロバイダもあれば、
閲覧できないプロバイダもあります。

最初、apacheの問題かと思い、
configの設定等を見直したのですが、
特にそのような制限は設けていなかったため、
原因は特定できませんでした。
当時は、緊急性もないのでそのまま放っておいたのですが、
先日oracleのisqlplusを使用したところ、
isqlplusの使用ポート：5500でも同現象
(webブラウザよりhttp://***.***.***.***:5500/isqlplus/にてアクセスします。)
プロバイダによって、接続できたり接続できなかったりする。
が発生している状況を知るに至りました。

これで、原因がapacheではないと特定されたのですが、
なぜ？プロバイダによってアクセスできたり、
できなかったりするのかの判断がつきません。

自宅のルータ(corega bar4p pro)側のセキュリティはすべて外しております。

原因等おわかりになられる方おりましたら、
教えてください。
よろしくお願いします。
ｔｒｙ
常連さん
会議室デビュー日: 2004/10/22
投稿数: 38
お住まい・勤務地: 神奈川/東京
投稿日時: 2005-09-13 09:56
とりあえず思いついたことを・・・。
以下の部分の確認をしてください。

１．閲覧できない時はどんなログが出ますか？
　　(access_logやerror_logなど）

２．TCPdumpなどでキャプチャーしパケットが届いているのか

３．サーバに変なルーティングがされていませんか？
　　
綾瀬
ぬし
会議室デビュー日: 2002/07/31
投稿数: 393
お住まい・勤務地: どっちも3階
投稿日時: 2005-09-13 10:12
こんにちは。

閲覧できない場合はブラウザにエラーなどが出るのでしょうか。
それとも、中途半端に表示されて「完全な」閲覧ができないのでしょうか。
具体的な症状を書いてもらえると、他の方にも何が起きているのか判りやすいと思いますよ。
また、ｔｒｙさんも書いてますがサーバ側のログには何か残ってますでしょうか。
これらがある程度把握できれば、例えば

1.サーバにはアクセスした形跡があるが、クライアントでは
　エラーが出て見れない
2.サーバにはアクセスした形跡があるが、クライアントでは
　中途半端に表示される(テキストのみ表示され、画像が表示されないなど)
3.サーバにもアクセスした形跡がない

などというように、具体的に何処で引っかかってるのかある程度の
切り分けができると思います。

さて、見れたり見れなかったりする場合で私がすぐに思いつくのは
Path MTU Discovery関連ですかね。
これがどういうものなのかや、該当する場合の対処法などは検索するとすぐに
出てくると思いますので、まずは試してみてはいかがでしょうか。

[ メッセージ編集済み 編集者: 綾瀬 編集日時 2005-09-13 10:24 ]
crahadoll
常連さん
会議室デビュー日: 2005/01/20
投稿数: 45
投稿日時: 2005-09-14 16:10
綾瀬さんに教えて頂きました、
Path MTU Discovery Black Holeが原因でした。
現在私の使用しているルーター「Corega BAR SW-4P Pro」のMTU値は、
MAXの1500に設定されているのですが、
OCNのMTU値が1454であるため、ルータ側で設定されている
MTUの値(1500)未満の判別が認識できず、
データが届かなかったという次第です。
ルータ側にてこのMTUの値を1454に変更したところ、
問題なく、HPを閲覧することができるようになりました。
どうもありがとうございました。
炭鉱
会議室デビュー日: 2005/01/07
投稿数: 18
投稿日時: 2005-09-16 20:22
現在修行中のものです。
非常に関心のある話題ですので、
便乗で質問させていただいてよろしいでしょうか？

まず１点目。
crahadollさんの選択された、Corega BAR SW-4P ProのMTUを1454にするよりも
サーバーの稼動しているマシンのMTUを、そうしたほうがいいように思いますが、
いかがでしょうか？（ルーターで分割するのは効率が悪く思えます）

２点目ですが、この通信の一連の流れを
・クライアントよりTCPコネクション要求
・セットされたMSSにより、サーバーとの間でMTU1500にてコネクション確立
・サーバー側からのIPヘッダにはDFビットが立っている
・Corega BAR SW-4P ProもMTU1500なのでそのまま通過
・経路上のどこか（おそらくPPPoE終端ルータ）で破棄される
・しかしブラックホールでICMPパケット分割要求メッセージが帰ってこず、通信が切断

・そこでCorega BAR SW-4P ProのMTUを1454にセットしなおす
・クライアントとサーバー間でMTU1500でTCPコネクションが確立する（DFビットON）が
・Corega BAR SW-4P Proがサーバー機に対してICMPパケット分割要求メッセージを送信
・サーバー側がこのコネクションのDFビットをオフにすることで通信が可能になる

・・・という理解でよろしいのでしょうか？
それともDFビットって、途中のNATルーターやフィルタ機などで書き換えられているんでしょうか？
（WEBサーバーでDFビットが立つ設定のメリットも想像できないんですが・・・）
cn009
ベテラン
会議室デビュー日: 2004/05/13
投稿数: 72
投稿日時: 2005-09-17 01:57
同じく修行中の者です。

引用:

crahadollさんの選択された、Corega BAR SW-4P ProのMTUを1454にするよりも
サーバーの稼動しているマシンのMTUを、そうしたほうがいいように思いますが、
いかがでしょうか？（ルーターで分割するのは効率が悪く思えます）

サーバのMTUが1500とかだと、無駄な処理が発生しますね。
多分パケットにDFがセットされていて、ICMPエラーが返ってきて、
パケットサイズを小さくして送りなおす、となると思います。
# Linuxでは /proc/sys/net/ipv4/ip_no_pmtu_disc で設定できるみたいです
# デフォルトは0（Path MTU Discovery を無効にしない ＝ 使う）らしいです

サーバマシンへのIPアドレスの割り当てが固定なのかDHCPなのかが書かれてないですが、
DHCPだとオプションでMTUを通知できるらしいので、もしかするとサーバマシンのMTUも1454になっているかもしれません。

また、プロバイダがybbなのでサーバ側はMTUが1500でも大丈夫なはずです。
MTUの問題なら、クライアント側の設定が間違っている可能性が高いと思います。
でも、ネットワークの末端（PPPoE等）ではない部分でMTUが小さくなっている場合は
どうするのが良いんでしょうかね。

ただ、利用者に知識が無くて、MTUの設定をしてもらえない場合は
大手の接続サービスで最もMTUサイズの小さいと思われるフレッツ・シリーズの
MTUサイズの1454等にサーバ側を設定してしまうのもありかもしれませんね。
# ダイヤルアップだとかなり小さかったかな
# でも正しいMTUの値が通知されて自動的にセットされるはず・・・

2点目の質問は@ITさんの「ネットワークの設定は正しいか？」をどうぞ。

引用:

それともDFビットって、途中のNATルーターやフィルタ機などで書き換えられているんでしょうか？
（WEBサーバーでDFビットが立つ設定のメリットも想像できないんですが・・・）

DFビットをオンに書き換えると、ICMPのエラーが返ってきた場合の処理が大変なのでやらないと思います。
DFビットをオフに書き換えると、送信元が Path MTU Discovery に対応しているのに、
わざわざ途中のルータで分割させたりすることになり、非効率なのでやらないと思います。

Webサーバ上でDFビットをオンにする理由はやはり転送の効率アップだと思います。
IPパケットの分割はそのルータの負荷が増えますし、そこから先のルータでも処理するパケットの数が増えるので負荷が増えます。
また、あて先のマシンでIPパケットの再構築が必要なのでそこでも負荷が増えます。

それにIPパケットが分割された場合、途中のFWやパケットフィルタ、PFW等で廃棄される可能性もあります。
確か（昔の？）ノートン・インターネット・セキュリティのデフォルト設定はそうでした。
1

スキルアップ／キャリアアップ（JOB@IT）