Azure Firewall は、パブリックまたは内部の Azure Standard Load Balancer を使用して仮想ネットワークに統合できます。
推奨される設計は、セットアップが簡略化されるため、Azure Firewall で内部ロード バランサーを使用することです。 パブリック ロード バランサーが既にデプロイされていて、それを引き続き使用する場合は、機能を中断する可能性のある非対称ルーティングの問題に注意してください。
Azure Load Balancer の詳細については、Azure Load Balancer とは何かに関する記事を参照してください。
パブリック ロード バランサー
パブリック ロード バランサーを使用する場合は、パブリック フロントエンド IP アドレスを使用してロード バランサーをデプロイします。
非対称ルーティング
非対称ルーティングは、パケットが宛先へのパスを 1 つ受け取り、送信元に戻るときに別のパスを取得するときに発生します。 この問題は、サブネットにファイアウォールのプライベート IP アドレスへの既定のルートがあり、パブリック ロード バランサーを使用している場合に発生します。 この場合、受信ロード バランサートラフィックはパブリック IP アドレスを経由しますが、リターン パスはファイアウォールのプライベート IP アドレスを経由します。 ファイアウォールはステートフルであり、そのような確立済みのセッションを認識しないため、返されるパケットは破棄されます。
ルーティングの問題を修正する
シナリオ 1: NAT ゲートウェイのない Azure Firewall
サブネットに Azure Firewall をデプロイする場合は、サブネットの既定のルートを作成する必要があります。 このルートは、AzureFirewallSubnet にあるファイアウォールのプライベート IP アドレスを介してパケットを転送します。 詳細な手順については、 Azure portal を使用した Azure Firewall のデプロイと構成に関するページを参照してください。 ファイアウォールをロード バランサーのシナリオに統合する場合は、インターネット トラフィックがファイアウォールのパブリック IP アドレスを経由するようにします。 ファイアウォールはその規則を適用し、パケットをロード バランサーのパブリック IP アドレスに NAT します。 この問題は、パケットがファイアウォールのパブリック IP アドレスに到着したが、プライベート IP アドレスを介して (既定のルートを使用して) 返されるときに発生します。
非対称ルーティングを防ぐには、ファイアウォールのパブリック IP アドレスの特定のルートを追加します。 ファイアウォールのパブリック IP アドレスを対象としたパケットはインターネット経由で送信され、ファイアウォールのプライベート IP アドレスへの既定のルートはバイパスされます。
ルート テーブルの例
たとえば、次のルート テーブルは、パブリック IP アドレスが 203.0.113.136、プライベート IP アドレスが 10.0.1.4 のファイアウォールのルートを示しています。
シナリオ 2: NAT ゲートウェイを使用した Azure Firewall
一部のシナリオでは、送信接続の SNAT (送信元ネットワーク アドレス変換) ポートの制限を克服するために、Azure Firewall サブネット上に NAT ゲートウェイを構成できます。 このような場合、NAT ゲートウェイのパブリック IP アドレスが Azure Firewall のパブリック IP アドレスよりも優先されるため、シナリオ 1 のルート構成は機能しません。
詳細については、「 NAT ゲートウェイと Azure Firewall の統合」を参照してください。
NAT ゲートウェイが Azure Firewall サブネットに関連付けられている場合、インターネットからの受信トラフィックは Azure Firewall のパブリック IP アドレスに送信されます。 その後、Azure Firewall は、トラフィックをロード バランサーのパブリック IP アドレスに転送する前に、ソース IP を NAT ゲートウェイのパブリック IP アドレスに変更 (SNAT) します。
NAT ゲートウェイがない場合、Azure Firewall は、トラフィックをロード バランサーのパブリック IP アドレスに転送する前に、ソース IP アドレスを独自のパブリック IP アドレスに変更します。
Important
リソース (AKS/VM) サブネットに関連付けられているネットワーク セキュリティ グループ (NSG) 規則で、NAT ゲートウェイのパブリック IP アドレスまたはパブリック プレフィックスを許可します。
NAT ゲートウェイを使用したルート テーブルの例
次ホップとしてインターネットを使用する Azure Firewall パブリック IP アドレスの代わりに NAT ゲートウェイのパブリック IP アドレスを使用するには、リターン パスのルートを追加する必要があります。
たとえば、次のルート テーブルは、パブリック IP アドレスが 198.51.100.101 の NAT ゲートウェイと、プライベート IP アドレスが 10.0.1.4 のファイアウォールのルートを示しています。
NAT 規則の例
どちらのシナリオでも、NAT 規則は、RDP (リモート デスクトップ プロトコル) トラフィックをファイアウォールのパブリック IP アドレス (203.0.113.136) からロード バランサーのパブリック IP アドレス (203.0.113.220) に変換します。
ヘルスプローブ
ポート 80 または HTTP/HTTPS プローブで TCP (トランスポート制御プロトコル) 正常性プローブを使用する場合は、ロード バランサー プール内のホストで Web サービスを実行することを忘れないでください。
内部ロード バランサー
内部ロード バランサーは、プライベート フロントエンド IP アドレスを使用してデプロイされます。
このシナリオには、非対称ルーティングの問題はありません。 受信パケットはファイアウォールのパブリック IP アドレスに到着し、ロード バランサーのプライベート IP アドレスに変換され、同じパスを使用してファイアウォールのプライベート IP アドレスに戻ります。
このシナリオはパブリック ロード バランサーのシナリオと同様にデプロイしますが、ファイアウォールのパブリック IP アドレス ホスト ルートは必要ありません。
バックエンド プール内の仮想マシンは、Azure Firewall 経由で送信インターネット接続を持つことができます。 次ホップとしてファイアウォールを使用して、仮想マシンのサブネット上にユーザー定義ルートを構成します。
追加のセキュリティ
負荷分散シナリオのセキュリティをさらに強化するには、ネットワーク セキュリティ グループ (NSG) を使用します。
たとえば、負荷分散された仮想マシンが配置されているバックエンド サブネットに NSG を作成します。 ファイアウォールのパブリック IP アドレスとポートからの着信トラフィックを許可します。 NAT ゲートウェイが Azure Firewall サブネットに関連付けられている場合は、NAT ゲートウェイのパブリック IP アドレスとポートから発信される着信トラフィックを許可します。
NSG について詳しくは、「セキュリティ グループ」をご覧ください。
次のステップ
- Azure Firewall のデプロイおよび構成方法について説明します。