こんにちは！ネットワークセキュリティの世界へようこそ。インフラやネットワークの勉強を始めると、次から次へと専門用語やアルファベットの略語が出てきて、お腹いっぱいになってしまいますよね。
「VPN」「IPsec」「ESP」、そして今回主役として取り上げる「AH（Authentication Header）」……。なんだか難しそうな壁がそびえ立っているように感じるかもしれませんが、大丈夫です。一歩ずつ、身近な例えを交えながら優しく紐解いていきましょう！
今回は、このAHというプロトコルが「ネットワークの世界でどんなお仕事をしているのか」、そして現場のエンジニア泣かせである「NAT（ネットワークアドレス変換）との切ない関係」について、じっくりと解説していきますね。
—
1. そもそも「AH（Authentication Header）」ってなに？
ネットワークの世界では、私たちが送受信するデータは、いわば「ハガキ」のようなものです。途中の郵便局（ルーターや中継機器）や配達員（プロバイダ）の目をすり抜けながら、宛先まで届けられます。
ここで大きな問題になるのが、次の2点です。
1. 中身の改ざん（途中で悪い人に書き換えられていないか？）
2. 送信者のなりすまし（本当に信頼できる相手から届いたものか？）
この問題を解決するために生まれたのが、IPsecというセキュリティの仕組みであり、その中で「データの完全性（改ざんされていないこと）」と「送信者の認証」をガッチリ守る役割を持つのがAHプロトコルなんです。
現実世界で例えるなら「封筒の割印（わりいん）」
AHの働きを身近なもので例えるなら、重要書類を入れた「封筒の継ぎ目に押された割印やセキュリティシール」です。
もし、配達途中の誰かが悪意を持って封筒をバリッと開き、中の手紙の金額を書き換えたとします。そして、また上手にのり付けして元に戻したとしても……封筒の「割印」や「セキュリティシール」がビリッと破れていたら、「おや？これ、途中で誰かに開けられたな！」と一目で分かりますよね。
AHはまさにこの役割をIPパケット全体に対して行っています。データが目的地に着くまでの間に、一文字たりとも書き換えられていないことを完璧に証明してくれる頼もしい相棒なのです。
—
2. AHのヘッダー構造と「認証範囲」の秘密
さて、ここから少しだけパケットの構造という核心に迫っていきますよ。「うわ、難しそう…」と思わず、一緒に図解を見るような気持ちでついてきてくださいね。
IPsecで保護されたパケットがネットワークを流れるとき、元のパケットの先頭にAHのヘッダーがペタッと貼り付けられます。
AHヘッダーの主な中身（フィールド）
AHのヘッダーの中には、主に次のような情報（切手や管理番号のようなもの）が入っています。
- 次ヘッダー（Next Header）: 「このAHのすぐ後ろに、どんなプロトコル（TCPやUDPなど）が続いているよ」という目印です。
- ペイロード長（Payload Length）: AHヘッダー自体の大きさを表します。
- セキュリティパラメータインデックス（SPI）: 「どのルールブック（暗号や認証の方式）を使ってこの手紙を書いたか」を識別するためのID番号です。
- シーケンス番号（Sequence Number）: パケットの順番を表す番号です。同じパケットをもう一度送りつけて混乱させようとする悪い奴（リプレイ攻撃）を防ぐために使われます。
- ICV（Integrity Check Value / 認証データ）: これが一番重要です！パケット全体から計算された「魔法のチェックサム（要約値）」が入っています。受信側で同じ計算をして、この値が一致すれば「改ざんなし！」と判定されます。
AHが「守る範囲（認証範囲）」の驚きの事実
ここで、インフラエンジニアの試験などでもよく狙われる、AHの少し変わった特徴をご紹介します。
実はAHが保護するのは、「IPパケットのヘッダー情報（宛先や送信元IPアドレスなど）の大部分」と「中身のデータ（ペイロード）」です。
ただし、IPヘッダーの中でも、ルーターが中継する途中で書き換わることが前提のフィールド（例えば、ルーターを通るたびに減らされる生存時間 TTL など）は、計算から除外（ゼロクリア）されます。
「データだけでなく、宛先などのヘッダーも含めて丸ごと封印する」のがAHのスタイルなんですね。
—
3. 現場泣かせ！NAT環境でのAHの非互換性
さて、ここからが実務で一番ハマりやすいポイント、そしてネットワークエンジニアの頭を悩ませる「NAT（Network Address Translation）」との切ない関係のお話です。
NATってそもそも何だっけ？
自宅やオフィスのルーターを思い浮かべてみてください。私たちのパソコンにはプライベートIPアドレス（例：192.168.1.10）が割り振られていますが、インターネットに出るときには、ルーターが持つグローバルIPアドレスに変換（NAT）されて外の世界へ飛び出しますよね。
このとき、ルーターはパケットの「IPヘッダーに含まれる送信元IPアドレス」をこっそり書き換えているのです。
なぜAHはNATを通り抜けられないのか？
もうお分かりでしょうか？
先ほど、AHは「パケットが改ざんされていないかチェックするために、IPヘッダーも含めて丸ごと封印（ICV計算）している」とお伝えしました。
もし、途中のルーターがNATによって「IPアドレス」を書き換えてしまったらどうなるでしょうか？
受信側に届いたとき、受信側は「届いたパケットのIPアドレスを使って、届いたICVを検証しよう」としますが、途中でアドレスが書き換わっているため、計算結果がどうしても一致しなくなってしまうのです。
結果として、受信側のセキュリティ機器は「おっと、このパケットは途中で改ざんされているぞ！（あるいは壊れているぞ）」と勘違いして、容赦なくパケットをドロップ（破棄）してしまいます。
これが、AHがNAT環境で使えない（非互換である）決定的な理由です。
—
4. 実際のインフラ現場での対策と設定のヒント
「じゃあ、ルーターの向こう側（インターネット越し）とはAHを使った安全な通信ができないの？」という不安がよぎりますよね。ご安心ください、現代のネットワークでは賢い回避策が用意されています。
実務の世界では、AH単体で使われることは減り、データを暗号化する役割を持つ「ESP（Encapsulating Security Payload）」というプロトコルが主に使われます。ESPであれば、データ部分だけを暗号化して保護するため、NAT環境をうまくすり抜ける技術（UDPカプセル化など）と組み合わせることが可能です。
もしどうしてもIPsecを設定する機会があれば、CiscoルーターやLinuxのIPsec設定（StrongSwanなど）において、次のようなモードやプロトコルの選択に直面します。
# 【設定づくりのヒント：CiscoルーターのIPsecトランスポート/トンネル設定イメージ】
crypto ipsec transform-set MY-TRANSFORM-SET esp-aes 256 esp-sha256-hmac
# ここで 'esp-...' を指定しているのが分かりますね。
# もしここに 'ah-sha256-hmac' を指定してしまうと、NAT環境下で通信断（パケット破棄）のトラブルが発生しやすくなります。もし実務で「自宅のルーターの背後にある拠点から、本社のルーターへIPsec VPNを張りたいけれど、なぜか通信できない！」というトラブルに遭遇したら、「もしかしてAHを使っていないか？ NAT越えでパケットのIPヘッダーが書き換わって認証エラーになっていないか？」と疑ってみてください。この視点を持つだけで、トラブルシューティングのスピードが劇的に変わりますよ。
—
おわりに
今回は、AH（Authentication Header）プロトコルの基本構造と、NAT環境における宿命的な非互換性について解説しました。
最初は難しく見えるパケットの仕組みも、「手紙の割印」や「途中の郵便局での書き換え」という現実世界の比喩に置き換えてみると、ぐっと身近に感じられたのではないでしょうか。
ネットワークの世界は、こうした「ルールの厳しさと、それを現実の仕組み（NATなど）にどう合わせるか」というジレンマの連続で、そこがまた最高に面白いところです。
今日の知識が、あなたのインフラ学習や日々の運用管理の現場で少しでもお役に立てば嬉しいです。それでは、また次回の技術解説でお会いしましょう！
コメント