パスMTUディスカバリーブラックホールに関するいくつかの言葉

パスMTUディスカバリーブラックホールに関するいくつかの言葉

参加する代わりに

真のシステム管理者（またはそのように振る舞う管理者）ごとに1回、真実の瞬間が訪れます。 彼には、GNU / Linuxがインストールされているコンピューターでルーターを構成する運命があります。 すでにこれに合格している人は、これに複雑なものは何もないこと、そしていくつかのチームに会うことが可能であることを知っています。 そして今、私たちの管理者はこれらのコマンドを見つけてコンソールに送り、誇らしげにすべてがすでに機能していることをユーザーに伝えます。 しかし、それはありました-ユーザーは自分のお気に入りのサイトが開かないと言います。 彼の人生の一部を詳細の解明に費やした後、ほとんどのサイトは次のように動作することがわかりました。

1.ページを開くと、タイトルがロードされ、それ以上は何もありません。

2.この状態では、ページは無期限にハングします。

3.ブラウザのステータスバーは常に、ページがロードされていることを示します。

4.このサイトへのPingとトレースは問題ありません。

5.ポート80へのtelnet接続も正常に機能します。

がっかりした管理者がプロバイダーのテクニカルサポートに電話しますが、すぐにそれを取り除き、Windows OSでルーターを設定するようアドバイスし、そこで動作しない場合はハードウェアルーターを購入します。

この状況は多くの人によく知られていると思います。 自分自身に陥った人もいれば、彼女と友達になった人もいれば、フォーラムや他の会議でそのような管理者に会った人もいました。 だから：もしあなたがそのような状況にあるなら、おめでとうございます！ あなたはブラックホールを発見するパスMTUに直面しています。 この記事は、この問題が発生する理由とこの問題を解決する方法について説明しています。

記事を理解するために必要な用語。

MTU（Maximum Transmission Unit） -この用語は、OSIネットワークモデルのデータリンク層で送信できる最大パケットサイズ（バイト単位）を決定するために使用されます。 イーサネットの場合、これは1500バイトです。 より大きなパケットが到着した場合（たとえば、トークンリングを介して）、データはMTU以下（つまり1,500バイト以下）のパケットに再構成されます。 別のMTUでのパケットの再構築の操作はフラグメンテーションと呼ばれ、ルーターにとっては高価です。

PMTU（パスMTU） -このパラメーターは、ソースとレシーバー間のMTUデータチャネルの中で最小のMTUを示します。

PMTUディスカバリーは、ルーターの負荷を軽減するために設計されたPMTUディスカバリーテクノロジーです。 1988年にRFC 1191で説明されています 。 このテクノロジーの本質は、2つのホストが接続されると、DF（フラグメント化しない）パラメーターが設定され、パケットの断片化が防止されることです。 これにより、MTUがパケットサイズよりも小さいノードは、パケットの送信を拒否し、Destination is unreachableタイプのICMPメッセージを送信します。 エラーメッセージには、ノードのMTU値が伴います。 送信ホストはパケットサイズを縮小し、再送信します。 このような操作は、パケットが断片化せずに宛先ホストに到達するのに十分小さくなるまで発生します。

MSS（Maximum Segment Size） -最大セグメントサイズ、すなわち TCPが接続のリモートのもう一方の端に送信するデータの最大チャンク。 次の式で計算されます。

インターフェースMTU-Header_IP_Size（20バイト）-Header_TCP_Size（20バイト）。 合計は通常1460バイトです。 接続が確立されると、各サイドは独自のMSSを宣言できます。 最小値が選択されます。 詳細はこちらをご覧ください 。

フラグDF（フラグメント化しない） -IPパケットヘッダーのフラグフィールド内のビット。1に設定されている場合、このパケットのフラグメント化が許可されていないことを示します。 このようなフラグを持つパケットが次の転送のMTUよりも大きい場合、このパケットは破棄され、送信者にICMPエラーが送信されます：「断片化が必要ですが、ビットフラグメントが設定されていません」

