IPsec と IKEv2

IPsec は IP レベルでポリシーに基づきトラフィックを保護し、IKEv2 はピアの認証、アルゴリズムの交渉、セキュリティ関連付け（SA）の維持を担当します。本社 10.10.0.0/24 から支社 10.20.0.0/24 へのアクセスを例に挙げます：業務ホストはパケットをゲートウェイに渡し、ゲートウェイは保護が必要かどうかを判断し、確立済みの送信用 SA でカプセル化します。相手側ゲートウェイは着信用 SA を検索し、認証・復号してポリシーを確認した後、内部ネットワークへ転送します。

ここでは3つの独立した事柄があります：⁠システムルーティングがパケットをどこに送るか、ポリシーがどのように保護を要求するか、SA が利用可能なキーと状態を持っているかどうかです。IKE が接続済みと表示するのは、その一部が成立していることを示すだけです。

ポリシーとセキュリティ関連付け：なぜ別々に保存するのか

セキュリティポリシーデータベース（SPD）は、トラフィックを破棄するか、バイパスするか、IPsec で保護するべきかを表現します。セキュリティ関連付けデータベース（SAD）は、具体的なアルゴリズム、キー、SPI、シーケンス番号、ライフサイクルなどの状態を保存します。1つのポリシーは、異なる時期に異なる世代の SA を指すことができ、再鍵時には新旧の SA が短時間併存する場合もあります。IPsec アーキテクチャ RFC 4301

ESP SA は単方向です：A→B と B→A はそれぞれ独自の SPI、キー、シーケンス番号を使用します。IKEv2 の1回の Child SA 交渉では通常、このようなペアの SA が作成され、管理ツールはこれを1つの CHILD_SA として全体表示することがあります。IKE SA は双方のその後のコントロールメッセージを保護するため、その SPI と ESP の SPI を同じ番号空間として扱ってはなりません。strongSwan IPsec 入門

着信 ESP は、受信側が承認した SPI を使用してセキュリティ関連付けを検索します。SPI はパスワードでもユーザーIDでもありません。たとえパケットが SA に見つかったとしても、認証、リプレイチェック、ポリシー制約を通過する必要があります。正しい SPI が見えただけで、パケットを合法な業務として扱うことはできません。

Traffic Selector によってトンネルがどのように制限されるか

Traffic Selector には、アドレス範囲、プロトコル、ポート範囲が含まれます。発信側は広い範囲を提案でき、応答側はポリシーに基づいてより狭い範囲を受諾します。例えば、本社が 10.10.0.0/24 から支社 10.20.0.0/24 へのアクセスを提案した場合、最終的に支社のサーバー 10.20.0.8 の TCP 443 のみが許可されるのであれば、交渉成功を「支社サブネット全体の任意のポートがアクセス可能」と解釈してはいけません。

以下は、1方向で既に決定されたセレクタのマッチングのみを示しており、完全な IKE 交渉やカーネル SPD の優先順位はシミュレートしません。

from ipaddress import ip_address, ip_network

def protected_flow(src, dst, protocol, dport):
    return (ip_address(src) in ip_network('10.10.0.0/24')
            and ip_address(dst) == ip_address('10.20.0.8')
            and protocol == 6 and dport == 443)

assert protected_flow('10.10.0.9', '10.20.0.8', 6, 443)
assert not protected_flow('10.10.0.9', '10.20.0.8', 6, 22)
assert not protected_flow('10.10.0.9', '10.20.0.9', 6, 443)
assert not protected_flow('10.11.0.9', '10.20.0.8', 6, 443)
print('アドレス、プロトコル、ポートの共同マッチングの局所モデルが通過')

SPI が見つかったら、内側パケットを配信できるのか？

正しい SPI を送信用 SA の SPI に置き換えても、同一デバイスがそれを保存しているとしても、それはこの方向の着信状態として扱えません。復号後に宛先ポートを変更した場合、暗号学的チェックが通過しても、セレクタによって拒否される可能性があります。SPI は通行証ではありません。

ESP：可視フィールド、暗号化コンテンツ、認証

ESP は IP プロトコル番号 50 を使用し、AH は 51 を使用します。ここで言う数字はプロトコル番号であり、TCP/UDP ポートではありません。ESP は機密性と完全性を提供できますが、具体的な内容は交渉されたトランスフォームによって決まります。AH は認証を提供しますが暗号化は提供せず、選択された IP ヘッダフィールドをカバーし、NAT によるアドレス書き換えにより敏感です。すべての ESP 組み合わせを固定された1つの暗号化アルゴリズムとして記述することはできません。

