二つの /24 ではなく一つの /23：ネゴシエーションで何が変わるか

隣接する二つの /24 はきれいに一つの /23 にまとまる。その整った算術が、変更は見た目だけだと人々を納得させる。これはアドレスについての算術であり、トンネルが気にするのはセレクタ、すなわちネットワークの記述ではなくネゴシエーションの提案である。短い行は、同じトラフィックを保護したままにすることも、意図より広く保護することも、半分しか覆えないこともある。どれになるかは、両方のピアが何を受け入れる用意があるかで決まる。三つのうちどれが起きたかを知る唯一の方法は、インストールされた結果を読むことだ。

人が一つに混同する三つの事実

アドレス集合は、どのホストを保護するかを示す。グルーピングは、そのアドレスをどう提案するかを示す。セレクタ一つか複数か、アソシエーション一つか複数か、ということだ。交渉された結果は、両方のピアが実際にインストールした内容を示し、最初の二つより狭いことがある。

変更記録には別々に書く。設定一行が三つの異なる答えを隠していることはよくある。それらを分けられないレビュアは、変更を承認することもできない。

レスポンダがあなたの集約に対してできること

IKEv2 のレスポンダは、提案されたセレクタの組を、自分が受け入れられる部分集合に狭めることができる。受け入れられるものが何もなければ、提案をそのまま拒否することもできる。また、追加のトラフィックはこのアソシエーションに収めるのではなく別のアソシエーションが必要だと示すこともできる。

何も受け入れないレスポンダは、代わりにエラーを返す。少なくとも、提案が黙って狭められたのではなく拒否されたことが分かる。

つまり、交換が成功したのは両者が何かに合意した証拠であり、列挙したすべてに合意した証拠ではない。最初の成功メッセージは結果を読むための出発点であり、結論では決してない。受け入れられた部分集合は一つの /24 より小さいこともあり、その場合インストールされた集合は提案とは似ても似つかないものになる。

集約が静かに境界を消す場所

二つの /24 は異なるサービス規則を持ちうる。片方が管理プロトコルだけを許可し、もう片方が一般的なアプリケーションを許可しているかもしれない。IP 層で両方のアドレスを覆うセレクタは、その規則を保存しない。集約は境界を、トンネルの後ろにある何らかのフィルタリングへと移してしまう。集約する前にサブネットごとのサービス規則を列挙すること。そうしなければ、その比較は決して行われない。

プロトコルとポートの値はセレクタの一部であり、任意の追加項目ではない。元のポリシーがそれらを制限していたなら、集約も同じ制限を引き継がなければならない。そうでなければ、その変更はルーティングの衣装を着た権限変更である。制限が元のポリシーの要点だったなら、集約の後も明示的に保ち、記録にもそう書く。

プレフィックスごとに結果を読む

変更後は、設定されたものではなくインストールされたものを見る。次に、各プレフィックスから各方向へフローを生成し、それを扱うアソシエーションに属するカウンタを確認する。一つのアソシエーションでトラフィックを生む二つのプレフィックスは問題ない。片方が何も生まない二つのプレフィックスが、まさに発見である。

これはユーザーが使っているのと同じアプリケーションで行う。 ゲートウェイで発生するプローブは、その背後のクライアントとは別の経路を試し、その違いこそがセレクタのバグの潜む場所だ。本来なら忙しいはずのプレフィックスでカウンタが動かないことは、不在を測っているがゆえに、どのログ行よりも強い証拠になる。

変更を元に戻せるようにする

新しいポリシーがすべてのプレフィックスの組み合わせから試されるまで、元のポリシーを設定に残しておき、各フローがどのアソシエーションに落ちたかを記録する。提案が変わるとピアがアソシエーションを置き換えるなら、ロールバックは古い提案を復元しなければならず、古いアドレスだけでは足りない。

ウィンドウが開く前に、もう一方の端点の所有者と調整する。片側が自明と考える集約が、もう片側では受け入れられないグルーピングかもしれず、変更の最中にそれを知るのは高くつく。提案するグルーピングを書面で合意し、それを交換がインストールする内容と比較する。その合意は変更チケットに残し、来週には消えるチャットのスレッドに置かない。