試験場

この問題は実際には最もよく知っています（ただし、上司が耳の上で叫ぶときのトラブルではありません）。 これを行うために、図1に示すテストネットワークを作成しました。





図 1.テストネットワーク。



これは、グローバルネットワークの簡易バージョンです。 役割

1. deb-serv-03という名前のコンピューターがLinuxルーターです。 重要 -eth2インターフェースでは、MTUサイズが1400バイトに削減されました。

2. deb-serv-05-ローカルネットワーク上のクライアント。

3. deb-home-プロバイダーにあるルーター。

4. deb-serv-データを交換するインターネット上のWebサーバー。 www.site.localから、 そこにあるサイズ5.9Kbのページを取得します。

もちろん、実際にはチェーンははるかに大きくなりますが、実例としてはこれで十分です。 このネットワーク上のすべてのコンピューターは、Debian GNU / Linux 5.0 Lennyを実行しています。 ネットワークのさまざまなポイントで、tcpdumpプログラムを使用して状況を制御します。

PMTUの通常の検出

まず、ページを開いたときにネットワーク上で何が起こるかを見てみましょう。 Webサーバーからのパッケージの行き方を学びます。 TCPDUMP＃1の出力を見ます（eth0 deb-servで）：



1 IP 172.16.5.3.48547 > 192.168.0.1.80: Flags [S], seq 2947128725, win 5840, options [mss 1460...], length 0

2 IP 192.168.0.1.80 > 172.16.5.3.48547: Flags [S.], seq 757312786, ack 2947128726, win 5792, options [mss 1460...], length 0

3 IP 172.16.5.3.48547 > 192.168.0.1.80: Flags [.], ack 1, win 1460, options [...], length 0

4 IP 172.16.5.3.48547 > 192.168.0.1.80: Flags [P.], seq 1:118, ack 1, win 1460, options [...], length 117

5 IP 192.168.0.1.80 > 172.16.5.3.48547: Flags [.], ack 118, win 181, options [...], length 0

6 IP 192.168.0.1.80 > 172.16.5.3.48547: Flags [.], seq 1:2897, ack 118, win 181, options [...], length 2896

7 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556

8 IP 192.168.0.1.80 > 172.16.5.3.48547: Flags [.], seq 1:1349, ack 118, win 181, options [...], length 1348

9 IP 192.168.0.1.80 > 172.16.5.3.48547: Flags [.], seq 1349:2697, ack 118, win 181, options [...], length 1348

10 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556







最初の10個のパッケージのみを提供し、標準のtcpdump出力の余分な部分をすべて切り捨てます。 解析：

1. 1行目から3行目には、tcp接続のセットアップが表示されます。 当事者はSYN、SYN-ACK、ACKパケットを交換します。 ここでは、オプションフィールド、つまり当事者間で交換されるMSSパラメータに注意する価値があります。 両側で1460バイトです。 つまり、当事者が互いに送信するパケットの最大サイズは、1460（MSS）+20（TCPヘッダー）+20（IPヘッダー）= 1500バイトです。

2. 4行目で、deb-serv-05からWebページのリクエストを送信します。 行5は、このパッケージの受領を確認します。

3. 6行目では、要求に対する応答の送信（つまり、Webページの一部の送信）を確認します。 おそらくこのインターフェイスのpcapの特性により、tcpdumpはサイズが2948バイトのパケットを1つ認識しますが、サイズが1500および1452バイトのパケット2つはそれぞれネットワークに送信されます。 tcpdumpのより詳細な出力を見ると、DFフラグがこのパッケージ（またはパッケージ）にあることがわかります。

IP (tos 0x0, ttl 64, id 5177, offset 0, flags [DF], proto TCP (6), length 2948)