Transport モードは通常、元の IP ヘッダの後の上位層コンテンツを保護します。Tunnel モードは、完全な元の IP パケットを内側ペイロードとして使用し、新しい外側 IP ヘッダを追加します。前者が元の IP ヘッダが完全に修正不可能であることを意味するわけではなく、後者が業務のエンドツーエンド暗号化を意味するわけではありません：ゲートウェイからゲートウェイへのトンネルは、相手側ゲートウェイで終了します。ESP RFC 4303

AES-GCM の3つの長さを混同しない

AES-GCM-ESP の nonce は、4 B の salt と 8 B の明示的 IV で構成されます。salt はキー材料の割り当て時に随伴し、各パケットで ESP ヘッダ内に 4 B のフィールドを再送信するものではありません。明示的 IV はパケット内に現れ、同一キー下では重複してはなりません。SPI とシーケンス番号は追加認証データに参加するため、任意に書き換えることはできません。

Tag のサポート長さは、具体的なトランスフォーム識別子によって決まります：RFC 4106 は 16 B のサポートを要求し、8 B または 12 B も許可しており、一律に「GCM の ICV は 12 B」と記述してはいけません。以下の例では 16 B Tag、最小4バイトアライメント、IPv4 オプションなし、UDP NAT-T を選択しています。追加のトラフィック隠蔽パディングはありません。AES-GCM-ESP RFC 4106

def esp_tunnel_size(inner, outer_ip=20, udp=True):
    padding = (-(inner + 2)) % 4
    total = outer_ip + (8 if udp else 0) + 8 + 8 + inner + padding + 2 + 16
    return total, padding

assert esp_tunnel_size(1000) == (1064, 2)
assert esp_tunnel_size(1000, udp=False) == (1056, 2)
assert esp_tunnel_size(1000, outer_ip=40) == (1084, 2)
assert max(n for n in range(1501) if esp_tunnel_size(n)[0] <= 1500) == 1438
assert esp_tunnel_size(1438) == (1500, 0)
assert esp_tunnel_size(1439)[0] == 1504
print('アルゴリズムとカプセル化の仮定が明確な ESP 長さ予算が通過')

1438 B は、このグループの仮定における最大完全内側 IP パケットであり、TCP アプリケーションペイロードではありません。内側 IPv4/TCP には、独自のヘッダをさらに差し引く必要があります。アルゴリズム、外側 IPv6、IP オプション、および他のトンネルの変化後には、再計算する必要があります。

シーケンス番号と受信リプレイウィンドウは、ある程度の順序不同を許容しつつ、重複パケットを拒否します。ESN は拡張シーケンス番号を使用しますが、オンライン ESP のシーケンス番号フィールドは依然として下位 32 ビットであり、上位ビットは状態から推測され、認証に参加します。リプレイウィンドウは信頼できる伝送ウィンドウではありません：失われた ESP パケットは、ESP によって自動的に再送信されることはありません。

IKEv2：保護キーを先に派生させ、その後身份認証を完了する

追加のチャレンジ、EAP、または拡張交換がない場合、初期確立は通常、IKE_SA_INIT と IKE_AUTH の2つのリクエスト-レスポンス交換、つまり約2ラウンドトリップタイム（RTT）を含み、計算時間が加算されます。Cookie、エラー DH グループのリトライ、認証方法、およびパケット損失は時間を増加させる可能性があり、すべての接続が一定の4パケットであると記述してはいけません。IKEv2 初期交換

IKE_SA_INIT 交換は、アルゴリズム提案、一時 DH 公開鍵、および nonce を行います。ここで共通秘密が得られても、相手の身份が証明されたわけではありません：身份検証は交渉記録にバインドされ、攻撃者と共有された暗号化チャネルのみが確立されるのを防ぎます。

IKE_AUTH の暗号化ペイロードには、身份、認証材料、および最初の Child SA に必要なパラメータが含まれます。外側 IP/UDP および IKE ヘッダは依然として可視です。AUTH は、署名または共有キーなどのメカニズムに基づいて行うことができ、「最初のメッセージに証明書秘密鍵で署名する」に限定されるものではありません。基本署名認証の入力には、相手の nonce と SK_pi/SK_pr で処理された身份ペイロードが含まれ、ハンドシェイクと身份の間のバインドを確立します。RFC 7296 §2.15

EAP 認証には複数の IKE_AUTH 往復が必要になる場合があります。IDi を宣言したからといって、EAP 身份認証が完了したわけではありません。認証が通過した後でも、その身份が対応するセレクタを要求できるかどうかをチェックする必要があります。

