web-dev-qa-db-ja.com

この奇妙なMTUはどうなっているのでしょうか。

私のオフィスには、VPNを介してリモートサーバーと通信するサーバーマイクがあります。 MTUサイズに関連していると思われるさまざまな問題がありました。 MikeはRHEL3サーバーであり、カスタマーサーバーはCentOS 5です。tracepathツールを使用して最大MTUを見つけようとしましたが、この奇妙な結果が得られました。

[root@mike root]# tracepath 192.168.1.4
 1:  mike (192.168.100.1)                                  0.170ms pmtu 552
 1:  mike (192.168.100.1)                                  0.011ms pmtu 552
 1:  mike (192.168.100.1)                                  0.010ms pmtu 552

snip - thousands of lines of the same output

 1:  mike (192.168.100.1)                                  0.025ms pmtu 552
 1:  192.168.100.252 (192.168.100.252)                        0.405ms
 2:  192.168.100.253 (192.168.100.253)                        0.876ms
 3:  192.168.1.4 (192.168.1.4)                         97.1000ms reached
     Resume: pmtu 552 Hops 3 back 3

私たちのオフィスの別のサーバーから別の顧客へ私ははるかに合理的な見た目の結果を得る

[root@nora ~]# tracepath 192.168.2.1
 1:  nora (192.168.100.228)                                0.080ms pmtu 1500
 1:  192.168.100.253 (192.168.13.253)                      asymm  2   0.813ms
 2:  no reply
 3:  192.168.11.1 (192.168.11.1)                           73.210ms reached
     Resume: pmtu 1500 Hops 3 back 3

ですから、ルーター、ファイアウォール、VPNの間ではなく、マイクと関係があると思います。何か案は？

以下のダニエル・ローソンの答えに応えて、ノラは正しい応答を得ることができるので、問題はサーバーマイクであると私が信じる理由はここにあります

[root@nora ~]# tracepath 192.168.1.4
 1:  nora (192.168.100.228)                                0.101ms pmtu 1500
 1:  192.168.100.253 (192.168.100.253)                      asymm  2   0.863ms
 2:  no reply
 3:  192.168.1.4 (192.168.1.4)                        111.601ms reached
     Resume: pmtu 1500 Hops 3 back 3

Mike Penningtonのコメントに応えて、192.168.100.252と192.168.100.253はどちらもファイアウォールです。デフォルトゲートウェイは192.168.100.252であり、これらの顧客がトラフィックを192.168.100.253に送信するための静的ルートがあります。それらは同じネットワーク上にあるので、ホップカウントが増分されないのはそのためだと思います。

linuxvpnmtu
5
mmcg

あなたが言ったことから、サーバー「マイク」からある顧客へのパスは552に制限されており、「ノラ」から別の顧客への別のパスは制限されていません。

同じパスを比較しているわけではないので、より多くの情報がない限り、これがサーバー「マイク」に固有のものであるとは思えません。 PMTUはパスに沿った制約付きMTUであるため、これがマイクに固有である場合は、トレースパス先のすべてのマシンで発生するはずです。

VPN接続を使用していることを考えると、制約のあるPMTUが表示されていることはそれほど驚くことではありません。最初の顧客に対するVPN構成のMTU設定を確認し、顧客のVPNエンドポイント（VPNを終了するパブリックIPアドレスなど）に直接MTUを確認することも試みます。それらのいずれかがあなたの答えを持っている可能性があります。

4
Daniel Lawson

この問題は、ジュニパーがPMTUDの一部であるICMP到達不能パケットでMTU値を返さないことに関連していると思います。私は以前にジュニパーで同様の問題を見たことがあります

0
rocco

これは、ファイアウォールやさまざまなベンダーのVPNからは非常に一般的です。一部のタイプのトラフィックのMTUを1500未満に減らすためのチェックポイント。

0
Federico

Windowsマシンが手元にある場合は、mturouteをtracerouteモードで実行して、MTUが低いリンク/ホップを判別できます。

http://www.elifulkerson.com/projects/mturoute.php

0
joeqwerty