192.168.0.1.80 > 172.16.5.3.48547: Flags [.], seq 1:2897, ack 118, win 181, options [nop,nop,TS val 86620459 ecr 4922429], length 2896





4.これらのデータパケットがdeb-serv-03に到達すると、MTU 1400との接続を通過できずフラグメント化できないため（DFフラグ）、ICMPメッセージタイプ3コード4が生成されるため、 破棄されます： ICMP 172.16 .5.3到達不能-フラグメント化する必要があります（mtu 1400） 。これは7行目で見られます（10行目では、2番目のパッケージにメッセージが来ます）。 このメッセージは、目的のMTUを送信します。

5. 8行目と9行目では、MTU = 1400を受信したdeb-servが、Webページの同じ部分を1400バイトのサイズのパケットで送信する方法を観察します。 これらのパケットは、ページ全体が転送されるまで確認が生成されるdeb-serv-05に到達します。 後続のすべてのパケットのサイズは1400バイト以下です。

この例は、RCF1911で説明されているトランスポートMTU決定手順（PMTU）を示しています。 図2に簡略化して示しました。





図2. PMTUを決定する手順。

Path MTU Discoveryブラックホールとのミーティング

次に、新しい専門家がプロバイダーに来て、現在担当しているdeb-homeを介したicmpパケットの送信を禁止する（たとえば、icmpフラッドから保護する）ことを決めたとします。 何が起こるか見てみましょう：

TCPDUMP＃1出力（eth0 deb-servで）：



1 IP 172.16.5.3.57925 > 192.168.0.1.80: Flags [S], seq 1723325723, win 5840, options [mss 1460...], length 0

2 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [S.], seq 2482933888, ack 1723325724, win 5792, options [mss 1460...], length 0

3 IP 172.16.5.3.57925 > 192.168.0.1.80: Flags [.], ack 1, win 1460, options [...], length 0

4 IP 172.16.5.3.57925 > 192.168.0.1.80: Flags [P.], seq 1:118, ack 1, win 1460, options [...], length 117

5 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], ack 118, win 181, options [...], length 0

6 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:2897, ack 118, win 181, options [...], length 2896

7 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [...], length 1448

8 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [...], length 1448

9 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [...], length 1448

10 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [...], length 1448







TCPDUMP＃2出力（eth0 deb-serv-03上）：



1 IP 172.16.5.3.57925 > 192.168.0.1.80: Flags [S], seq 1723325723, win 5840, options [mss 1460...], length 0

2 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [S.], seq 2482933888, ack 1723325724, win 5792, options [mss 1460...], length 0

3 IP 172.16.5.3.57925 > 192.168.0.1.80: Flags [.], ack 1, win 1460, options [...], length 0

4 IP 172.16.5.3.57925 > 192.168.0.1.80: Flags [P.], seq 1:118, ack 1, win 1460, options [...], length 117

5 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], ack 118, win 181, options [...], length 0

6 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [...], length 1448

7 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556

8 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1449:2897, ack 118, win 181, options [...], length 1448

9 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556

10 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [...], length 1448

11 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556

12 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [...], length 1448

13 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556

14 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [...], length 1448

15 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556

16 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [...], length 1448

17 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556

18 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [...], length 1448

19 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556

20 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [...], length 1448







ご覧のとおり、状況はかなり予想されます。 各出力の最初の6行は、通常の転送の場合とまったく同じです（前の例の説明を参照）。 しかし、その後、矛盾が始まります。 ICMP 3：4はdeb-serv-03（TCPDUMP＃2の行7、9 11.13、15、17、19）で同じ方法で生成されますが、deb-servはそれを受信せず、サイズが1500バイトのパケットを送信し続けます（ TCPDUMP＃1の6〜12およびTCPDUMP＃2の6、8、10、12、14、16、18、20。 毎回、再送信の間隔が長くなります（これらの例では、タイムスタンプを削除しましたが、TCP再送信メカニズムは実際にこのように機能します）。 この場合、PMTUを超えるデータは送信できません。 しかし、残念ながら、TCPはこれを認識せず、接続が確立されたときに選択されたMSSでパケットを送信し続けます。 この状況は、 パスMTUディスカバリブラックホール （トランスポートMTUの定義におけるブラックホール ）と呼ばれます。 私はそれを簡略化した形で図に示しようとしました。 3。





