VPNのパケット断片化という「見えない牙」を折る：MTU/MSS最適化の深淵
ネットワークエンジニアとして現場を渡り歩いていると、いかに最新のゼロトラスト・アーキテクチャやIdPによる認証基盤を完璧に構築しても、最後の最後で「特定のWebサイトだけが見えない」「大容量ファイルの転送がタイムアウトする」といった、MTU（Maximum Transmission Unit）に起因する古くて新しい問題に足元をすくわれる場面に何度も遭遇する。
VPN、特にIPsecやSSL-VPNを導入すると、オリジナルのパケットにヘッダーが追加される「カプセル化（Encapsulation）」が発生する。このオーバーヘッドこそが、ネットワークの境界においてパケット断片化（Fragmentation）を引き起こし、パフォーマンスを殺し、時にはセキュリティ機器の検査漏れを誘発する「見えない牙」となるのだ。
今日は、このパケット断片化のメカニズムを解剖し、インフラアーキテクトとして避けては通れない最適化手法を紐解いていく。
—
1. カプセル化が引き起こす「パケット断片化」の静かなる脅威
標準的なEthernetのMTUサイズは 1500 bytes だ。しかし、IPsec（ESP/AH）やSSL-VPN（TLS/DTLS）を導入すると、ペイロードの外側に新たなIPヘッダー、UDPヘッダー、あるいはESPヘッダーが付与される。
ここで 1500 bytes のパケットがVPNトンネルに入るとどうなるか。当然ながら、物理インターフェースの制限を超え、ネットワーク機器はパケットを断片化せざるを得なくなる。
断片化されたパケットは、再構築（Reassembly）のためのCPU負荷をネットワーク機器に強いるだけでなく、特にステートフルなファイアウォールにおいて重大な脆弱性を生む。断片化されたパケットの2番目以降のフラグメントにはTCPヘッダーが含まれないため、IDS/IPSがシグネチャによる検査をすり抜けてしまうケースがあるからだ。ゼロトラストの文脈においても、パケットの整合性はセキュリティの根幹である。
—
2. TCP MSS Clamping：なぜ「クランプ」が最強の武器なのか
パケット断片化を防ぐための最もエレガントな解決策が MSS Clamping だ。TCPのハンドシェイク中に送信される SYN パケット内の MSS (Maximum Segment Size) 値を、VPN装置側で「書き換えて」しまう。
クライアントが 1460 bytes のMSSを要求しても、VPNルーターがそれを 1360 bytes に書き換えることで、送信元ホストは最初から「小さめのパケット」を生成するようになる。これにより、カプセル化されても物理MTUを一切超えることがなくなる。
Cisco/Juniper等での設定例
多くのルーターでは、インターフェースに対して以下のように設定する。
# Cisco IOSでのMSS Clamping設定例
interface Tunnel0
# IPsecのオーバーヘッドを考慮して1360に制限
ip tcp adjust-mss 1360ここで重要なのは、値の選定だ。IPsecのESPモードであれば、一般的に 1360 から 1400 の間で調整するのが定石だが、環境によってはさらなる余裕が必要になる。
—
3. 実践：LinuxカーネルにおけるTCPバッファとMTUの最適化
コンテナやクラウド上のLinuxインスタンスからVPNを張る場合、カーネルパラメータの調整も欠かせない。特に TCP Window Size と MSS のバランスは、RTT（Round Trip Time）が長い環境でのスループットを左右する。
# カーネルパラメータでTCP最大バッファサイズを調整（sysctl.conf）
# 広帯域・高遅延環境（BDP: Bandwidth Delay Product）を考慮
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# PMTU Discoveryを有効にする（デフォルトは有効だが確認）
net.ipv4.ip_no_pmtu_disc = 0ここで気をつけたいのが、Path MTU Discovery (PMTUD) の失敗だ。ICMPの Destination Unreachable (Fragmentation needed) がファイアウォールで遮断されていると、PMTUDは機能せず「ブラックホール・ルーター問題」が発生する。セキュリティを固めすぎてICMPを全遮断している現場は要注意だ。
—
4. セキュリティとパフォーマンスのトレードオフ：勘所
パケット断片化を単なる「通信エラー」と捉えて放置してはならない。これは、ネットワークの信頼性のみならず、TLSのハンドシェイク最適化にも直結する。
- TLSハンドシェイク: TLS 1.3ではハンドシェイクの往復回数が減ったが、それでも最初の
Client Helloが断片化すると、TCPの再送制御（Retransmission）によりセッション確立が遅延する。 - ヘッダー圧縮: 可能であれば、VPNトンネル内で
ROHC (Robust Header Compression)等を活用することで、ヘッダーサイズを物理的に削減し、MTUの圧迫を緩和するアプローチも検討すべきだ。
結論：パケットが見える技術者であれ
ネットワークがブラックボックス化し、SD-WANやSaaSの裏側で何が起きているか見えにくい時代だからこそ、こういった「レイヤー3以下の泥臭い調整」ができる技術者が、結局のところ一番信頼される。
MTUやMSSの設定は、単なるパラメータ変更ではない。それは、複雑な企業ネットワークという大海原を駆け巡るデータパケットに対して、「お前たちは決して断片化せず、無傷のまま終端まで届くのだ」と指示を出す、ネットワークの調律（チューニング）に他ならない。
まずは明日、トラブルシューティングの現場で ping -f -l 1472 <target_ip> を打ち、物理ネットワークの真の限界を知ることから始めてほしい。そこから見える景色こそが、真のインフラアーキテクトへの入り口なのだから。
コメント