VPN で接続した 2 拠点間のアクセスを制限する方法

サイト間トンネルは、二つの拠点がパケットを交換できるかという一つの問いに答えるだけで、どの拠点機器がどの中央サービスに到達できるのかという重要な問いを開いたままにします。トンネルを相互信頼とみなすと、ゲストのノート PC が財務サーバーと同じ経路に乗ってしまいます。解決策は優れたトンネルではなく、復号後に適用する明示的な許可リストです。本手順は、そのリストを定義から証明済みの拒否まで導きます。

この順序で作業し、以下のポリシー手順が通るまでトンネルの経路を広げないでください。

ゲートウェイに触れる前にマトリクスを書く

役に立つ行は、送信元グループ、宛先ホストまたはサービス網、そしてアプリケーションが実際に使うプロトコルとポートの三つを挙げます。拠点とデータセンターは項目ではありません。プライベート DNS と認証サービスは、アプリケーションがそれなしでは動かない場合にだけ独自の行を持ちます。

送信元はサブネットの都合ではなく役割、つまり職員、ゲスト、管理者でまとめます。三つとも同じフラットな LAN を共有していると、ゲートウェイはネットワーク層で区別できないため、ID 制御かセグメント分割を先に置く必要があります。その後、各行に所有者とレビュー日を付けてマトリクスを文書にします。

パケットが復号される場所で強制する

IKE と ESP を許可する規則は外側のトンネルを作るだけです。内側のトラフィックはトンネルインターフェースに平文で届くので、許可リストはそこに置き、復号する機器で転送チェーンと既定の破棄、マトリクスの行ごとに一つの規則を設定します。Linux のゲートウェイでは、転送を有効にし、フィルタ規則を物理アップリンクではなくトンネルデバイスに置くことになります（strongSwan の転送ガイドを参照）。

トラフィックセレクタはルーティングの決定であり、認可の決定ではありません。広いセレクタは両方のサブネットを覆っていてもルーティングには正しく、ファイアウォールは依然として一つのホストへの TCP 443 だけを許可します。セレクタはトンネル用に折衝され、そこに入れるものを記述しますが、特定の機器が何を使えるかではありません。セレクタが広いからといってファイアウォール規則を広げてはいけません。

iptables -A FORWARD -i tun0 -s 10.20.0.0/24 -d 10.10.5.10 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i tun0 -j DROP

NAT と重複するサブネットは規則を変える

拠点のゲートウェイがトンネルの前に各ホストを一つのアドレスに変換すると、送信元ベースの行はすべてその一つのアドレスに潰れます。トンネルのトラフィックの変換をやめるか、規則が別のもの、たとえば変換前に記録した元の送信元アドレスに依存することを受け入れるかです。宛先ホストが見るのは元のアドレスではなく NAT 後のアドレスなので、遠端も同じ問題を抱えます。

重複するレンジがもう一つの罠です。両方とも 192.168.1.0/24 を使う二つの拠点は、片側をマッピングしない限り一つのポリシー表には書けませんし、マッピングは衝突しないアドレス設計の代わりにはなりません。後でほどくことになる規則を書く前に、計画を直してください。

成功だけでなく拒否を証明する

許可されたアプリケーションだけを試しても、上流のどこかで緩い規則があれば同じ結果になるため、ほとんど何も証明できません。

通常の拠点端末から目的のサービスに到達し、セッション全体が動くことを確認します。次に、閉じたままであるべき宛先、たとえば拠点が関与しないサーバーの管理ポートを試し、それを落としたカウンターまたはログ項目を読みます。規則セットを無効にして動作を確かめるのは試験を無効にし、確認している間ゲートウェイを開けたままにします。

リストを生かし続ける

アプリケーションは移動し、アプリケーションより長生きする規則は誰も所有しない穴になります。レビュー日を行に結び付け、サービスがアドレスを変えたら同じ保守手順でセレクタの範囲とファイアウォール規則を変えます。

トンネルの背後でもホスト単位の制限は重要：サーバー自身のファイアウォールは、公開するサービスに対してだけ拠点のレンジを受け入れるべきです。二つの層が一致しているほうが、完全に信頼する一つの層より監査しやすいです。