移転中~VPN環境で閲覧できないWEBサイトの原因は、MTU...YAMAHAのRTX1200でVPNを組みました。構成としては以下のようなスター型のネットワークで、外部へのインターネットもセンター側を経由して行くようにしています。拠点側から一部のWEBサイトが見えないという問合せがありました。Microsoftのサイト(htt://www.microsoft.com/)とか、借りている一部のレンタルサーバ上のWEBとかです。IEで見ると、ずっと接続に行ってるような感じですが、何も表示されず最終的にタイムアウトしてしまっているようです。Googleとかは普通に表示されまし、センター側の端末も何も問題なく表示されます。使ってパケットをキャプチャして見ました。閲覧できないレンタルサーバ上(IP:xxx.xxx.xx.xxx)に、数キロバイトのHTMLを置きそれにアクセスした時の状態です。Retransmission]が大量に出ていますね。Retransmissionは再送要求をしているようです。時間内にサーバからパケットが来なかったので要求してると思われます。フラグつまり、TCP接続を中断したというメッセージが来ています。(TCPのフラグの意味は@IT:TCPパケットの構造を参照)で、今度は別の閲覧可能なレンタルサーバ上(IP:xxx.xx.xx.xxx)に、同じく数キロバイトのHTMLを置きそれにアクセスした時は以下のようになりました。PDU]が発生してますが、これはセグメントが分割されて送ってきたよというメッセージのようです。(分割には、IPレベルで分割というかフラグメントする方法がありますが、これはそれではありません。IPレベルで分割されると、ルータがパケットを分割するためスループットが非常に悪くなります。PDU]は大きなデータを送受信するときは必ず発生します。通信では1回の転送で送信できるデータの最大値(MTU)が決まっていますが、アプリケーション側からみた1回のデータの送信はMTU(IPパケット全体の長さ)やMSS(IPパケット内のデータ部分の長さ)を考えないからです。PDU]で送られてきたパケットを結合してアプリケーション側に渡していると思われます。このことから、この分割は普通、アプリケーションから送るデータがMSSを超えている場合に起こることがわかります。サーバとクライアントはどのように分割するサイズ、つまりMSSを知るのでしょうか。TCPではコネクションを確立する3wayハンドシェイクで、お互いのMSSを通知し合って、値が小さい方を採用するようです。上記の閲覧できたレンタルサーバのパケットキャプチャを見ると、以下のようになっていることがわかります。今回問題となっていたのはVPN内のMTUです。@IT:pingでMTUサイズを調査するを参考にして、センター側と拠点間のMTUサイズを測って見ました。set."エラーが出てしまいました。1253以上のパケットになるとIPフラグメントするわけですね。-fなのでこのVPNルータ間のMTUは以下の計算によると、1280Byteのようです。1252+8(ICMPヘッダ)+20(IPヘッダ)=1280(MTU)(1280なのはヤマハのRTXルータでVPN組んだ時のデフォルト値のようです。本当はもっと大きい値でも問題なさそうな気がするのですが。)IP,TCPのヘッダはそれぞれ20Byteなので、このVPNルータ間のMSSは以下のように1240Byteになります。Coede4を送信元ホストに送信し、ホストはそれによりパケットサイズを調整して再送という段取りをとるようです。Discovery(経路MTU検索)と言うようです。DFビットが設定されていないと、ルータはフラグメントを行なってパケットを送信するようです。(スループットは落ちます)しかし、送信元に「パケットでかいから小さくしてよ」というICMPパケットがFWなどによって遮断されるとどうなるでしょうか。パケットを送り、パケットが届かねぇから通信辞めると捨て台詞を吐いてるようです。MSのサイトを始め幾つかのサイトが見れなかったのはこれが原因だと思います。書き換えてみたところ、閲覧出来なかったサイトも見れるようになりました。ルーターの問題をトラブルシュートする方法の方法3に有るように、以下の手順を行います。クリックして開きます。タブをクリックします。エントリが表示された場合、その接続がインターネット接続に使用されているネットワーク接続であると考えられます。