広い IPsec セレクタは全サービスへの許可ではない

二つのピアがサブネット全体を保護することに合意し、誰かがその合意を、その中のあらゆるサービスに到達する許可だと読み違える。これが俗説である。セレクタはトンネルが運ぶ用意のある通信を示すだけで、組織がどのサービスを許可するかについては何も語らない。二台の機器が広いアドレス範囲を正当に交渉し、その内側のアクセスポリシーが二つのポートだけを許可していても、両方の記述は同時に成り立つ。

保護範囲は許可ではない

トラフィックセレクタはトンネル合意の一部である。ピア同士が何を暗号化するかを狭めるか確認するもので、両側に運ぶフローが多いときには広いセレクタのほうが運用が簡単なことが多い。サービスフィルタは経路の別の地点にある別の制御であり、パケットが復号された後に実際に何を使えるかを決める。テストを一つ通すためにフィルタを外すのは、ポリシーの判断を事故に変えることだ。

設計文書では二つの記録を分けておく。セレクタだけを見た読み手は、与えられていない許可を推測するからだ。変更記録の二行がそれを防ぎ、その後の議論より短い時間で済む。

一つのフローを両端から記述する

開始側、応答側、提示されたままの送信元と宛先、プロトコル、両方のポートを書き出す。次にその各ラベルを反対側の端点のために反転させる。クライアントの一時的な送信元ポートは応答の宛先ポートになり、遠隔ネットワークはローカルネットワークになるからだ。この反転なしに片側から他方へ設定をコピーすることが、フィルタが結局まったく逆の方向を許可してしまう原因である。表を一度書いて、そこから両方のフィルタを組み立てる。

何かをコピーする前に選択モデルを合意する。ポリシーベースの設計とルートベースの設計は、同じ意図を異なるオブジェクトで表すからだ。フローの横にモデル名を書く。さもないと次の技術者は、決して比較できなかったオブジェクトを突き合わせて半日を費やす。

実際に適用されているフィルタを見つける

ASA では、VPN フィルタはグループポリシーに結び付いた ACL で、復号後かつ暗号化前のトラフィックに適用される。Cisco のグループポリシーの文書は継承についても説明しており、グループポリシーの値を打ち消すユーザーレベルの値も含まれる。したがって、編集した ACL が目の前のセッションを統制している ACL とは限らない。ユーザーオブジェクトも同様で、目に見える痕跡をあまり残さずにグループを上書きできる。

変更したと記憶しているオブジェクトではなく、実際に有効なセッションを調べ、どのポリシーオブジェクトがそれを与えているかを記録する。この一手間で、フィルタは正しいのに動かないという報告の驚くほど多くが解決する。

方向、ポート、そして逆方向の場合

文書化された慣例では、遠隔ネットワーク、または割り当てられた遠隔クライアントのアドレスを送信元の位置に、ローカルネットワークを宛先の位置に置き、応答はアドレスの位置を入れ替えて表す。ポートの規則はこの慣例の上に載っており、アドレス以上に注意を要する。

文書化されたモデルでは、宛先ポートの規則が、同じ送信元ポートを使う逆方向の開始に影響しうる。つまりフィルタは、無害な応答が付いた一方向の要求規則ではない。開始の両方向を明示的に検討し、拒否するつもりの場合も含める。

同じ文書はフィルタを初期接続に限定しているので、検査対象のアプリケーションが開くあらゆる二次チャネルを一律に強制するものではない。完全なポリシーにその範囲が必要なら、それは目的を超えて引き伸ばした ACL ではなく、別の境界に属する。

終わりと呼ぶ前に三つの場合を試す

意図したフローを受け入れ、ポリシーが禁じるサービスを拒否し、検討した逆方向の場合を実践する。展開するのと同じ識別情報とセレクタを使って、承認された計画の下で実行する。許可されたサービスが動くことだけを示すテストは、トンネルを証明するのであってポリシーを証明するのではない。

交渉された範囲とアクセスの判断を二つの記録として保つ。VPN が何を許すかを説明するには両方が要るからだ。