プロキシIDとは
Proxy ID とは、乱暴に説明すると、IKEv1 のフェーズ 2 で交換される『セレクタ』そのものを指します。IKEv1 用語では Proxy ID と呼びますが、IPsec 用語ではセレクタと呼びます。
セレクタとは『1. ローカル NW アドレス』、『2. リモート NW アドレス』『3. プロトコル(TCP/UDP)』、『4. ローカルポート番号』、『5. リモートポート番号』のセットです。3～5は any となるケースが多く、その場合は省略されます。
IKEv1 で交換された Proxy ID は、IPsec の SPD の中にあるセレクタとして使われます。ルータに入ってきたパケットについて『IPsec で保護して通信するか』、『そのまま通信するか』、『破棄するか』の Action を決定します。
実はこの Proxy ID は RFC では明確には定められていません。厳密に言うと、RFC draft 版で議論されている中で消えた言葉です。
RFC 2409 の draft 第1版では以下のようにあります。
Proxy negotiation-- in which the negotiating parties are not the
endpoints for which security association negotiation is taking
place-- is supported.
IKE では IPsec 以外の用途にも使えるように仕様を切り離して考えているため、トンネルモードやトランスポートモードという記述がありませんが、要は、IPsec のトンネルモードとして使うときには IKEv1 では Proxy negotiation を使うよ、ということを言っています。
また、5.6.2 Phase 2 using Oakley Quick Mode の IKEv1 パケットフォーマットの中には以下の記述があります。
ID of source for which ISAKMP is a proxy
ID of destination for which ISAKMP is a proxy
これが Proxy ID です。つまり、フェーズ 2 (Quick モード) では送信元と宛先の Proxy ID を提示することになっています。
これらが RFC 2409 最終版にはそれぞれ以下のように変わっています。
Client negotiation is supported. Client mode is where the
negotiating parties are not the endpoints for which security
association negotiation is taking place.
ID of source for which ISAKMP is a client
ID of destination for which ISAKMP is a client
Proxy という言葉が Client に置き換わっています。ですが Proxy ID という言葉がベンダ実装の用語として使われているのです。
フェーズ2 失敗のよくあるケース Proxy IDの非対称性
IKEv1 においてはこの Proxy ID (Client ID) は両端で対称になるように揃えないとフェーズ 2 に失敗するケースがあります。
ケースがある、というのは単にメーカーが Proxy ID の一致を必須とするかどうか次第、ということです。この辺りは RFC には明確な記載はありませんが『ID ならば両者での共通認識であるべき』という主張も理解はできます。こういう曖昧な仕様、意見の相違も IPsec をややこしくしている原因の1つなのですが。
例えば以下の構成において R1 が 10.1.1.0/24 を持ち、かつ、インターネット接続を持つ本社のルータ、R2 が10.2.2.0/24 のみを持つリモート拠点のルータであるとします。このケースにおいて、R1 では Local を 10.1.1.0/24 にしているのに対し、R2 で Remote を 0.0.0.0/0 にしてしまうと Proxy ID の非対称性が生まれ、エラーが発生し、フェーズ2に失敗します。エラーのメッセージは『invalid proxy IDs』や『incorrect proxy IDs』等メーカーによって様々です。
例えば YAMAHA ルータ は Proxy ID を設定もできるし設定無しにもできるという、日本人らしい造りをしています。
そしてこのような反省から、IKEv2 (RFC4306) では Proxy ID の代わりに『トラフィックセレクタ (TS) 』という概念が明確に定義されました。
"2.9 Traffic Selector Negotiation" に以下のように記載されています。
The first of the two TS payloads is known as TSi (Traffic Selector- initiator). The second is known as TSr (Traffic Selector-responder). TSi specifies the source address of traffic forwarded from (or the destination address of traffic forwarded to) the initiator of the CHILD_SA pair. TSr specifies the destination address of the traffic forwarded to (or the source address of the traffic forwarded from) the responder of the CHILD_SA pair. For example, if the original initiator request the creation of a CHILD_SA pair, and wishes to tunnel all traffic from subnet 192.0.1.* on the initiator's side to subnet 192.0.2.* on the responder's side, the initiator would include a single traffic selector in each TS payload. TSi would specify the address range (192.0.1.0 - 192.0.1.255) and TSr would specify the address range (192.0.2.0 - 192.0.2.255). Assuming that proposal was acceptable to the responder, it would send identical TS payloads back.
また、その直後に以下の記載があります。
The responder is allowed to narrow the choices by selecting a subset of the traffic, for instance by eliminating or narrowing the range of one or more members of the set of traffic selectors, provided the set does not become the NULL set.
これはローカルとリモートのアドレス帯が対称となるよう、TS の範囲をネゴシエーションすることが定義されています。つまり、Proxy ID に相当するものが対称になるように自動調整してくれるのです。
ただし、あくまで狭める方向にしかならないので、上記のケースだと R2 のリモート拠点からR1 経由のインターネット接続はできない状態で IPsec が構成されます。
ともあれ、フェーズ 2 で失敗する場合はポリシーが対向で対称になっているかを確認しましょう。または、IKEv2 への設定変更もよいです。
ポリシーベースとルートベース
ベンダの IPsec 実装でポリシーベースとルートベースという言葉があります。これも RFC では定義されていない言葉です。というよりも、RFC ではポリシーベースが前提で作られています。ルートベースはベンダ主導でそのポジションを獲得した実装です。
ポリシーベース IPsec では、パケットがルータに入ったタイミングでまずは SPD によるポリシー精査が走ります。要はポリシーベースルーティングです。
なので IPsec 保護対象はルーティングテーブルを見ません。例えば以下の記事の例では VyOS 間のポリシーベース IPsec を構成していますが、対向 NW の 10.1.1.0/24 や 10.2.2.0/24 のルーティング設定は書いていません。
一方、ルートベース IPsec では、SA をトンネルインタフェースで接続します。そしてパケットがルータに入るとまずはルーティングテーブルを見て、NextHop がトンネルインタフェースだった場合は SPD によるポリシー精査が走りますが、ここでは基本的に全てを IPsec 保護対象とします。
ルートベースにすると、ポリシーベースのような『そのまま通信するか』、『破棄するか』といった選択肢が無くなり、全て『IPsec で保護』となりますが、そもそもポリシーベースでも『そのまま通信するか』、『破棄するか』という選択肢はほぼ利用されません。
『破棄するか』というのはファイアウォールの仕事ですし、『そのまま通信する』という選択肢はルートベースでもカバーできますので特に困ることはありません。
一方、トンネルインタフェースによるルートベース IPsec を構成するメリットとしては、大きく 2 つあります。
1 つは、RIP や OSPF 等のダイナミックルーティングを構成できることです。
ポリシーベースではルート情報がルーティングテーブルに乗らないのでルート情報を伝搬できませんが、ルートベースならばトンネルインタフェースを通じて伝搬が可能です。
もう 1 つは、Proxy ID というややこしい話に巻き込まれずに済むことです。
Cisco や PaloAlto 等のルートベース IPsec の実装では、デフォルトで Proxy ID を 0 に揃えてくれます。
例えば PaloAlto の以下ページから引用すると、
プロキシ IDが設定されていない場合、Palo Alto Networks ファイアウォールはルート ベースのVPNをサポートしているため、プロキシ IDとして使用されるデフォルト値は、"source ip: 0.0.0.0/0, destination ip: 0.0.0.0/0 and application: any"となり、
当然、対向も同じ all 0 に揃える必要はありますので、その点は注意が必要です。
IT/インフラエンジニアの地位とスキル向上のために
あなたが成長の日々を歩めますように。
コメント