web-dev-qa-db-ja.com

CentOSLinuxでのTCP再送信、重複など）に関する問題

Vyattaゲート​​ウェイを実行しています。背後にはCentOS Linuxがあり、前面にはIPSecトンネルがあります。

セットアップを表示しようとしています：

PARTNER-NETWORK <--- IPSec (GRE, MTU 1420) ---> VYATTA (TUNNEL, MTU 1420 <> eth0, MTU 1500) <---> CentOS (eth0, MTU 1500) <---> internet (eth0, MTU 1500)

私はたくさん見ますTCP再送信、重複など、それは異なるMTU/MSSのためだと思います-デバッグするのは難しいです:(

CentOSに以下を追加しようとしました：

iptables -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

しかし、それでは問題は解決しないようです。

問題が正確にどこにあるか、および問題を解決する方法についてのアイデアをデバッグするにはどうすればよいですか？

centosiptablesmtuvyatta
1
Alfred Balle

ゲートウェイから両方のエンドポイントへのICMPタイプ3コード4（つまり、断片化が必要）メッセージを許可していますか？そして、エンドポイントは実際にそれらを受信して​​いますか？

Windows 95以降、事実上すべてのオペレーティングシステムでPath MTUDiscoveryが使用されています。実際には、これは、Do n'tFragmentフラグが設定されたすべてのTCPパケットを送信することを意味します。パケットがパケットのルート内の一部のホップのMTUよりも大きいことが判明した場合、問題が発生したルーターは、ICMPメッセージ「FragmentationNeeded」を送信者に送り返すことになっています。そのメッセージから、送信者はそのホップの正確なMTUを認識し、それに応じてパケットのサイズを変更することを認識します。その結果、エンドポイントは最終的には、ルーターがパケットをフラグメント化する必要がまったくないようにパケットのサイズを決定します。これにより、パフォーマンスが向上します。

ただし、誰かが「Fragmentation Needed」ICMPメッセージをブロックしている場合、Path MTUDiscoveryメカニズムは機能しません。受信者は、パケットのルート上の特定のホップのMTUよりも大きいパケットを取得することはないため、受信者はそれを確認しません。送信者は、パケットが確認応答されていないことを確認すると、そのパケットを再送信します。この特定の接続ではMTUを減らす必要があるという手がかりがないため、送信者はパケットをそのまま再送信します。 1ホップには大きすぎます。したがって、この場合、再送は役に立ちません。

1
telcoM