復号後、VPNトラフィックを最初に見るポリシーはどれか

VPNのフローは完全に暗号化され完全に認証されていても、誰も計画していない場所に着地することがある。差し込むケーブルは内側のパケットをどのルールが処理するかを決めない。決めるのはポリシーフックと経路だ。だからラック図で同じに見える二つの設計でも、適用のされ方はまったく変わりうる。どちらを選ぶかは、復号されたフローを最初に見る制御の名前を挙げることから始まる。

ポートではなくポリシーフックで決める

どのVPN基盤も転送する前のどこかの時点で復号済みトラフィックを評価するが、その時点には設定上の名前がある。ある製品ではグループポリシーのフィルター、別の製品ではインターフェースポリシーやゾーンペア、ルーティングする機器では単にforwardチェーンであることもある。ルールを適用するのはフックであり、スイッチポートはケーブルが終わる場所にすぎない。フックを見つけることが最初の判断で、ほかのすべてはそれに対する位置づけだ。

ハードウェアを見る前にフローを書き出す。送信元は誰か、どこへ向かうか、どのプロトコルが運ぶか、どのサービスが許可されているか。そのうえで四つの事実それぞれを適用する制御を探す。

二つの経路、二つの異なる適用の物語

二つの形が一般的で、どちらも別の要件には正しいことがある。

endpoint -> shared inside subnet -> server
endpoint -> dedicated transit -> policy firewall -> server subnet

第一の形はゲートウェイですべて適用できる。ただしゲートウェイのポリシーがその宛先向けに書かれ、サーバーに迂回経路がない場合に限る。第二の形は境界を足すが、経路とポリシーが実際にトラフィックを通す場合だけだ。終端点と同じセグメントにあるサーバーは、想定した中間ホップをたどらないかもしれない。図は意図を示し、経路表は実際に起きることを示す。

図ではなく経路検索で検証する。パケットが出ていくインターフェースと選ばれる次のホップが、第二の形が設計どおりに動くかを決める。

ip route get 10.30.7.20
sudo iptables -S FORWARD
sudo tcpdump -ni inside0 host 10.30.7.20

トポロジーと分離を切り分ける

サブネットを共有しても場所が信頼できなくなるわけではなく、専用の中継があっても保護されるわけではない。決めるのは実際に適用される制限、実際に行われる転送、そして各部分を誰が管理するかだ。スイッチの数を数えても三つのどれも分からない。ポリシーと経路から決め、トポロジーはその決定に従わせる。

トラフィックの集団も分けて扱う。リモートアクセスのプール、サイト間のプレフィックス、専用線のネットワークは一つの機器を共有しても異なるルールを要する。身元とリスクが違うからだ。一つの集団向けに書いたルールは、アドレス計画を共有すると他を黙って覆ってしまう。

配置ごとに障害と管理を確認する

どの配置にも障害の形があり、有益な問いは部品が止まったときに何が動き続けるかだ。死んだ一つの機器に複数の論理インターフェースを置いても独立した復旧は得られず、同じ電源や同じ管理者を共有する下流のファイアウォールは二つ目の境界ではない。管理経路がどこを通るかを問うべきだ。トンネル経由でしか届かないコンソールは復旧経路にまったくならない。ssh [email protected] true をトンネルの外から実行するのが、コンソールがそれに依存しないことを示す最も安い方法だ。ある製品のグループポリシーの文書はフィルターを復号後・暗号化前のトラフィックに置いており、どの製品でも探すべき名前付きフックの典型だ。

候補ごとに障害の物語を適用の物語の隣に書く。検査で勝ち復旧で負ける配置は取引であり、事故の最中に発見するのではなく取引として記録すべきだ。

許可されたフローと拒否されたフローで受け入れる

承認された試験計画をもとに、実際のVPN送信元から三つを確認する。動くべきアプリケーション、動くべきでない資源、そして応答が戻る向きだ。拒否はポリシーが効いている証拠であり、許可されたフローは経路の存在しか示さない。

選んだ経路とポリシーの結果を一緒に保存する。経路のない結果は再現できず、結果のない経路は弁護できない。この組は、どのスイッチ層が本質的に安全かという主張より、接続点の選択にはるかに役立つ。