IPsecのオーバーヘッド：モード、NAT-T、アルゴリズムで変わる
公開されている単一のオーバーヘッド値は、ひとつの経路上のひとつのカプセル化を説明するだけです。トンネルが実際にネゴシエートするヘッダーを合計し、そのうえで経路を測定してください。
どこかのガイドに、たいてい六十から八十バイトの数値があり、誰かが1500から引いてインターフェースMTUを求めたものです。その数値は、特定の経路上の特定のカプセル化を説明するものです。モード、外側のアドレスファミリー、暗号、あるいはNATの有無を変えれば、その計算はもうあなたのトンネルには当てはまりません。
その数値は別のトンネルのものだった
オーバーヘッドは、抽象的な意味でのIPsecの性質ではなく、実際に組み立てられるパケットの性質です。ネゴシエートされたモード、外側のヘッダー、保護ヘッダー、パディング、整合性フィールド、そして場合によっては追加のUDPラッパーです。
IPv4でNATなしのトランスポートモードについて引用される数値は、NATトラバーサル下のIPv6によるトンネルモードより小さいパケットを説明しています。どちらもそれぞれのケースでは正しいのです。どちらかを別の配備にコピーすると、大きな転送を壊すMTUに行き着きます。小さなリクエストは動き続けるので、失敗は静かなものです。
実際にある層を合計する
外側のIPヘッダーから始めて内側へ進みます。トンネルモードでは元のパケットが内側にあるので、外側のヘッダーは置き換えではなく追加です。RFC 4303 は、ESPヘッダー、パディング、それに続く整合性データについて説明しています。
| Layer | What it adds | When it applies |
|---|---|---|
| Outer IP header | 20 bytes for IPv4, 40 for IPv6 | Always, and 40 rather than 20 if the outer path is v6 |
| ESP header | 8 bytes of SPI and sequence number | Always |
| Block cipher IV | 8 to 16 bytes depending on the transform | When the negotiated cipher uses one |
| Padding and trailer | Padding to the block size, plus two trailer bytes | Always, and the amount varies with payload length |
| Integrity data | 12 to 16 bytes for common authenticated ciphers | When integrity protection is negotiated |
| UDP encapsulation | 8 bytes | NAT traversal on port 4500, which is common for clients behind NAT |
これらの行のどれも配備間で一定ではなく、パディングの行はひとつの配備の中ですら一定ではありません。公開された単一のオーバーヘッド値が期待外れになる理由は、まさにこれです。
同じトンネルについて二つの拠点が食い違うことがある
保護されたパケットは依然として外側の経路を渡らなければならず、外側の経路はどこでも同じではありません。PPPoEアクセス回線はきれいなEthernetセグメントより運べる量が少なくなります。モバイルネットワークはさらに縮むことがあり、自社トラフィックをトンネル化するプロバイダーは誰も言わなかったもう一つのカプセル化を加えます。一方の回線で動き他方で失敗するトンネルは、二番目の回線を説明しているのであって、プロトコルを説明しているのではありません。
両方向が異なることもあります。非対称な経路では、アップロードは動くのにダウンロードが止まる形になり、到達性ではなくパケットサイズを見るまでアプリケーションの問題のように読めます。小さなpingが通ることは、フルサイズの応答についてほとんど何も証明しません。
引くのではなく測る
経路を通り抜けられる最大のデータグラムを見つけ、次にインターフェースが報告する値と比較します。
ip link show eth0 | grep -o 'mtu [0-9]*' ip xfrm state list ping -M do -s 1400 198.51.100.7 ping -M do -s 1372 198.51.100.7 tcpdump -ni any -c 20 'esp or udp port 4500'
応答が返るまでpingのサイズを下げていき、動く最大値をその経路の予算とみなします。xfrmの出力は、どのモードとどのアルゴリズムがネゴシエートされたかを示し、それが誠実な計算の入力になります。キャプチャは、ワイヤ上にあるのがESPかUDPカプセル化ESPかを確認し、それでNATの疑問は推測なしに片づきます。
制御プレーン用にもう一つ値を確保してください。IKEハンドシェイクのパケットはデータパケットと構造が違うので、ハンドシェイクのキャプチャから導いたサイズはデータプレーンのMTUではありません。
数値をあるべき場所に置く
トンネル経由のTCPでは、MSSクランプがしばしば最も侵襲の少ない制御となるのは、トンネル自体を変えずに端点が送る量を減らせるからです。ルートベースのトンネルでは、トンネルインターフェースのMTUを意図的に設定し、その理由を記録してください。両方を同時に行ってから測っても、どちらが効いたのかは何も分かりません。
ネゴシエートされたモード、外側のファミリー、NATの状況、再現できる症状をチケットにまとめて残してください。記録された四つの事実は記憶された定数に勝り、次のクライアント更新を生き延びるのはこの形だけです。