キー派生における順序と用途

基本 DH フローでは、g^ir を「自分の秘密鍵、相手の公開鍵」を使用して双方が計算した共有秘密とします。これは2つの公開 KE 値に対して直接 DH を行うものではありません。

prf+ は IKE で定義された反復展開関数であり、HMAC 結果を無限に繰り返すものではありません。展開された IKE 材料は、SK_d、両方向の完全性/暗号化、および身份認証補助用途のために順次使用されます。AEAD 組み合わせには、従来の完全性アルゴリズムのキーは別途必要ありません。SK_pi/SK_pr は証明書秘密鍵ではありません。RFC 7296 §2.13–2.17

最初の Child は IKE_SA_INIT の nonce を使用します。その後の作成は、対応する新しい交換の nonce を使用します。新しい DH がある場合、共有秘密は Ni/Nr 前 にあり、末尾に自由に配置できる付加フィールドではありません。基本最初の Child には独自の追加 KE 交換がないからといって、接続全体に一時 DH がないわけではありません。

NAT-T：UDP 4500 上で IKE と ESP をどのように区別するか

ネイティブ ESP には TCP/UDP ポートがないため、多くの NAT はマルチクライアント ESP マッピングを正しく維持できません。NAT-T は ESP を UDP でカプセル化し、4500 をよく使用します。IKE は通常、UDP 500 から確立を開始し、NAT の検出または機能条件に基づいて 4500 に切り替えます。4500 が見えただけでは、必ずしも NAT があるとは断定できません。MOBIKE などの動作もポートの使用に影響を与えます。strongSwan NAT トリaversal

したがって、前述の ESP 長さ予算には UDP ヘッダ 8 B のみが追加され、IKE 専用の 4 B マーカは追加されません。NAT keepalive はマッピングを維持し、保護された IKE アクティブチェックはピアの応答を確認し、これらは互いに代替できません。UDP カプセル化 RFC 3948

再鍵、再認証、およびアドレス移行

CREATE_CHILD_SA は、追加の Child を確立したり、既存の Child を置き換えたり、IKE SA の再鍵にも使用できます。基本交換は1つのリクエストと1つのレスポンスで、約1 RTT です。「0.5 RTT 未満で交渉が完了する」には、対応するプロトコルの保証はありません。

Rekey はキーと関連付けを更新しますが、証明書の現在の状態を再検証したり、ユーザー認証を再度実行したりするものではありません。Reauthentication は認証プロセスを再実行し、影響を受ける状態が異なります。実装は通常、新旧 SA を短時間オーバーラップさせ、進行中の旧パケットを受信させます。期限切れ、バイト/パケットカウント、リプレイシーケンス番号、および双方による同時再鍵の開始を処理する必要があります。strongSwan SA 更新

MOBIKE は、双方のサポートと交渉が必要となる IKEv2 拡張機能であり、トンネルが外側アドレスの変化に応じてパスを更新できるようにします。デバイスが「IKEv2」と記載されているからといって、移行が必ずサポートされているとは断定できません。これはアプリケーションに新しい身份を作成するものではなく、切り替え中のゼロパケットロスを保証するものでもありません。MOBIKE RFC 4555

証明書チェーンが大きい場合、IKE メッセージは MTU および断片化の制限を受ける可能性があります。IKEv2 の暗号化メッセージ断片化拡張機能は IP レベルの断片化とは異なり、ESP データパケットが PMTU を無視できることを意味するものではありません。IKE 断片化 RFC 7383

IKE 成功から業務成功へ

Linux のポリシーベース IPsec は、ポリシーに基づいてマッチングトラフィックをキャプチャします。XFRM インターフェースなどのルーティングベースのアプローチは、ルーティング管理をより直感的にしますが、依然として正しいポリシー、SA、およびインターフェースの関連付けに依存しています。インターフェースの作成やルーティングの追加自体は、暗号学的セッションを確立しません。strongSwan ルーティングベース VPN

swanctl --list-sas から実際の交渉結果を確認し、業務フローとルーティングと照合できます。Linux ip -s xfrm policy でポリシーを観察できます。SA 状態をエクスポートする際には、一部の生状態コマンドにキー材料が含まれる可能性があることに注意し、診断共有ではキーを出力しないサマリーを優先してください。パフォーマンスを判断する際には、実際のトラフィックとオフロードが有効かどうかに基づいて行い、「エンタープライズグレード」や「カーネル実装」という言葉だけでスループットの上限を直接導出しないでください。