Azure Firewall と Azure Standard Load Balancer を統合するIntegrate Azure Firewall with Azure Standard Load Balancer

Azure Firewall と Azure Standard Load Balancer (パブリックまたは内部) を仮想ネットワークに統合できます。You can integrate an Azure Firewall into a virtual network with an Azure Standard Load Balancer (either public or internal).

内部ロード バランサーと Azure Firewall の統合は、設計が大幅に簡素化されるという点で推奨されます。The preferred design is to integrate an internal load balancer with your Azure firewall, as this is a much simpler design. パブリック ロード バランサーが既にデプロイされていて、今後もその環境を維持したい場合は、そのパブリック ロード バランサーを使用できます。You can use a public load balancer if you already have one deployed and you want to keep it in place. ただし、パブリック ロード バランサーのシナリオでは、機能が無効になる可能性がある非対称ルーティングの問題を認識しておく必要があります。However, you need to be aware of an asymmetric routing issue that can break functionality with the public load balancer scenario.

Azure Load Balancer の詳細については、Azure Load Balancer とは何かに関する記事を参照してください。For more information about Azure Load Balancer, see What is Azure Load Balancer?

パブリック ロード バランサーPublic load balancer

パブリック ロード バランサーを使用する場合、ロード バランサーはパブリック フロントエンド IP アドレスを使用してデプロイされます。With a public load balancer, the load balancer is deployed with a public frontend IP address.

非対称ルーティングAsymmetric routing

非対称ルーティングとは、パケットが送信先に到達するために通過するパスと、送信元に戻るために通過するパスが異なるルーティングです。Asymmetric routing is where a packet takes one path to the destination and takes another path when returning to the source. この問題は、サブネットの既定のルートにファイアウォールのプライベート IP アドレスが含まれているときに、パブリック ロード バランサーを使用した場合に発生します。This issue occurs when a subnet has a default route going to the firewall's private IP address and you're using a public load balancer. この場合、ロード バランサーの受信トラフィックはパブリック IP アドレス経由で受信されますが、復路のパスはファイアウォールのプライベート IP アドレスを通過します。In this case, the incoming load balancer traffic is received via its public IP address, but the return path goes through the firewall's private IP address. ファイアウォールはステートフルであり、そのような確立済みのセッションを認識しないため、返されるパケットは破棄されます。Since the firewall is stateful, it drops the returning packet because the firewall is not aware of such an established session.

ルーティングの問題を修正するFix the routing issue

Azure Firewall をサブネットにデプロイするときの 1 つの手順は、AzureFirewallSubnet 上のファイアウォールのプライベート IP アドレスを通過するようにパケットを方向づけるサブネット用の既定のルートを作成することです。When you deploy an Azure Firewall into a subnet, one step is to create a default route for the subnet directing packets through the firewall's private IP address located on the AzureFirewallSubnet. 詳細については、チュートリアル: Deploy and configure Azure Firewall using the Azure portal (チュートリアル: Azure portal を使用して Azure Firewall のデプロイと構成を行う)」を参照してください。For more information, see Tutorial: Deploy and configure Azure Firewall using the Azure portal.

ロード バランサーのシナリオにファイアウォールを導入するときに、インターネット トラフィックがファイアウォールのパブリック IP アドレス経由で到着するように設定できます。When you introduce the firewall into your load balancer scenario, you want your Internet traffic to come in through your firewall's public IP address. そこから、ファイアウォールによってファイアウォール規則が適用され、パケットがロードバランサーのパブリック IP アドレスに NAT されます。From there, the firewall applies its firewall rules and NATs the packets to your load balancer's public IP address. ここで問題が発生します。This is where the problem occurs. パケットはファイアウォールのパブリック IP アドレスに到着しますが、プライベート IP アドレス経由でファイアウォールに戻ります (既定のルートが使用されます)。Packets arrive on the firewall's public IP address, but return to the firewall via the private IP address (using the default route). この問題を回避するには、ファイアウォールのパブリック IP アドレス用の追加のホスト ルートを作成します。To avoid this problem, create an additional host route for the firewall's public IP address. ファイアウォールのパブリック IP アドレスに到着するパケットは、インターネット経由でルーティングされます。Packets going to the firewall's public IP address are routed via the Internet. これにより、ファイアウォールのプライベート IP アドレスへの既定のルートの使用が回避されます。This avoids taking the default route to the firewall's private IP address.


たとえば、パブリック IP アドレスが で、プライベート IP アドレスが のファイアウォールのルートは次のようになります。For example, the following routes are for a firewall at public IP address, and private IP address

ルート テーブル

内部ロード バランサーInternal load balancer

内部ロード バランサーを使用する場合、ロード バランサーはプライベート フロントエンド IP アドレスでデプロイされます。With an internal load balancer, the load balancer is deployed with a private frontend IP address.

このシナリオでは、非対称ルーティングの問題はありません。There's no asymmetric routing issue with this scenario. 受信パケットはファイアウォールのパブリック IP アドレスに到着し、ロード バランサーのプライベート IP アドレスに変換された後、同じ復路のパスを使用してファイアウォールのプライベート IP アドレスに戻ります。The incoming packets arrive at the firewall's public IP address, get translated to the load balancer's private IP address, and then returns to the firewall's private IP address using the same return path.

そのため、このシナリオはパブリック ロード バランサーのシナリオと同じようにデプロイできますが、ファイアウォールのパブリック IP アドレスのホスト ルートは必要ありません。So, you can deploy this scenario similar to the public load balancer scenario, but without the need for the firewall public IP address host route.

追加のセキュリティAdditional security

負荷分散シナリオのセキュリティを強化するために、ネットワーク セキュリティ グループ (NSG) を使用できます。To further enhance the security of your load-balanced scenario, you can use network security groups (NSGs).

たとえば、負荷分散される仮想マシンが配置されているバックエンドのサブネット上に NSG を作成できます。For example, you can create an NSG on the backend subnet where the load-balanced virtual machines are located. ファイアウォールの IP アドレスまたはポートからの受信トラフィックが許可されます。Allow incoming traffic originating from the firewall IP address/port.

NSG について詳しくは、「セキュリティ グループ」をご覧ください。For more information about NSGs, see Security groups.

次の手順Next steps