サイト間 VPN で記録すべきこと：セレクターと範囲

トンネルを導入して半年後、新しいサブネットがポリシーに一致しなくなり、共有上の唯一の文書にはオフィス VPN とだけ書かれている。これがセレクター記録で防ぐ障害であり、具体的には、アドレス集合が変わったのに書類が変わっていないというものだ。記録を正しく書くには、いくつかあるアドレス集合のどれを説明しているのかを把握し、自分が設定したものではなく、相手側が実際に適用しているものを記録する必要がある。

設定とネゴシエーションは別物

ポリシーベースの IPsec トンネルでは、各側が子アソシエーションの送信元と宛先の範囲というトラフィックセレクターを提案する。 応答側はその提案を狭めることができる , そのためインストールされたアソシエーションは設定に列挙された範囲より狭いことがある。設定を写した記録は意図を説明するもので、現在の保護範囲ではない。両者は静かに食い違い、トンネルの状態ページにはそれを示すものがない。

両方の列を、観測した日付とともに残す。設定されたセレクターは意図したものであり、ネゴシエートされたセレクターはカーネルが今適用しているものだ。両者が異なるとき、その差はルーティングの不具合よりもはるかに多く、予想外の障害を説明する。

ひとつのアソシエーションは、設定されたすべての組を表すわけでもない。複数のセレクターの組み合わせを持つトンネルは複数の子アソシエーションになることがあり、そのひとつだけを列挙した記録は不完全な一覧だ。要約するのではなく、すべて列挙する。

ルートベースのトンネルは選び方が違う

ルートベースのインターフェースでは、ルーティングテーブルがトンネルに入るものを決め、セレクターは意図的に広くできる。それは手抜きではなく正当な設計であり、記録もそのように説明しなければならない。ルート、それが向かうインターフェース、どのサービスに到達できるかを制限するファイアウォールポリシーを書き留める。保護範囲は意図的に広く、絞り込みはサービス範囲が担う。

ポリシーベースのひな形をルートベースのトンネルに写すと、導入が使っていない仕組みを説明する文書ができる。次の技術者はそこにあるはずのないセレクターを探し、単に文書化が拙いだけなのにトンネルの設定が誤っていると結論づける。

変換も同じ表に入れる

NAT が相手側に別の範囲を見せるときは、元のプレフィックスと変換後のプレフィックスを一緒に記録し、セレクターとアクセスルールがそれらを照合する段階も書き留める。順序が、遠い側が書いたアドレスをそもそも見るかどうかを決めるからだ。ふたつの範囲の片方しかない表は、完全に見えるため、表がないより悪い。

これが NAT 変更後に動いていたトンネルを壊す細部であり、セレクターは依然として元のプレフィックスに一致し、相手側は変換後のものを受け取り、その戻りルートはもう存在しないアドレスを指す。両者が一致しなくなった瞬間、何もエラーを記録しない。

プライベート DNS も同じ場所に入る。該当サイトから使えないアドレスに解決する名前は、サポートチケットが付いた文書の誤りであり、トンネルのせいにされる。

サービス要件を添える

保護範囲は許可リストではない。どのサービスがどの送信元から到達できるべきか、その背後にあるアプリケーションを誰が所有するかを書く。このふたつの項目は別の問いに答えるもので、混同するとセキュリティレビューがアクセスではなくルーティングを論じることになる。

次に、そのルールを維持するネットワーク管理者を名指しする。所有者のないセレクター一覧は静かに古くなり、深夜にトンネルが切れたとき、古いものと誤ったものは区別できない。所有者は、変更が意図的だったと確認できる人物でもある。

記録をテスト計画に変える

必要な経路ごとに代表的な送信元と宛先のホストを選び、期待されるルート、サービス、応答ゲートウェイを書き留める。これで文書は説明ではなくテスト計画になる。下のコマンドで現在のアソシエーションを読み戻し、書き留めたネゴシエート済みの行と比較する。

swanctl --list-sas

五行の骨組みで記録を正直に保つのに通常は足りる。下の版は変更チケットに切り詰めずに収まる：

sites: office <-> dc1
configured selector: 10.10.0.0/16 <-> 10.20.0.0/16
negotiated selector: 10.10.4.0/22 <-> 10.20.0.0/16
translated range: 172.16.4.0/22 -> 10.10.4.0/22
service and owner: erp:443 / finance-netops

ゲートウェイだけへの ping は受け入れテストではない。通過経路を決して通らないため、転送されるすべてのフローが失敗していても通ることがある。片側のホストからもう片側のサービスへテストし、応答がトンネルを通って届くことを確認する。ping だけが通るなら、記録はまさに防ぐために書かれた転送の問題を見つけたことになる。 strongSwan の転送に関する文書 Linux のピアでセレクター、ルート、転送がどう相互作用するかを説明している。