忘れ去られた守護者：AHプロトコルの美学と、現代ネットワークが直面する残酷な現実
ネットワークエンジニアの端くれとして、皆さんは夜中にふと、パケットの深淵に思いを馳せることはないだろうか。現代のゼロトラストアーキテクチャにおいて、暗号化は「常識」だ。しかし、暗号化だけでは足りない。我々が真に求めるのは、データが改ざんされていないという「完全性」と、誰が送ったかという「真正性」の証明である。
今回は、IPsecの古参プロトコルであり、現代のクラウドネイティブな環境ではむしろ「異端」扱いされる Authentication Header (AH) について、その剥き出しの構造と、なぜ彼が現代のNAT（Network Address Translation）の荒波で溺れるのかを徹底的に解剖していく。
AHプロトコルの解剖学：データ完全性の原点
AH（プロトコル番号 51）は、ペイロードを暗号化しない。その代わり、IPヘッダーの一部（変化するフィールドを除く）からペイロードの末尾に至るまでを、HMAC等のハッシュ関数で計算し、その結果をパケットに埋め込む。
AHのヘッダー構造
AHヘッダーは、IPヘッダーとトランスポート層（TCP/UDP）の間に割り込む。
Next Header(8bit): 次のプロトコルの種類（TCPなら6）。Payload Length(8bit): AHヘッダーの長さ。Reserved(16bit): 将来のための予約領域。SPI(32bit): セキュリティパラメータインデックス。どのSA（Security Association）を使うかを識別する。Sequence Number(32bit): リプレイ攻撃を防止するための通し番号。ICV(可変長): 整合性チェック値。ここで認証が行われる。
この構造の何が美しいかと言えば、ICV（Integrity Check Value）がパケット全体を「固着」させる点にある。中間で悪意あるアクターがIPヘッダーをいじれば、受信側で即座にハッシュ不一致が検知される。これが純粋な「完全性」の哲学だ。
なぜAHは「NATの悪夢」に苦しめられるのか
ここで、現場のエンジニアが直面する最大の壁――NATとの相性について語ろう。
AHの設計思想は「IPヘッダーまで認証する」ことにある。しかし、NATを通過する際、ルーターは送信元IPアドレスやポートを書き換える。するとどうなるか？当然、ICV の計算結果が合わなくなり、パケットは受信側で静かにドロップされる。
これが、多くの企業内ネットワークでIPsecの「トンネルモード」に ESP (Encapsulating Security Payload) が選ばれ、AHが歴史の影に追いやられた理由だ。ESPはIPヘッダーを認証対象から外すことで、NAT越えを可能にしている。
トラブルシューティングの定石：パケットの視点
もし、あなたがネットワーク管理者として「AHパケットがなぜか通らない」という事象に遭遇したら、まずは tcpdump でICVの不整合を疑う前に、iptables や nftables でプロトコル 51 がブロックされていないかを確認してほしい。
# AHプロトコル（51）が許可されているか確認
# ゼロトラスト環境では、AHではなくESP+UDPカプセル化(4500番ポート)を推奨する
sudo nft list ruleset | grep 51パフォーマンスの最適化：RTT削減とバッファチューニング
AHやESPを駆使したセキュアなトンネルを構築する際、セキュリティと引き換えに発生する最大のコストは「オーバーヘッド」と「遅延（RTT）」だ。特に、TCPヘッダーをカプセル化して暗号化・認証する場合、MTU（Maximum Transmission Unit）の調整を怠ると、パケット断片化によるパフォーマンスの劇的な低下を招く。
TCP/IPスタックのチューニング
高トラフィックなVPNゲートウェイでは、カーネルのバッファサイズを最適化することが、擬似的なRTT削減に繋がる。
# sysctl.confへの追記例：TCP送受信バッファの拡大
# 高速なバックボーン回線でのスループットを維持する
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216現代のセキュリティアーキテクトへ：AHは死んだのか？
ここまで読んで、「AHはレガシーで使えない」と結論づけるのは早計だ。AHは、特定の「管理された環境下」において、暗号化の計算コストをかけずにデータ完全性を保証する唯一無二の手段となり得る。例えば、機密性の高い管理用通信や、センサーネットワークのデータ完全性担保など、暗号化が不要または法的に禁止されている領域でこそ、その輝きを放つ。
しかし、広域なエンタープライズNWでは、TLS 1.3が提供する強力な認証と暗号化のセットこそが正義であることは疑いようがない。
最後に一つだけ覚えておいてほしい。プロトコルは単なる仕様書ではなく、その時代のネットワークエンジニアたちの「理想」の結晶だ。AHが抱えるNATとの不和は、当時の「インターネットはエンドツーエンドであるべき」という信念の裏返しでもある。
アーキテクトとして、我々は仕様を選ぶのではない。そのプロトコルが設計された背景にある「魂」を理解し、現在のビジネス要件という制約の中で、最も安全かつ静かな経路を設計するのだ。
さあ、次はどのパケットを解析しようか。ネットワークの深淵は、まだまだ深い。
コメント