図 3. PMTUの定義におけるブラックホール。



この問題はまったく新しいものではありません。 2000年のRFC 2923に記載されています 。 それにもかかわらず、それは多くのプロバイダーの間でうらやましい粘り強さを満たし続けています。 しかし、この状況を責めるのはプロバイダーです。ICMPタイプ3コード4をブロックする必要はありません。さらに、通常、「理由の声」（つまり、問題が何であるかを理解しているクライアント）を聞きたくありません。

PMTU問題の解決

テクニカルサポートに電話することはありませんが、私たちの資金に基づいて問題の解決に努めます。

それについても知っているLinux開発者は、iptablesに特別なオプションを提供しています。 男iptablesからの引用：



TCPMSS

This target allows to alter the MSS value of TCP SYN packets, to control the maximum size for that connection (usually limiting it to your outgoing interface's MTU minus 40 for IPv4 or 60 for IPv6, respectively). Of course, it can only be used in conjunction with -p tcp. It is only valid in the mangle table. This target is used to overcome criminally braindead ISPs or servers which block "ICMP Fragmentation Needed" or "ICMPv6 Packet Too Big" packets. The symptoms of this problem are that everything works fine from your Linux firewall/router, but machines behind it can never exchange large packets:

1) Web browsers connect, then hang with no data received.

2) Small mail works fine, but large emails hang.

3) ssh works fine, but scp hangs after initial handshaking.

Workaround: activate this option and add a rule to your firewall configuration like:

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \

-j TCPMSS --clamp-mss-to-pmtu



--set-mss value

Explicitly set MSS option to specified value.



--clamp-mss-to-pmtu

Automatically clamp MSS value to (path_MTU - 40 for IPv4; -60 for IPv6).



These options are mutually exclusive.







英語が苦手な人のための私の無料翻訳：



TCPMSS

MSS TCP SYN , ( MTU 40 IPv4 60 IPv6). , -p tcp. mangle. , "ICMP Fragmentation Needed" "ICMPv6 Packet Too Big" . – , :

1) , .

2) , .

3) ssh , scp ( : TCP " ").

: , , :

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \

-j TCPMSS --clamp-mss-to-pmtu



--set-mss

MSS .



--clamp-mss-to-pmtu

MSS (path_MTU - 40 IPv4; -60 IPv6).

.





ご覧のとおり、彼らは多くのことを書き、おおよその問題の症状を説明しさえしました。 そして、プロバイダーのこの行動は「犯罪的無能（犯罪的脳死）」と呼ばれ、私はそれらに完全に同意します。 このオプションがこの例でどのように機能するかを見てみましょう。 推奨ルールをdeb-serv-03に追加します。

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN、RST SYN -j TCPMSS –set-mss 1360

そして何が起こったのか見てください：

TCPDUMP＃1出力（eth0 deb-servで）：



1 IP 172.16.5.3.33792 > 192.168.0.1.80: flags [s], seq 1484543117, win 5840, options [mss 1360...], length 0

2 IP 192.168.0.1.80 > 172.16.5.3.33792: flags [s.], seq 2230206317, ack 1484543118, win 5792, options [mss 1460...], length 0

3 IP 172.16.5.3.33792 > 192.168.0.1.80: flags [.], ack 1, win 1460, options [...], length 0

4 IP 172.16.5.3.33792 > 192.168.0.1.80: flags [p.], seq 1:118, ack 1, win 1460, options [...], length 117

5 IP 192.168.0.1.80 > 172.16.5.3.33792: flags [.], ack 118, win 181, options [...], length 0

