pfSense の静的トンネルアドレス：優先か予約か

二つの設計は紙の上では似て見えるが、ルールがそれらに依存すると大きく異なる振る舞いをする。一方はクライアントオーバーライドにアドレスを打ち込み、そのアドレスを身元として信頼する。もう一方は動的な受け入れを完全に閉じるので、端点は一意の割り当てを持つか、さもなければ接続しない。アドレスを防御できるポリシー入力に変えるのは二番目だけで、ファイアウォール規則を一つ書く前にこの違いを理解する価値がある。

オーバーライドアドレスが実際に約束するもの

クライアント固有のオーバーライドはクライアントごとのオプションを運び、その中に優先トンネルアドレスが含まれる。Netgate はそのアドレスを予約ではなく優先と説明しており、つまり動的プールはそのアドレスを他の誰かのために手放さない。

通常はこれで問題ない。衝突はまれで、クライアントは普通は要求したとおりのものを受け取り、それは利便性には十分で認可には足りない。利便性と認可は別の要件であり、衝突を生き延びるのは片方だけだ。

サブネットトポロジでは、このフィールドはクライアントアドレスとサーバーネットワークのマスクを一緒に受け取るので、10.90.0.0/24 トンネル内のアドレスは 10.90.0.10/24 と書く。

そのどれも番号を予約しない。オーバーライドが一致しないクライアントや重複セッションはプールの別の場所に落ちることがあり、アドレスを鍵にしたルールはそのとき、そこにいない誰かを記述することになる。

範囲を限定した既定で動的経路を閉じる

代替は静的専用サーバーであり、受け入れたすべての端点が自分の身元と自分の一意なアドレスを持ち、それ以外は入らない。

実装は、その一つのサーバーに限定し、接続ブロックを有効にした DEFAULT オーバーライドになる。一致するオーバーライドを持たないクライアントは、通常の動的受け入れに戻れなくなる。この一行が優先を閉じた集合に変える。

範囲が重要だ。装置上のすべての VPN インスタンスに既定オーバーライドを適用すると、無関係なトンネルを締め出し、その故障はポリシー決定ではなく壊れたサービスに見える。適用先は、受け入れモデルを変えているその一つのサーバーに限る。そして、次の人がそれがどのトンネルのものか覚えていないのだから、範囲を変更記録に残すべきだ。

その後で許可集合全体を監査する。既定ブロックはアドレスを与えられずに残った名前付きオーバーライドを直さないし、その端点は理由の手がかりもなく単に接続に失敗する。

サーバーが実際に使う身元に合わせる

オーバーライドは何かに一致する。証明書のコモンネームで照合するサーバーでは、オーバーライド名はそのコモンネームでなければならず、人の表示名ではない。アカウント一覧からではなく証明書からコピーする。

ユーザー名をコモンネームとして使うよう設定されたサーバーはまったく別の鍵で照合するので、証明書にちなんで名付けたオーバーライドは決して発火しない。設定を読み、アカウント一覧の表示から推測してはいけない。

配備が要求する追加の認証要素は残す。閉じたアドレスモデルが変えるのは、誰が接続でき、どのアドレスを受け取るかであり、証明書の検査や第二要素を置き換えるものではない。

対応表が堅くなってからアクセスルールを書く

身元からアドレスへの対応表が閉じれば、ルールはアドレスを人のように装わずに参照できる。ある人の端点をまとめた別名は特定のサービスに届き、別の別名は別のものに届く。別名がレビュー可能な対象になり、アドレスはその内部の実装詳細になる。

宛先とポートは明示する。トンネルプール全体からローカルネットワーク全体を許可するのは、この演習が置き換えるはずだった設計そのものだ。

フローティング、グループ、インターフェースのルールは、先の広い通過が後の狭い通過を打ち消すので、実際の評価順で読む。クライアント間の内部転送を切ると、ピア間の通信はそれらのルールをレビューする境界にとどまる。紙の上にしかないルールは執行ではない。

否定のケースを試す

新しい接続を四つ試す。名前付きの端点、オーバーライドがまったくない端点、到達できるべきサービス、到達すべきでないサービスだ。一覧にない端点が重要なケースで、設計はそれを止めるために存在し、それが接続できてしまうなら既定ブロックは仕事をしていない。

IPv4 のアドレス方針は第二のスタックについて何も語らないので、IPv6 は別に確認する。そのうえで、アプリケーションが依然として利用者を認可していることと、トンネルアドレスがネットワークの事実であり誰がキーボードの前にいるかの証明ではないことを確かめる。どちらの確認も受け入れ記録に入れる。

最後に移行を計画する。新しいオーバーライドと狭いルールはすでに確立したセッションを遡って変えないので、既存の状態は期限切れにするか意図的に消す必要がある。