二つのクライアントグループ、一台のサーバー：ポリシーをどこで強制するか

二つのクライアントグループを別々のサブネットに置くと分離に見えますが、そうではありません。アドレスはパケットがどこから来たように見えるかを示し、許可はそれを転送する者が下す判断です。この問いに答えるのはマスクではなく設定なので、ルールを書く前に、どのコンポーネントがピアのトラフィックを転送するかを決めてください。

サブネットはラベルであり、ルールではない

グループごとに一つのプールを割り当てても、読みやすいアドレスが得られるだけで、それ以外は何も得られません。追加のルートを受け入れたクライアントは到達性を得たのであり、到達性は認可ではありません。通信の許可は転送の判断にあり、それはサーバーの設定に応じてデーモンかカーネルに存在します。

アドレスの所有が、プレフィックスをグループセレクターとして使えるようにします。認証された各アイデンティティは予測可能なアドレスまたは範囲に対応する必要があり、複数のデバイスが一つの資格情報と一つの割り当てを共有した時点でその対応は破綻します。送信元プレフィックスに頼る前にアイデンティティと同時性を解決してください。どのマシンが呼び出しているかを推測するポリシーは、最悪の瞬間に間違った相手を認可します。

ピアのトラフィックを運ぶ経路を選ぶ

デーモンが自身のプロセス内でピアのパケットを転送する場合、そのパケットはホストの転送フックに決して届かないため、カーネルのルールはそれを見られません。その内部転送を無効にすると、カーネルが転送ポイントになり、通常の転送ルールが適用されます。

# peer forwarding inside the daemon: enforce with per-group policy instead of FORWARD rules
client-to-client
# kernel forwarding path: remove the line above, then filter in the forward chain

オフロードされたデータチャネルや製品が管理するサーバーは独自の強制モデルを公開しているので、コミュニティの挙動を前提にせず、どれを実行しているかを確認してください。避ける価値のある失敗は、レビューでは正しく見えるのに実行時に決して参照されないルールです。

ルールを書く前にマトリクスを書く

短いマトリクスはルールセットよりレビューしやすく、実装が満たすべき契約です。同じグループのピアは許可、グループ間のピアは拒否、両グループは名前付きの共有サービスへ許可、それ以外はすべて拒否。ファイアウォールエディターを開く前に、この四行を書き出してください。ルールの構文を読めないレビュー担当者でもマトリクスは確認できます。実装はその行に一致させるだけです。

書くときは三つの宛先クラスを分けておきます。VPNホスト上のサービスはローカル入力、別のクライアントはピアの通過、ゲートウェイの背後にあるマシンは別の転送経路です。一つの寛大なルールが誤って三つすべてを許可し、グループポリシーが余計な手順を伴うフラットなネットワークに変わるのです。各行の隣にクラスを書いて、意図が次の編集でも残るようにしてください。

ルールを生き残る場所に置く

判断はファイアウォールの残りを保守している同じ場所に、そうでなければ飲み込んでしまう許可ルールより前に追加します。ルールの順序はポリシーの一部であり、広い許可の後に置かれた正しいルールは何も強制しません。変更の前後でルール番号を記録してください。エディターにはあるが実行中のルールセットにないポリシーは計画であり、制御ではありません。

ポリシーが変わったとき既存のフローがどうなるかを決めてください。変更前に開かれたセッションは変更後も動き続けることがあります。退会したメンバーが即座にアクセスを失う必要があるなら、接続が自然に閉じるのを待つのではなく、その状態を終了させる手段をルールセットに持たせてください。

ファイアウォールの残りを所有する仕組みを通じてルールを永続化し、そのそばにマトリクスを記録します。記録されていないポリシーは次のインシデントの際に記憶から再導出されます。たいてい急いでいる人によって。

両側から証明する

各グループの一台のクライアントから、同一グループ内の到達性、グループ間の失敗、共有サービスをテストします。一台のクライアントからの一回のテストではマトリクスの半分しか証明できず、省かれる半分がたいてい間違っている側です。拒否の方向は二回繰り返してください。キャッシュされたセッションが強制の誤りを隠すことがあるからです。どのペアをテストしたかを記録し、次の人が繰り返さないようにします。

トンネルがIPv6を運ぶなら同じ確認をそのプロトコルで繰り返し、通常のアプリケーション認証はそのままにしてください。送信元プレフィックスはアカウントではないので、ネットワークポリシーを通過しても、サービスが呼び出し元を信頼すべきという意味にはなりません。