6 IP 192.168.0.1.80 > 172.16.5.3.33792: flags [.], seq 1:2697, ack 118, win 181, options [...], length 2696

7 IP 172.16.5.3.33792 > 192.168.0.1.80: flags [.], ack 1349, win 2184, options [...], length 0

8 IP 192.168.0.1.80 > 172.16.5.3.33792: flags [.], seq 2697:5393, ack 118, win 181, options [...], length 2696

9 IP 192.168.0.1.80 > 172.16.5.3.33792: flags [fp.], seq 5393:6380, ack 118, win 181, options [...], length 987

10 IP 172.16.5.3.33792 > 192.168.0.1.80: flags [.], ack 2697, win 2908, options [...], length 0







TCPDUMP＃3出力（eth0 deb-serv-05上）：



1 IP 172.16.5.3.33792 > 192.168.0.1.80: Flags [S], seq 1484543117, win 5840, options [mss 1460...], length 0

2 IP 192.168.0.1.80 > 172.16.5.3.33792: Flags [S.], seq 2230206317, ack 1484543118, win 5792, options [mss 1360...], length 0

3 IP 172.16.5.3.33792 > 192.168.0.1.80: Flags [.], ack 1, win 1460, options [...], length 0

4 IP 172.16.5.3.33792 > 192.168.0.1.80: Flags [P.], seq 1:118, ack 1, win 1460, options [...], length 117

5 IP 192.168.0.1.80 > 172.16.5.3.33792: Flags [.], ack 118, win 181, options [...], length 0

6 IP 192.168.0.1.80 > 172.16.5.3.33792: Flags [.], seq 1:1349, ack 118, win 181, options [...], length 1348

7 IP 192.168.0.1.80 > 172.16.5.3.33792: Flags [.], seq 1349:2697, ack 118, win 181, options [...], length 1348

8 IP 172.16.5.3.33792 > 192.168.0.1.80: Flags [.], ack 1349, win 2184, options [...], length 0

9 IP 172.16.5.3.33792 > 192.168.0.1.80: Flags [.], ack 2697, win 2908, options [...], length 0

10 IP 192.168.0.1.80 > 172.16.5.3.33792: Flags [.], seq 2697:4045, ack 118, win 181, options [...], length 1348







解析：

1. 1〜3行目では、すでにTCP接続を監視することに慣れています。 ただし、MSS値に注意してください。 TCPDUMP＃1では、deb-serv-05は値1360を受け取りますが、TCDUMP＃3では、MSS = 1460のパケットが送信されていることがわかります。 これは、ルールが–set-mss 1360でどのように機能するかを示しています。通過するパケットのMSS値を編集します。 戻ってきたSYNパケットの場合、この値も編集されます。

2.両方の結論の4行目と5行目で、GETリクエストの送信と受信の確認を確認します。

3. TCPDUMP＃1の6行目とTCPDUMP＃3の6行目と7行目では、データを含むパケットを送信していますが、各パケットのサイズは1400バイトを超えていません。 繰り返しになりますが、TCPDUMP＃1では1つの大きなパケットが表示されますが、TCPDUMP＃3では2つのパケットの到着が見られます。

4.さらにパケット交換は、TCPプロトコルのルールに従います。 ただし、パケットサイズが1400バイトを超えることはありません。



簡略化した形式で、MSSの動作を図に示します。 4.通常の動作に似ているため、データ交換は表示しませんでした。



図 4. MSSをその場で変更します。



man iptablesには2つのオプションが記載されていますが、これまでのところ1つしか適用していません。 必要なオプションは、特定の状況によって異なります。 すべての状況は2つのタイプに分類できます。



1.ルーターでサイトが正常に開き、ローカルネットワーク上のクライアントで問題が発生します。

