IKEv2 は一度のハンドシェイクではない — IKE SA、認証、そして CHILD SA
ゲートウェイの応答は到達性を示すだけで、身元は示さない。IKE_SA_INIT、IKE_AUTH、最初の CHILD SA の順に追い、トラフィックが流れる前に何が成り立つべきかを確認する。
IKEv2 の接続は、トラフィックが暗号化されて終わる一度の交換だと思うかもしれない。実際には少なくとも二度の交換があり、最初の交換は誰も認証しない。ピアは制御メッセージから始め、暗号パラメータで合意し、身元を証明し、その後にだけアプリケーションのパケットを運ぶ状態を交渉する。この順序が、ゲートウェイは応答しクライアントは接続済みと表示するのにプライベートなアプリケーションがタイムアウトする、というよく報告される食い違いを説明する。各段階が実際に何をし、その後に何が成り立つべきかを示す。
神話: ゲートウェイが応答すれば接続済みである
最初のメッセージへの応答は、端点が到達可能で話す用意があることを証明する。アカウントが受け入れられたこと、証明書チェーンが検証されたこと、何らかのデータポリシーが導入されたことは証明しない。
そうした失敗は後で起こり、異なる症状を生む。証明書の拒否や EAP の失敗は最初の交換がすでに成功した後に届くため、UDP 500 への ping やクライアントの緑のアイコンはほとんど何も語らない。
IKE_SA_INIT: 身元ではなくパラメータで合意する
最初の交換は IKE セキュリティアソシエーションの提案（暗号化と完全性のアルゴリズム、疑似乱数関数、Diffie-Hellman グループ）を運ぶ。ピアは nonce も交換し、双方がその値から生まれる共有秘密から IKE SA の鍵素材を導出する。この交換のどこにも、相手が誰かという情報はない。確立するのは、双方が同じ鍵を計算でき、一つの提案に合意しているという点だけである。どの提案も気に入らない応答側はここで交換を拒否するので、バージョンやアルゴリズムの不一致はサーバーが落ちているように見える。
この時点で作られた IKE SA は、以降のすべての管理交換を保護する。それが役割であり、あなたのパケットを守るのとは別の役割だ。
IKE_AUTH: 身元を証明し、最初の CHILD SA を構築する
次の交換は身元を運ぶ。証明書を使う場合、各ピアが自分の秘密鍵で署名し、相手が検証しなければならないチェーンを提示し、EAP を使う場合、応答側は選んだ方式で開始側にチャレンジを送る。ここでようやく、誤ったサーバー名、期限切れの証明書、拒否されたパスワードが表面化する。
通常の場合は IKE_AUTH が最初の CHILD SA も交渉するので、データ保護は同じ往復で合意される。開始側がトラフィックセレクタを提案し、応答側がそれを狭めるか拒否し、データ経路の鍵は IKE SA から導出される。つまり一つの交換が、身元ともう一つはポリシーという、まったく異なる二か所で失敗しうる。一般的なハンドシェイク失敗ではなく通知ペイロードやエラーを読むべきで、一方の修正は証明書、もう一方はサブネットの不一致だからである。
二つの SA、二つの役割
| アソシエーション | 保護する対象 | 有効期間の挙動 |
|---|---|---|
| IKE SA | 管理交換: 鍵の再生成、削除、設定ペイロード | 独自のスケジュールで再生成され、データ経路はその変更を生き延びられる |
| CHILD SA | トラフィックセレクタに一致するアプリケーショントラフィック | 独立して再生成され、多くの場合より頻繁に |
両者を分けて考えると、バグに見える二つの挙動が説明できる。トンネルが確立と表示されていても背後で鍵の再生成が失敗していることがあり、CHILD SA はクライアントが接続を切らずに置き換えられる。
strongSwan では、IKEv2 設定リファレンスとswanctl --list-sasが両方の階層を示し、ip xfrm stateにip xfrm policyを加えると、カーネルが実際に何を導入したかがわかる。この二つの見方を比べるのが、交渉が完了したのか、完了したように見えただけなのかを知る最速の方法だ。デーモンがカーネルに状態のない CHILD SA を一覧に出すなら、導入は静かに失敗している。カーネルがデーモンの知らない状態を保持しているなら、以前の試行の残骸を見ている。
トンネルが上がった後も成り立つべきこと
トラフィックセレクタは、どのアドレスが対象になるかを定義する。クライアントがあるサブネットを提案し、サーバーが別のサブネットを期待しているなら、CHILD SA は導入されるが役に立つものは何も運ばない、エラーは交渉の問題ではなくルーティングの問題として現れる。次にローカルスタックが協力する必要があり、ホストがルーティングする場所で転送を有効にし、トンネルを指すルートを置き、カプセル解除されたパケットを許可するファイアウォール規則を用意し、プライベート名が関わるなら内部リゾルバを用意する。これらはそれぞれ別に失敗し、どれも IKE デーモンの再起動では直らない。
診断中はログを見えるようにしておき、まず初期交換、次に身元の検証、適用される場合はユーザー認証、次に CHILD の導入、最後にアプリケーショントラフィックを確認する。止まった段階が直すべき段階であり、後から起きたルーティング障害は、すでに通過した身元チェックを緩める理由には決してならない。