こんにちは！ネットワークの裏側を覗くのが大好きな、技術メディアの主筆ライターです。
日々の業務で「ゼロトラスト」や「SASE（Secure Access Service Edge）」という言葉を聞かない日はないほど、企業のネットワークセキュリティの常識は大きく変わりましたよね。「社内だから安全」「VPNで繋げば安心」という境界防御の時代は終わり、どこからアクセスしてもすべての通信を疑い、検証する時代になりました。
さて、そんなSASEの導入プロジェクトで、インフラエンジニアの前に突如として立ち塞がる「ラスボス」のような存在をご存知でしょうか？ それが今回深掘りする 「GREトンネリングとオーバーヘッド（おまけの荷物）」 です。
「なんだか難しそうなプロトコルが出てきたぞ……」と思ったそこのあなた、大丈夫です！ 一歩ずつ、身近な例えを交えながら優しく紐解いていきましょう。
—
1. そもそもGREトンネリングってなに？（郵便配達の例え）
私たちが普段使っているインターネットは、まるで手紙や荷物を宛先まで届ける「郵便システム」のようなものです。パソコンから送られたデータは「IPパケット」という封筒に入れられ、世界中のルーターという郵便局員たちをリレー形式で経由して、目的地へ届けられます。
ここで、企業がSASEを導入する場面を想像してください。本社や支店の社員たちがインターネットへアクセスする際、その通信を一度セキュリティクラウド（SASEのPoP：中継拠点）へ安全に集約し、怪しい通信がないか検問（CASBやSWGによる検査）を受けさせたいわけです。
しかし、通常のインターネットの海をそのまま通信させると、途中で改ざんされたり覗き見られたりする危険があります。そこで登場するのが 「トンネリング」 です。
これを現実世界で例えるなら、「大切な手紙（元のIPパケット）を、そのまま頑丈なジュラルミンケース（新しいIPパケット）の中に丸ごとスポッと入れて送る仕組み」 です。このジュラルミンケースを作る役割を担うのが、GRE（Generic Routing Encapsulation） というプロトコルになります。
—
2. 知られざる「おまけの荷物（オーバーヘッド）」の正体
ジュラルミンケースに入れて安全に運べるのは素晴らしいのですが、ここに一つ大きな問題（物理の現実）が立ち塞がります。
インターネットの世界には、一度に運べる荷物の最大サイズ（限界重量）があらかじめ決められています。これがネットワーク用語でいう MTU（Maximum Transmission Unit） です。一般的に、インターネットの標準的なMTUは 1500 バイトとなっています。
ここで少し想像してみてください。
トラックの荷台（最大 1500 バイト）に、目一杯の大きさの荷物を積もうと計画しました。しかし、SASEへ送るためにその荷物を「GREというジュラルミンケース」に丸ごと詰め直さなければならなくなりました。
当然、ジュラルミンケース自体の重さや厚み（GREヘッダー：通常 24 バイトなど）の分だけ、全体のサイズが膨れ上がってしまいますよね。これが 「オーバーヘッド（付加的な負荷・サイズ増大）」 です。
- 元の荷物：
1460バイト - GREのケース：
24バイト - 合計サイズ：
1484バイト + さらに外側のIPヘッダー（20バイト） ＝1504バイト！
あれっ？ トラックの最大積載量（1500 バイト）をオーバーしてしまいました！
—
3. 荷物が大きすぎるとどうなる？（フラグメンテーションの悲劇）
制限サイズを超えた荷物をそのまま送り出そうとすると、途中のルーターでこんな悲劇が起きます。
「おっと、この荷物は大きすぎて我が社のトンネルを通せないぞ。仕方ない、この荷物を真っ二つにブッタ切って、別々のトラックに分けて送り出そう！」
これが フラグメンテーション（パケットの断片化） と呼ばれる現象です。
現実世界で、あなたの大切な荷物が途中で勝手にバラバラに解体され、別々のルートでバラバラに届いたらどうでしょう？ 受け取り側のパソコン（宛先）は、バラバラになった破片をもう一度パズルのように組み立て直さなければなりません。
この「切断と組み立て」の作業は、ルーターや端末のCPUにとって非常に大きな負担（オーバーヘッド）になります。ネットワークの世界では、このフラグメンテーションが多発すると、通信速度の低下（スループットの悪化）や、最悪の場合は接続断を引き起こす原因になるのです。
—
4. 現場でできる解決策：MSSクランピングとパスMTUディスカバリー
「じゃあ、どうすればこのパケット破片化の悲劇を防げるの？」という疑問が湧きますよね。
現場のネットワークエンジニアが実務で必ず行う、具体的な対策（処方箋）を見ていきましょう。
対策①：MSSクランピング（TCPの最大セグメントサイズ調整）
通信の最初に行われる「握手（3ウェイハンドシェイク）」のタイミングで、あらかじめ「うちのトンネルはちょっと狭いから、最初に作る荷物の大きさ（MSS）を小さめに申請してね！」とルーターに教え込むテクニックです。
CiscoルーターやヤマハのRTシリーズなどの機器では、次のような設定を入れて対策を行います。
! CiscoルーターでのMSS調整設定例 (インターフェースコンフィギュレーション)
interface Tunnel0
ip address 192.168.100.1 255.255.255.0
tunnel source GigabitEthernet0/0
tunnel destination 203.0.113.50
! TCPのMSS（Maximum Segment Size）をGREのオーバーヘッドを考慮して小さく制限する
ip tcp adjust-mss 1360> 【技術解説メモ】
> 通常のEthernetのMTU（1500）から、IPヘッダー（20）とTCPヘッダー（20）とGREヘッダー（24）を引いた安全なサイズとして、1360 や 1350 あたりにMSSを書き換える（クランプする）のが現場の定石です。
対策②：パケットの「お断りフラグ（DFビット）」の活用
ネットワークの途中で勝手にフラグメンテーションさせないために、パケットのヘッダーに DF（Don't Fragment：分割禁止） というフラグを立てる手法があります。もしサイズオーバーのパケットが来たら、ルーターは「分割するなと言われているので通せません」というエラー通知（ICMPメッセージ）を送信元に送り返します。
これによって、送信元は「もう少し小さなサイズで送り直そう」と賢く調整することができます。これが PMTUD（Path MTU Discovery） の仕組みです。
ただし、ファイアウォールの設定ミスなどでこのエラー通知（ICMP）が途中でドロップされてしまうと、通信が完全に固まってしまう「ブラックホールルーター問題」が起きることもあるため、注意深く設計する必要があります。
—
まとめ：見えないトンネルの裏側を想像しよう
今回は、SASEの基盤を支えるGREトンネリングの裏側で起きている「オーバーヘッド」と「サイズ調整の重要性」について解説しました。
- GREトンネリング は、通信を安全にカプセル化する便利な技術だが、おまけのヘッダー分だけパケットサイズが大きくなる。
- 最大サイズ（MTU）を超えると、フラグメンテーション が発生して通信パフォーマンスが低下する。
- 現場では MSSクランピング などの適切なパラメータ調整を行い、スムーズなパケットの旅をサポートする必要がある。
普段何気なく繋がっているクラウドやセキュリティサービスも、こうしたパケットレベルの細やかな気配りやエンジニアの泥臭いチューニングによって支えられています。
「最近、特定の拠点からクラウドへの通信だけやけに遅いな……」と感じたら、ぜひ今回のGREオーバーヘッドやMTU/MSSの値を疑ってみてくださいね。あなたのインフラ構築の引き出しが、また一つ深まるはずです。
それでは、また次回のテック解説でお会いしましょう！
コメント