はじめに
Azure Firewallを経由させて南北・東西方向のトラフィックを流す構成をとることがあると思います。その際に、戻りのトラフィックをUDRでAzureFirewallに向けるんだっけ？どうするんだっけ？と悩むことがあるのでそのまとめ。
Azure FirewallによるDNAT
- よくあるこんなパターン
- 南北方向(外からのトラフィック)を制御する
- Azure FirewallにDNATルールを追加する
- 「Azure FirewallのパブリックIP：ポート」を「VMのプライベートIP：ポート(3389とか)」にマッピングする
- VM目線では、Azure FirewallのプライベートIPからの通信を受け付けているだけなので、NSGによる外部IPの穴あけも不要
戻りの通信のUDRの必要性
- 結論、不要
- あくまで戻りの通信は、同じネットワークセグメントに属するVM → Azure Firewallとなるため、ルーティングは非対象にならない
Hub-Spoke構成におけるSpoke間のVM通信
-
Azure Firewallをパケットフォワーダとして用いることで、直接ピアリングの張られていないSpoke間の接続を実現するパターン
-
東西方向(ネットワーク境界内)の通信となるため、ネットワークルールにより制御
-
Spoke1 -> Spoke2およびSpoke2 -> Spoke1の許可ルールを入れる(実際には必要に応じて一方向でも可)
戻りの通信のUDRの必要性
- Spoke間はそもそも相手のアドレス空間が見えていないので、UDRは必須
- 最低限デフォルトルート(0.0.0.0/0)をAzure Firewallに向けておけばよい
- あとはそれがSpoke宛ての通信であればAzure Firewallが自分の見ているルートテーブルをもとに振り分けてくれる
- 対象SpokeへのルートはVNet Peeringにより自動追加されている
オンプレ-Spoke通信
- オンプレ-ExpressRoute-Hub-Spoke構成でのオンプレからSpokeへ通信のパターン
- GatewaySubnetにSpoke宛てのトラフィックをAzure Firewallに流すルートテーブルを割り当てる
戻りの通信のUDRの必要性
- 行きの通信はGatewaySubnetに関連付けたUDRによって「オンプレ -> Gateway -> Azure Firewall -> VM」となる
- 一方、戻りの通信はUDR無しだとすると「VM -> GatewaySubnet -> オンプレ」となる
- よって、戻りの通信がAzure Firewallを通らず、非対称な形となるためTCPのセッションを開始できない
- ICMPなら通るが、TCPはできないという状態になってしまう
- よって、戻りの通信を「VM -> AzureFirewall -> Gateway -> オンプレ」となるようにVM側のサブネットにルートテーブルが必要
ちなみに
- この非対称ルーティングの話は、Azure FirewallとStandard Public Load Balancerを組み合わせる際にも問題になることがあるため注意
- 往路の通信はAzure Load Balancer経由でVMに到達するが、[デフォルトルート->Azure Firewall]のUDRによって復路がAzure Firewall経由となる
- ファイアウォールはステートフルであり、そのような確立済みのセッションを認識しないため、返されるパケットは破棄されるという話
おわり
- ちなみにAzure FirewallもNSGもステートフルなので戻りの通信は基本的に許可だが、ルーティングの考慮は必要になる
GitHubで編集を提案
Discussion