VPNクライアントの通信とファイアウォール状態：外側と内側のフロー

VPNのハンドシェイクは完了してクライアントはアドレスを取得したのに、ゲートウェイの背後のサービスは依然として接続を拒否する。ファイアウォールは往々にして指示どおりに動いている。許可したのは外側のトンネルフローであり、カプセル化解除後のアプリケーション接続とは別のパケットだ。そこから、どのフローを許可しているのか、そして境界が状態を追跡しているのかどうかという二つの判断が生まれる。

この二つを切り分けるまで、ルールの変更はすべて推測にすぎない。

ファイアウォールは二つの異なるパケットを見る

カプセル化解除の前、ファイアウォールはVPNエンドポイント宛ての通信、つまりリスナーへの外側UDPフローを見る。カプセル化解除の後、転送されるパケットはクライアントの内側アドレスとサービスの宛先を運ぶ。

外側フローの許可は、転送されるTCP接続を認可しない。両者は異なるチェーンで、異なるインターフェースに対して、変換後の異なるアドレスで評価されうる。

両側の等価な位置で取得したキャプチャを比較する。トンネル境界でのキャプチャとサーバーでのキャプチャは、同じセッションに対して異なるタプルを示す。

第一の判断：トンネルかサービスかを許可する

クライアントがVPNエンドポイント自体だけを必要とするなら、外側の許可で足りるかもしれない。ゲートウェイの先のサービスが必要なら、その宛先とポートへの転送許可が要る。サービスまで許可するトンネルルールは、名指しすべき設計判断であって、偶発的なものではない。

クライアントの範囲とサービスの適用範囲は狭く保つ。トンネルのサブネットからLAN全体への許可は、すべてのホストを信頼する決定であり、一つのアプリケーションの近道ではない。

二つのルールを別々に書き留める。トンネルのルールとサービスのルールは異なる仕方で失敗し、異なる証拠で切り分ける。片方が失敗したとき、どちらの層を先に見るべきかが分かる。

第二の判断：各境界で状態を持つか持たないか

確立済みフローのルールは、許可されたやり取りの応答を通せるが、その挙動は製品に依存する。クラウドのセキュリティグループは通常ステートフルだが、サブネットのACLはしばしばステートレスで、両方向の明示的な扱いを要する。経路上のすべての境界が同じように状態を扱うと仮定してはいけない。ルールを設計する前に、各境界を列挙し、ステートフルかステートレスかを記しておく。

ルールを変えると、既存の追跡済みフローは動き続けるのに新しいフローが失敗することがあり、その逆も起こりうる。その差は有用な手がかりであり、稼働中のゲートウェイで接続状態をすべて消す理由にはならない。

新しく統制されたリクエストで試し、該当するカウンターを確認する。清潔なテストは破壊的なリセットに勝る。変更記録にカウンター名を残し、次のテストが同じ証拠を使えるようにする。

同じポリシーで復路を検証する

クライアントからサービスへ新しいリクエストを送り、各境界で往路と復路のカウンターを確認する。変換が関わる場合は特に、応答が想定した経路を使っていることを確かめる。

想定したクライアント範囲とサービスの適用範囲を狭く保ち、リクエストを許可したのと同じルールセットの下で復路を検証する。古いフローが開いているから動くだけのルールは、動くルールではない。