こんにちは。ネットワークの現場で幾度となくパケットキャプチャの荒波に揉まれ、深夜のトラブルシューティングに冷や汗を流してきたシニアエンジニアの私だ。
今日は、現代のゼロトラスト全盛期においても、レガシーなデータセンター間接続やクラウドへのセキュアなブリッジとして根強く使われているIPsec、その中でも少しマニアックで、しかしネットワークの美しさが凝縮されたプロトコル「Authentication Header (AH)」について話をしよう。
「なぜ今さらAHなのか？」と思ったそこのあなた。実務でIPsecトンネルを組むとき、大半のエンジニアは暗号化と完全性の両方を提供してくれるESP（Encapsulating Security Payload）を選ぶはずだ。だが、AHのヘッダー構造、そしてそれがなぜ現代のネットワーク、特にNAT（Network Address Translation）環境で盛大に嫌われ、実務から姿を消しつつあるのかを深く理解していると、パケットを見た瞬間に「あ、これはNAT越えで死んでるな」と秒速で原因が特定できるようになる。
机上の空論ではない、現場で血を流しながら得た知見を交えて、AHの核心に迫っていこう。
—
1. AH（Authentication Header）の存在意義と「暗号化しない」という選択
IPsecというと「通信の暗号化」というイメージが強いかもしれない。だが、RFC 4302で定義されるAHプロトコルが提供するのは、暗号化（Confidentiality）ではない。提供するのは以下の2点のみだ。
1. データ完全性（Data Integrity）: パケットが途中で改ざんされていないことの証明
2. データ送信元認証（Authentication）: パケットの送信元が正当なピアであることの証明
3. リプレイ攻撃からの保護（Replay Protection）: シーケンス番号を用いた、古いパケットの再送攻撃の防止
「おいおい、中身が丸見え（暗号化なし）なのに、何の意味があるんだ？」と思うかもしれない。しかし、セキュリティの要件によっては「通信内容は傍受されても構わないが、データが途中で書き換えられていないことと、誰が送ったかが100%保証されていなければならない」というケースが存在する。例えば、公開情報の配信や、秘匿性よりも完全性が厳しく問われる一部の制御システムなどがこれに該当する。
何より、暗号化処理（AES等）のオーバーヘッドを嫌い、CPU負荷を最小限に抑えつつ整合性を担保したいという、極限までパフォーマンスを絞り出すインフラ設計において、AHはかつて一つの選択肢だったのだ。
—
2. AHパケットのヘッダー構造と認証範囲のリアル
では、IPパケットの中でAHがどのように挟まり、どの範囲が「認証の対象（変更されてはならない場所）」になるのかを見ていこう。
IPパケット（IPv4を例にとる）にAHがカプセル化されると、IPヘッダーとトランスポート層（TCP/UDP）の間にAHが挿入される。
[ 外部 IPヘッダー ] [ AH ヘッダー ] [ TCP / UDP ヘッダー ] [ ペイロード ]
│ │
└──── 認証範囲 ──────┘ （※一部の可変・動的フィールドを除く）AHヘッダーのフィールド構成
RFC 4302に基づくAHのヘッダー構造は以下のようになっている。トランスポートモードの場合、元のIPヘッダーの直後にこれが差し込まれる。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Payload Len | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Integrity Check Value (ICV) |
| (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Next Header (
Next Header): AHの直後に続くプロトコルを示す（TCPなら6、UDPなら17など）。 - Payload Length (
Payload Len): AHヘッダー自体の長さを32ビットワード単位で表す。 - SPI (
Security Parameters Index): 受信側がどのセキュリティアソシエーション（SA）を使って復号・検証すべきかを特定するための32ビットの識別子。 - Sequence Number (
Sequence Number): リプレイ攻撃を防ぐための単調増加する32ビット整数。 - ICV (
Integrity Check Value): ハッシュ関数（HMAC-SHA256など）によって計算されたチェックサム。これがデータの完全性を担保する実体だ。
どこが「認証範囲」になるのか？
ここがネットワークエンジニアの腕の見せ所だ。AHのICVを計算する際、IPパケット全体のすべてのフィールドがハッシュ化されるわけではない。
IPv4の場合、IPヘッダー内のフィールドには、ルーターを通過する過程で「書き換わるべきもの」が存在する。代表的なのが TTL (Time to Live) や ToS/DSCP (Type of Service)、そして Fragment Offset だ。これらはルーターを経由するたびに値がデクリメントされたり書き換えられたりするため、もしこれらも含めてICVを計算してしまったら、最初のルーターを1ホップ通過した瞬間にICVの不一致（検証エラー）を起こしてパケットがドロップされてしまう。
したがって、AHの認証計算（ICV計算）においては、IPヘッダー内の可変フィールドは「ゼロクリア（または特定の値にマスク）」されてからハッシュ関数にかけられる。
- IPv4ヘッダーの Type of Service (ToS)、Flags、Fragment Offset、TTL、Header Checksum は、計算時に無視（あるいはゼロ化）される。
この厳密なルールがあるからこそ、AHは中間者攻撃やパケットの改ざんを完璧に検知できるのだ。
—
3. 現場の悪夢：なぜAHはNAT環境で使えないのか？
さて、ここからが実務で最も直面する悲劇の話だ。現代のインフラにおいて、パケットがNAT（NAPT含む）を通過しないネットワーク環境など、もはや絶滅危惧種と言っていい。自宅からクラウドへ、あるいは企業オフィスからAWSのVPCへ向かう通信は、必ずどこかでルーターやファイヤーウォールによるNATを受けている。
ここでAHの致命的な弱点が露出する。
1. IPアドレスの書き換えとICVの破綻
NAPT（Network Address Translation）は、プライベートIPアドレスをグローバルIPアドレスに変換する際、IPヘッダーの Source IP Address（または Destination IP Address）を書き換える。
前述した通り、AHのICVは「パケットが途中で改ざんされていないこと」を証明するために、IPヘッダーの重要な部分も含めてハッシュ値を計算している。
もしNATルーターがIPアドレスを書き換えたらどうなるか？
受信側でAHのICVを検証したとき、「計算されたハッシュ値」と「パケットに含まれているICV」が完全に一致しなくなる。結果、受信側は「このパケットは途中で改ざんされた！」と判断し、容赦なくパケットを破棄（Drop）する。これが、AHがNAT環境で通信不能に陥る根本的なメカニズムだ。
2. トランスポート層ポートの不可視性
さらにタチが悪いことに、NAPTはポート番号（TCP/UDP Port）を見てアドレス変換を行う。しかし、AHプロトコルはIPヘッダーの直後にAHヘッダーを挟み込んでおり、その内側にあるTCPやUDPのヘッダーは暗号化こそされていないものの、AHの保護下（あるいは配置の位置関係）に隠れている。NATルーターの種類によっては、ESPのようにUDPカプセル化（UDPポート4500などによる包み込み）が標準で用意されていないAHの場合、ポート番号を正しく書き換えられず、ルーターがパケットを処理しきれずに捨ててしまう。
こうした背景から、IPsecをNAT環境で利用する場合は、AHではなく、NAT越え（NAT Traversal: NAT-T）のメカニズムをエレガントにサポートできるESP（UDP 4500ポートでのカプセル化）を使うのが、業界の絶対的なデファクトスタンダードとなっている。
—
4. 実務での設定例とデバッグTips
では、実際にインフラを構築する際のコンフィグレーションと、トラブルシューティングの現場で使える実践的なTipsを見ていこう。今回は、Linuxの強力なIPsecスタックである libreswan や strongSwan、あるいはルーティング設定の文脈に近い設定イメージを解説する。
設定例：強硬にAHを指定した場合の強烈なエラー
もしあなたが意地でもAHを使おうと、strongSwanの ipsec.conf で認証アルゴリズムにAHを指定したとする。
# /etc/ipsec.conf の設定サンプル（AHプロトコルを指定する例）
conn office-to-cloud
authby=secret
# トランスポートモードまたはトンネルモードの指定
type=tunnel
left=203.0.113.10 # 自拠点のグローバルIP（※NAT配下だとこの時点で死ぬ）
leftsubnet=192.168.10.0/24
right=198.51.100.20 # 相手先のグローバルIP
rightsubnet=10.0.0.0/16
# 【重要】ESPではなくAHを明示的に指定
# 現代の環境ではここに ah=sha256-hmac などを指定することになる
ah=sha256-hmac
auto=startこの設定で、もし left の手前に家庭用ルーターや企業用ルーターのNAPTが存在していた場合、IKE（Internet Key Exchange）のフェーズ1は奇跡的に成功したとしても、IPsec（フェーズ2）のデータ通信が始まった瞬間にパケットが一切通らなくなる。
現場のデバッグ：tcpdumpでAHを見分ける方法
夜間の障害切り分けで「なぜ通信できないのか」を暴くため、現場のエンジニアは tcpdump を叩く。AHパケットは、IPプロトコル番号 51 として流れる。
Linuxのコンソールで以下のようにキャプチャを仕掛けてみよう。
# プロトコル番号 51 (AH) のパケットをキャプチャする
sudo tcpdump -nnvv -i eth0 proto 51もしコンソールに以下のようなログが流れてきたら、AHパケットがインターフェースに届いている証拠だ。
22:10:15.123456 IP (tos 0x0, ttl 64, id 12345, offset 0, flags [DF], proto AH (51), length 108)
203.0.113.10 > 198.51.100.20: AH(spi=0x12345678,seq=0x1,icv=0xabcdef...)ここで、もしパケットの seq（シーケンス番号）が全くインクリメントされなかったり、相手側からの戻りパケットの icv 検証エラーでルーターのドロップカウンターが回っていたりする場合は、ほぼ間違いなく「経路上のどこかでNATによるIPヘッダーの改変（書き換え）が発生している」と断定して良い。
—
5. まとめ：モダンな設計におけるAHの立ち位置
ここまで、AHプロトコルのヘッダー構造、認証範囲の仕組み、そして実務で最も恐れられるNATとの非互換性について解説してきた。
- AHは暗号化を提供せず、完全性と認証のみを提供する（IPプロトコル番号 51）。
- IPヘッダーの可変フィールド（TTLやフラグメント情報など）をゼロクリアしてICV（ハッシュ）を計算するため、途中でIPアドレスが書き換わると即座に破綻する。
- そのため、NAT環境（NAPT）では絶望的に相性が悪く、現代のインターネットインフラでは基本的にESP（UDP 4500）へ移行すべきである。
ゼロトラストアーキテクチャやクラウドネイティブなネットワーク設計において、エンドポイント間のセキュアな通信は、TLSやmTLS、あるいは最新のWireGuardやESPベースのIPsecが主流となっている。AHが実戦投入される機会は極めて稀になっているが、「なぜこのプロトコルはNATを越えられないのか」というパケットレベルの挙動を深く理解していることは、ネットワークエンジニアとしての基礎体力を証明する最高の一生モノのスキルとなる。
障害の闇夜に迷ったときは、いつもパケットのヘッダーに立ち返ろう。パケットは決して嘘をつかない。
コメント