この場合、パス全体に沿った最小のMTUはサーバー上にあります。 通常、これらはPPPoE、PPtPなどのいくつかのカプセル化プロトコルです。 この状況に最適なオプションは-clamp-mss-to-pmtuです。これは、すべての通過パケットの最小MSSを自動的に設定します。



2.ローカルネットワーク上のルーターとクライアントでは、サイトは開かれません。

この場合、最小のMTUはプロバイダーのどこかにあり、標準的な方法で計算することは困難です。 特にこのために、私はこの状況に必要なMSSサイズを決定するのに役立つ小さなPythonスクリプトを作成しました（PEP8と足で撃つことができないことを本当に心配していません）：

 #!/usr/bin/env python # -*-coding: utf-8 -*- import socket import os import time import sys #        .    # ,    . HOST = 'www.site.local' #  ,        . #       ,  #  -    . TIMEOUT = 25.0 #  ,      ,     #  .      MTU BUF = 3000 #  MTU    . MTU = 1500 #  MSS      MTU-LIM-40  MTU-40.  #    MTU        # 100-200 -        . LIM = 100 #     .     #    . TRY_TIME = 0 def set_mss(mss, action='A'): return os.system("iptables -t mangle -%s OUTPUT -p tcp --tcp-flags \ SYN,RST SYN -j TCPMSS --set-mss %d" % (action, mss) ) def check_connection(host): sock = socket.socket() sock.connect( (host, 80) ) sock.send('GET / HTTP/1.1\r\nHost: %s\r\n\r\n' % host) sock.settimeout(TIMEOUT) try: answer_size = len( sock.recv(BUF) ) except: answer_size = 0 sock.close() return answer_size def main(): mss = MTU - 40 if not check_connection(HOST): mss = MTU - 40 - LIM set_mss(mss) if not check_connection(HOST): set_mss(mss,'D') print "Error: Too small LIM" sys.exit(1) else: while check_connection(HOST): time.sleep(TRY_TIME) set_mss(mss,'D') if mss >= MTU-40: print "Error in determining MSS" sys.exit(1) mss += 1 set_mss(mss) set_mss(mss,'D') mss -= 1 print 'MSS = %d' % (mss) if __name__ == '__main__': main() sys.exit(0)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スーパーユーザー特権でスクリプトを実行する必要があります。 彼の仕事のアルゴリズムは次のとおりです。

1.通常のMSS値を持つサイトから一定量のデータを取得しようとしています。

2.これが機能しない場合は、iptables OUTPUTチェーンのMSSをMTU-40-LIMに下げます。

3.その後でもデータを取得できない場合、LIMが小さすぎるというエラーが表示されます。

4.一貫してMSSを増やし、データが到着しなくなる瞬間を探しています。 その後、MSSの最後の有効値を推定します。

5. MSS = MTU-40に到達すると、MSSを特定できないことを示すエラーが表示されます。 パラグラフ1で同様のチェックを実行し、結果が一致しない場合、これは考える機会であるため、この状況は誤りです。



目的のMSSを受け取ったら、対応するルールに入力する必要があります。 目でMSS値を下げることにより、スクリプトなしで実行できますが、確認することをお勧めします-パケットを送信するためのオーバーヘッドが少なくなります。



多くの場合、フォーラムでは、特定のインターフェースでMTUを下げるためのヒントを見つけることができます。 これは万能薬ではないことを理解する必要があり、結果は低くするインターフェイスによって異なります。 参加者のインターフェイスの1つでTCP接続を下げると、宣言されたMSSが最小パケットサイズに対応するため、効果があります。 ただし、これらがエンドポイントではなく、中継ルーターの1つであり、-clamp-mss-to-pmtuオプションが有効になっていない場合、効果はありません。



この記事が、自宅や友人や知人の両方で同様の問題を解決するのに役立つことを願っています。 もう一度、プロバイダーの専門家に頼ります-極端な要件はICMPタイプ3コード4をブロックしません-これは同僚に問題を引き起こします。