IPsec のトラフィックセレクタ：何を覆い、何を覆わないか

トラフィックセレクタは、IPsec の合意が保護する内側のトラフィックに名前を与えるもので、その組は前提ではなく交渉で決まる。二つの端点は互いを完全に認証できても、どのパケットがトンネルの内側に属するかで食い違うことがある。その食い違いは接続状態には現れず、状態はたいてい健全なトンネルを報告する。セレクタを両端から読み、そのうえで一つの宛先を追えば、どれだけポリシーを編集するよりも早く見つかる。

両端から読む

各端点は自分の側をローカル、相手側をリモートとして記述する。そのため同じプレフィックスの組が二つの設定では入れ替わって見えるが、それは正しいことで矛盾ではない。視点を反転させるのが、動いている合意が紙の上で間違って見えるときにまず行うことだ。二つのファイルを入れ替えずに並べて比べると、存在しない不一致を作り出してしまう。

値はいつも単一のサブネットとは限らない。IKEv2 のセレクタはアドレス範囲、プロトコル番号、ポート範囲を運ぶことができ、そうやってポリシーはネットワーク全体ではなく一つのサービスを守る。意図したトラフィックより狭いセレクタは、一部の宛先だけを運び、ほかを黙って除外するトンネルを生む。

何かを変える前に、両側を一つの表に書き出す。この作業でたいていは設定ファイルに触れずに疑問が片づく。

狭めるのは応答側の判断

開始側が提案し、応答側は部分集合しか受け入れられない。IKEv2 では応答側が提示されたトラフィックセレクタを狭めることができ、実際にインストールされるのは狭められた結果だ。したがって開始側の設定を読んでも分かるのは提案であって、合意ではない。

だからこそ、クライアントに追加したサブネットが、新しい宛先を依然として拒む動いているトンネルを生むことがある。サーバは自分のポリシーが許す範囲まで提案を狭め、一方でクライアントのファイルはより広い範囲を並べたままになっている。交渉済みの状態だけが真実を示し、Linux では ip xfrm policy と strongSwan の IKEv2 ドキュメントにある child SA の一覧が、要求された内容ではなく実際にインストールされた内容を報告する。両者が食い違うとき、変えるべきは応答側のポリシーだ。

拒否された提案は、狭められた提案とは別の症状だ。拒否は交渉ログに現れ、child アソシエーションをまったく残さない。

一つの宛先を端から端まで追う

実際の宛先と、クライアントがそれに使う送信元アドレスを選び、その組を三つの独立した判断に通す。ルートが経路を選び、セレクタがその経路が保護されるかを決め、ファイアウォールがパケットが許可されるかを決める。それぞれが単独で失敗しうるし、広いセレクタはほかのどれも直さない。

ip route get 10.20.30.41
ip xfrm policy list
swanctl --list-sas

ルート照会は、パケットを運ぶインターフェースと送信元アドレスを示す。ポリシー一覧は、その組に一致するトンネルポリシーがあるかどうかを、方向とレベルも含めて示す。SA 一覧は交渉済みの child セレクタをカウンタとともに示すので、通信を試した後にパケットがゼロの child アソシエーションは、送っているものを除外しているセレクタの特徴だ。三つのコマンド、三つの異なる答え、そして黙った破棄を説明するのはそのうち一つだけだ。

child のカウンタが動いているのにアプリケーションが失敗し続けるなら、問題はトンネルの先にある。それは調査をセレクタではなく、遠いホストのリスナーやファイアウォールへ移す。

二つの目的を分けておく

オフィスのサブネットを守ることと、すべての閲覧を遠隔の出口から出すことは、別のセレクタを持つ別の要件だ。片方に合わせて作ったプロファイルがもう片方に合うことはまれで、混ぜると漏えいか壊れた分割のどちらかになる。保護範囲を広げることは両端とその転送ポリシーを変えることを意味し、片側だけの変更は拒否された提案になる。小さな編集のあとに動いていたトンネルが動かなくなる、いちばんよくある道筋がこれだ。

セレクタは暗号学的な適用範囲を記述し、ルートは経路を選び、アプリケーションは自前の許可を強制する。すべてを覆うトンネルでも loopback に結びついたサービスには届かず、トンネルへ向かうルートにも宛先を含むセレクタが要る。同じ試験要求に対して三つを確かめれば、食い違いが自分から名乗る。