SASE導入の死角：GREトンネルが引き起こす「見えないMTU問題」との付き合い方
読者の皆さん、こんにちは。現場でネットワークのトラブルシュートをしていると、決まって「なぜか特定サイトだけ読み込みが止まる」「APIのレスポンスが極端に遅い」という相談が舞い込んできます。
SASE（Secure Access Service Edge）を導入し、拠点のルーターからGRE（Generic Routing Encapsulation）トンネルでトラフィックをクラウド上のセキュア・ゲートウェイへ流し始めた途端に発生する、あの忌々しい現象です。今回は、多くのエンジニアが「魔法の杖」だと思って導入したGREが、実は足元をすくう罠になり得るという話を、少し現場の泥臭い視点を交えて紐解いていきましょう。
なぜGREは「パケットの敵」になるのか？
GRE（IPプロトコル番号47）は、非常にシンプルで強力なカプセル化技術です。しかし、そのシンプルさが災いします。
通常、標準的なイーサネットのMTU（Maximum Transmission Unit）は 1500 バイトですが、GREでパケットを包み込むと、ヘッダー分（GREヘッダー4バイト＋外側のIPヘッダー20バイト＝合計24バイト）がオーバーヘッドとして上乗せされます。つまり、本来 1500 バイト送れるはずのパケットが、GREトンネルを通ることで 1476 バイトしか載せられなくなるわけです。
ここで、何も知らずに 1500 バイトのパケットを流し込むと何が起きるか。ルーターは泣く泣くパケットをフラグメント（断片化）するか、あるいは DF（Don't Fragment） ビットが立っているパケットを破棄することになります。これが、特定の通信だけが「死ぬ」原因の正体です。
現場で遭遇する「TCP MSS」の調整術
この問題を解決する定石は、TCPの MSS（Maximum Segment Size） を適切に絞ることです。TCPのハンドシェイク時に、クライアントとサーバー間で「このサイズ以上のパケットは送らないでね」と握り合うことで、フラグメントを未然に防ぎます。
Ciscoルーター等の実務的な設定例を見てみましょう。
# インターフェース設定例
interface Tunnel0
ip address 10.255.255.1 255.255.255.252
# GREオーバーヘッド分を考慮してMSSを調整（1500 - 24 - 40 = 1436）
# 念のため余裕を見て1400程度に設定するのが現場の知恵
ip tcp adjust-mss 1400
tunnel source GigabitEthernet0/0
tunnel destination 203.0.113.10ここで重要なのは、計算式です。1500（MTU） - 20（IPヘッダー） - 20（TCPヘッダー） - 24（GREオーバーヘッド） = 1436 ですが、VPN等の多重化を考慮すると、さらに少し小さめの値を設定しておくのがエンジニアの「勘所」というものです。
API開発者が知っておくべき「そのパケット、本当に届いていますか？」
インフラ側でどれだけ対策しても、アプリケーションレイヤーで大きなリクエストやレスポンス（例えば、巨大なJSONを返すAPIなど）を扱う場合、MTU問題が再燃することがあります。
Pythonの requests や curl でデバッグする際は、-v オプションや verbose=True を使って、ハンドシェイクの後に通信が止まっていないか確認してください。
import requests
# API通信時のデバッグ例
try:
# 巨大なペイロードを送信する際は、パケット分割の影響を受けやすい
response = requests.post(
"https://api.example.com/v1/data",
json={"data": "..." * 1000},
timeout=10
)
response.raise_for_status()
except requests.exceptions.ConnectionError as e:
# ここでエラーが出る場合、MSS調整やPMTUD（Path MTU Discovery）が失敗している可能性大
print(f"接続エラー発生！パケットサイズを確認してください: {e}")もし自作のAPIクライアントを書く場合、curl で検証するのは鉄板です。
# パケットサイズを意識した検証コマンド
# --trace-ascii を使うと、ハンドシェイクの挙動が可視化できます
curl -v -X POST https://api.example.com/data \
-H "Content-Type: application/json" \
--trace-ascii dump.txt最後に：トラブルシューティングの心構え
「ネットワークが遅い」という報告が来たとき、多くのエンジニアはまず帯域幅を疑います。しかし、SASEとGREの組み合わせにおいて、真犯人はほぼ間違いなく「MTU不整合によるフラグメントのオーバーヘッド」か「ICMPブラックホール（PMTUD失敗）」です。
もし現場で「一部のWebサイトだけ開かない」と言われたら、迷わず ping にサイズ指定オプションを付けて打ってみてください。
# Windowsの場合：サイズを指定してDFビットを立てて送信
ping 8.8.8.8 -l 1472 -f
# Linuxの場合：
ping -s 1472 -M do 8.8.8.8これで応答が返ってこなければ、そのパスのどこかでMTUが 1472 未満に制限されています。
ゼロトラストへの移行は、単なる製品の入れ替えではありません。境界防御時代の「パケットは通り抜けるのが当たり前」という甘い考えを捨て、パケットのサイズ一つひとつにまで気を配る、そんな細やかな運用スキルこそが、これからのSASE運用を支える武器になるはずです。
皆さんのネットワークが、今日も安定して通信を運ぶことを願っています。
コメント