IKEv2 SA は上がっているのに子 SA がない：交換を読む

IKE はトンネルが上がっていると言い、子 SA は存在しないと言うが、両方の記述は同時に正しいことがある。確立した制御関係はデータの関連付けではなく、二つのオブジェクトは寿命も交渉も障害の様式も別である。前者を接続性として報告すると、チケットは最終的に、トンネルは上がっているが何も動かない、と主張することになる。接続の要約ラベルではなく関連付けの一覧を読むべきで、その一覧だけが欠けているオブジェクトを見せてくれる。以下はその一覧が意味を持つ順序である。

二つの関連付け、二つの仕事

IKE SA は制御チャネル、すなわち識別子、鍵、そして制御交換そのものの提案を運ぶ。子 SA は ESP の保護を運び、独自のアルゴリズムと独自のトラフィックセレクタを持つ。認証と子 SA の作成は通常一緒に進むが、それは最初の子 SA が IKE_AUTH の内部で交渉されるからであり、その束ね方がまさに分離を人に意外に感じさせる。

これが、これから出会う二つの障害の形も説明する。初期交換で拒否された子 SA は通常 IKE SA も道連れに下げるので、確立した制御チャネルはまったく見えない。IKE SA が単独で残る場合はむしろ、最初の子 SA が成功し、その後の子 SA 作成の試行が失敗したことを意味することが多く、鍵更新のときなどである。タイムスタンプはどの設定レビューよりも速くこれらの事例を切り分ける。

どの層が拒否したか

子 SA が拒否されると、通知はどの層かを名指しする。提案の拒否は、両者がアルゴリズムで合意できなかったことを意味し、多くの場合、一方が別の完全前方秘匿のグループや相手が受け入れない暗号を要求している。セレクタの拒否は、トラフィック集合がそのまま拒否されたことを意味し、これは暗号ではなく範囲の議論である。

子 SA がないことが設計である場合もある。子なしの IKE SA は定義された拡張で、データの関連付けを要求時に作る場面で使われるから、不在は正しく、一致するトラフィックが来たときに子 SA が現れる。IKEv2 に関する strongSwan の注記 は要求時スタイルと、最初の事例を決める提案設定の両方を扱っている。

障害を診断する前に、要求時またはトラップの設定があるか確認する。子 SA が遅延して作られるなら、待機時に子 SA がないのは期待される状態であり、本当のテストはトラフィックが一つ立ち上げるかどうかである。このテストは遅延設計と無言の失敗も切り分け、作成に失敗すればトリガは単に待機しているのではなく答えを返さないままになる。

次にデータ経路を問う

子 SA が存在すれば、次の問いにはカウンタが答える。ip -s xfrm state は関連付けごとのパケット数とバイト数を報告し、トラフィックを生成しても何も運ばない子 SA は、欠けている関連付けではなく 一致か経路の問題 を指す。swanctl --list-sas はそのカウンタの隣に子 SA のセレクタを表示し、パケットが受け入れられた集合の内側にあることを確かめる。

認証の成功と子 SA 交換の失敗は、報告書では分けて書く。認証が失敗したという報告は次の技術者を証明書ストアへ送るが、正確な文はもっと短く、IKE SA は上がり、このフローの子 SA は決して受け入れられなかった、となる。

両端を突き合わせる

自分で運用するサーバなら、一時間離れた二つの再接続試行を比べるのではなく、同じ交換のクライアント側とゲートウェイ側のログを取る。通知は両側で一致するはずで、一致しない箇所があれば設定を誤った側が見つかったことになる。

子 SA の交渉を直し、そのうえで意図したセレクタの内側のトラフィックで再試験する。欠けていたオブジェクトがいま存在することを示す唯一の試験であり、待機中に更新された関連付け一覧は修正の前後で同じに見えることがあるからだ。