Azure NVA 検査: 応答が別のファイアウォールを通る理由

支社から Azure へのフローは、両方向で正しくルーティングされていても失敗することがある。二つの方向が別々のアプライアンスを通るためだ。要求は VPN 経由で支社を出て NVA A に着地し、ワークロードに届く。応答はワークロードを出て、NVA B を指すルートに一致し、そこで途絶える。この図のどのルートも有効なのに、TCP セッションは壊れたままだ。

Request: branch -> VPN gateway -> NVA A -> workload
Reply:   workload -> NVA B -> VPN gateway -> branch

この隙間こそが本題である。ルーティングの収束とセッション状態の所有は別の問題だが、図の上では同じに見える。

Route Server が実際にプログラミングするもの

Azure Route Server は対応する BGP スピーカーとピアを組み、そのルートを学習して仮想ネットワークの有効ルートにプログラミングする。これはコントロールプレーンの仕事だ。ベンダーのファイアウォールのセッションテーブルを読むわけでもなく、どのアプライアンスが特定の接続を許可したのかも知らない。等コストの二つのネクストホップは、このファブリックにとって同じプレフィックスへの単なる二つの経路であり、どちらでも使う。

したがってルートを学習することは到達可能性を証明する。相手側の機器がこのフローを以前に見たかどうかは何も証明しない。

設計の前に両方向を読む

まず、意図したステアリングではなく、各方向で実際に持っているステアリングを書き出す。より具体的な BGP ルート、ユーザー定義ルート、ゲートウェイの挙動がすべて競合し、勝者はセッション単位ではなく宛先単位で決まる。NVA のデフォルトルートは、すべてのプライベートプレフィックスがそこを通ることを意味しない。

有用な確認は、特定のワークロード IP について、各方向がどのネクストホップに解決されるかを尋ねることだ。答えが二つの異なるアプライアンスなら、まだ表面化していなくても非対称性の問題がある。

状態はどこに住むか

ステートフルなファイアウォールは接続を許可し、五つ組をキーとするテーブルエントリを保持する。応答はそのエントリを持つ機器に届くか、その機器が別の方法で状態を取得する必要がある。Azure のデータプレーンはエントリをアプライアンス間で転送しない。トラフィックを所有者に戻すか、アプライアンスがベンダーの仕組みで状態を共有するか、さもなければ設計は成り立たない。

だから健全な NVA が二つあっても、それは検査のヘルスチェックにはならない。健全性は到達可能性の話であり、検査はどのインスタンスがセッションを持つかの話だ。

サポートされる HA モデルとそれぞれの約束

Microsoft's guidance on Virtual WAN のルーティング意図に関する Microsoft のガイダンスは、デュアルロール接続とファイアウォール NVA に対する限定的な挙動を説明しており、直接ルーティングがハブの通常の対称的な強制を迂回することがある。その注意書きは、選んだトポロジへの制約として読み、アクティブ-アクティブ設計の禁止として読まないこと。状態を同期する、またはフロー単位でステアリングするベンダーペアはサポートできる。どちらもしない等コストのペアはサポートできない。

次に、ノードが故障したときに既存セッションがどうなるかを定義する。ルート収束は新しいフローの到達可能性を数秒で回復するが、古いファイアウォール状態は単に消える。クライアントの再接続が文書化された結果になることもあり、それはインシデントの前に決めることであって、最中に決めることではない。

信頼する前に何をテストするか

Test with inspection enabled and ワークロードのアクセス ポリシーを配置した状態でテストする。どちらも非対称性を隠しうるからだ。新しい許可済みフローを両方向に送り、同じアプライアンスが両方の半分を見たことを確認する。その後、持続的なトラフィックを流して承認済みのフェールオーバーを起こし、確立済みセッションが生き残るか再接続するかを観察する。

各フローを処理したアプライアンスと関連付ける。片方の NVA でのパケットキャプチャは、応答がそこに戻ってこなければほとんど何も語らない。

最後に、計画を三つの独立した行として書く。ルートの所有、トラフィックのステアリング、セッション状態の所有だ。最初の二つが解決され、三つ目が前提にされると設計は壊れる。