Magic Transit はトラフィックを追加ヘッダーで包む（カプセル化する）ため、各パケットで元のデータに使える実効サイズが小さくなります。このオーバーヘッドを考慮しないと、パケットがネットワーク経路に対して大きすぎて破棄されたり、フラグメント化されたりします。その結果、性能低下や接続失敗につながります。このページでは、設定が必要な 2 つの値、最大伝送単位（MTU）と最大セグメントサイズ（MSS）を説明します。
最大伝送単位（MTU） ↗ は、ネットワークに接続したデバイスが受け取れる最大データパケットを表す値です。MTU はほぼ常に、ネットワーキングの OSI モデルのレイヤー 3 に適用され、Transmission Control Protocol（TCP）、Internet Protocol（IP）などのヘッダーと、データ（ペイロード）を含むパケット全体を対象にします。たとえば、インターネットを経由してルーティングするには、パケットは 1,500 バイトを超えてはいけません。
最大セグメントサイズ（MSS） ↗ は、1 つの TCP データグラムパケットで送れるデータ量を指します。この値は、MTU から IP ヘッダーと TCP ヘッダーのサイズを引いて決め、ルーターにペイロードの上限を伝えます。OSI モデルのレイヤー 4 に適用されます。
MSS / MTU についてよくある誤解は、これらの値を設定すると性能が悪化するというものです。わずかな性能低下はありますが、ネットワークの特性を踏まえずに設定しないほうが悪影響は大きくなります。
Magic Transit はサービス提供にカプセル化を使うため、この場合に MTU と MSS が重要な理由も押さえておく必要があります。
カプセル化では、Cloudflare がすべてのパケットに新しい IP ヘッダーと（多くの場合）何らかのカプセル化ヘッダーを付けるため、パケットにバイトが追加されます。たとえば、Internet Protocol version 4（IPv4）向けの Generic Routing Encapsulation（GRE）では、24 バイトが追加されます。IPv4 ヘッダーが 20 バイト、GRE トンネルヘッダーが 4 バイトです。
GRE カプセル化を行うネットワークインターフェイスは、追加オーバーヘッドを考慮して MTU を下げる必要があります。MTU の上限は 1,500 バイトなので、IPv4 では MTU は 1,476 バイトになります（元の 1,500 バイトから GRE カプセル化の 24 バイトを引いた値）。この縮小後の MTU が、GRE がカプセル化できる IP パケットの最大サイズになります。
データパケットがネットワークインターフェイスの受け入れ上限より大きい場合、ネットワークはそのパケットを破棄するか、より小さいパケットにフラグメント化する必要があります。フラグメンテーションが起きたとき、Cloudflare は完全に再組み立てできるデータパケットだけを受け入れます。一部のフラグメントが欠けている場合、Cloudflare は受信済みのフラグメントをすべて破棄します。不完全なパケットをお客様へ転送することはありません。
TCP ヘッダーの do not fragment（DF）ビットを 1 にすると、途中のネットワーク機器が受け入れられる MTU よりパケットが大きい場合、フラグメント化せず破棄するよう指示します。ほとんどの TCP 実装は、フラグメンテーションによる問題を避けるために DF ビットを 1 にします。
フラグメンテーションで問題が起き、MSS クランプを設定できない場合は、Cloudflare が DF ビットをクリアできます。このオプションを有効にすると、Cloudflare は 1,500 バイトを超えるパケットをフラグメント化し、デカプセル化後にインフラ側で再組み立てします。これは最終手段として使います。詳細はアカウントチームに問い合わせてください。
サイズ 3,000 バイトの UDP データグラム（UDP ヘッダー 8 バイト + UDP データ 2,992 バイト）を考えます。標準の 1,500 バイト MTU に収めるには、この UDP データグラムは次のように 3 つの IP パケットにフラグメント化されます。
この UDP データグラムの送信元ポートが 389 で、宛先が Magic Transit 顧客の IP アドレスだとします。さらに、その顧客が送信元ポート 389 の UDP トラフィックを破棄するファイアウォールルールを持っているとします。これは一般的な Connectionless Lightweight Directory Access Protocol（CLDAP） ↗ リフレクション攻撃の経路です。
前述の 3 つのパケットフラグメントは Cloudflare に到着しますが、送信元ポート情報を含む UDP ヘッダーがあるのは最初のフラグメントだけです。2 番目と 3 番目のフラグメントには UDP データはありますが、UDP ヘッダー情報はありません。
ここで問題になるのは、Cloudflare がどのフラグメントを破棄し、どれをお客様へ届けるかです。フラグメント化したパケットの先頭部分だけを破棄すると、残りの部分がサービス拒否（DoS）攻撃中に大量のトラフィックを生む可能性があります。
次の図は、前述の 3 つの UDP フラグメントが Cloudflare と Magic Transit をどう流れるかを示します。要点は次のとおりです。
- Cloudflare は不完全なパケットをお客様へ送りません: パケットを完全に再組み立てするために必要なすべての部分を確認できない場合、Cloudflare はその部分的なデータフラグメントをお客様へ送りません。
- Cloudflare Network Firewall は個々のフラグメントではなく、完全に再組み立てしたパケットを対象に動作します: つまり、UDP / TCP ヘッダー情報に一致するフィルターは、最初のフラグメントだけでなく、完全に再組み立てしたパケットに適用されます。Cloudflare は非先頭フラグメントをお客様へ漏らしません。
- お客様側でもフラグメント化したパケットを見ることがあります: デフォルトでは（
clear_dont_fragment_bitが未設定の場合）、Cloudflare はお客様へデータを送る前に、トンネルに設定した MTU に収まるようパケットをフラグメント化します。パケットが 1,476 バイトより大きい場合、Cloudflare はそれをフラグメント化し、再組み立てのためにお客様へ送ります。
いずれの場合も、Cloudflare はすべてのフラグメントをお客様へ送ります。
最大セグメントサイズ（MSS）は、TCP セグメントのサイズを制限する TCP 設定です。3 ウェイハンドシェイク中に SYN パケットがこのオプションを設定します。
デフォルトでは、TCP エンドポイントはローカルのネットワークインターフェイス MTU に基づいて MSS 値を設定します。たとえば IPv4 で MTU が 1,500 バイトなら、MSS は 1,460 バイトになります（1,500 バイトから IPv4 ヘッダー 20 バイトと TCP ヘッダー 20 バイトを引いた値）。
MSS は、TCP パケットサイズの挙動を設定するための手段です。TCP エンドポイントが MTU の小さいネットワークの背後にある場合、MSS 値を実際のパス MTU に合わせると、リモートエンドポイントはその MTU に収まるパケットを送るようになります。したがって、IPv4 の TCP エンドポイントが MTU 1,476 バイトの GRE トンネルの背後にある場合、TCP SYN パケットの MSS 値は 1,436 バイトにする必要があります。1,476 バイトから IPv4 ヘッダー 20 バイトと TCP ヘッダー 20 バイトを引いた値です。
MSS 設定を変える方法の 1 つは、ルーターの WAN インターフェイスにあるネットワークインターフェイスの MTU をパス MTU に合わせることです。もう 1 つの方法は MSS クランプを適用することです。ルーターなどの中間ネットワーク機器が、パケット通過時に TCP の MSS オプションをその場で変更するよう設定します。中間ネットワーク機器のインターフェイス MTU を変えることは、MSS クランプの適用とは異なり、TCP の MSS 値は変わりません。
トンネルの種類に応じて MSS クランプをいくつに設定すべきかは、MSS クランプの推奨値 を参照してください。
非対称の ルーティング ↗ は、Magic Transit では特によくある構成です。インターネットからの受信トラフィックは Cloudflare ネットワークに入り、GRE トンネル（MTU 1,476 バイト）を通ります。データセンターからの送信トラフィックは、Direct Server Return（DSR）でインターネットへ送られます（MTU 1,500 バイト）。
非対称の構成では、Magic Transit 利用者がインターネットへ送るパケットの MSS 値を下げて、インターネットから自ネットワークへ向かうパケットサイズを小さくする必要があります。そのため、お客様のエンドホストを設定するか、ネットワークから出る送信経路上の中間機器に MSS クランプを設定します。次の図は、両方の経路で MSS 値がペイロードサイズにどう影響するかを示します。
前述の図の要点: MSS クランプは、クランプを適用した方向とは逆方向に流れる TCP パケットのペイロードサイズに影響します。
MSS クランプが影響するのは TCP トラフィックだけです。たとえば Magic Transit プレフィックス上に Web サーバーがある場合、MSS クランプは Direct Server Return（DSR）トラフィックの TCP データに効きます。ただし、Magic Transit トンネルの内側にさらにトンネルがある場合（トンネル内トンネル）は、別の対応が必要です。
たとえば Magic Transit の GRE トンネルを用意し、そのうえで構内の第三者機器から別の IPsec または GRE トンネルを動かしている場合、MSS クランプはカプセル化トラフィックの外側パケットには効きません。MSS クランプは TCP トラフィックだけに効き、IPsec / GRE でカプセル化したトラフィックは IP だからです。この構成では、受信と送信の両方で、内側トンネルインターフェイスの MTU をさらに下げる必要があります。
MSS の値は、ネットワークの構成によって変わります。
-
Magic Transit の受信専用トラフィック（DSR）:
- エッジルーターのトランジットポート: TCP MSS クランプを最大 1,436 バイトに設定します。
- Magic Transit プレフィックス上の、第三者との IPsec/GRE トンネル: 内部トンネルインターフェイス（多くの場合、GRE 終端ルーターの背後にある別のファイアウォール）に MSS クランプを適用し、現在の値から 24 バイト減らします。
-
Magic Transit の受信 + 送信トラフィック:
- Magic Transit GRE トンネルの内部インターフェイス: Magic Transit の送信トラフィックが通る側です。トンネル設定後に機器が自動で行う場合もありますが、機器によります。TCP MSS クランプを最大 1,436 バイトに設定します。
- Magic Transit プレフィックス上の、第三者との IPsec/GRE トンネル: 内部トンネルインターフェイス（多くの場合、GRE 終端ルーターの背後にある別のファイアウォール）で、現在の値から 24 バイト減らします。
IPsec トンネルでは、指定する値はネットワークの構成によって変わります。物理インターフェイスが見るのは IPsec で暗号化された パケット ↗ であり TCP パケットではないため、MSS クランプはそれらに適用されません。そのため GRE トンネルより低い値になります。
-
Magic Transit の受信専用トラフィック（DSR）:
- エッジルーターのトランジットポート: TCP MSS クランプを最大 1,436 バイトに設定します。
- Magic Transit プレフィックス上の、第三者との IPsec/GRE トンネル: 内部トンネルインターフェイス（多くの場合、GRE 終端ルーターの背後にある別のファイアウォール）で、現在の値から 140 バイト減らします。
-
Magic Transit の受信 + 送信トラフィック:
- エッジルーター上: Magic Transit の IPsec トンネル内部インターフェイス（送信トラフィックが通る側）に適用します。トンネル設定後に機器が自動で行う場合もありますが、機器によります。TCP MSS クランプを最大 1,360 バイトに設定します。
- Magic Transit プレフィックス上の、第三者との IPsec/GRE トンネル: 内部トンネルインターフェイス（多くの場合、構内の IPsec 終端機器の背後にある別のファイアウォール）で、現在の値から 140 バイト減らします。