Azure の送信接続Outbound connections in Azure

Azure では、いくつかの異なるメカニズムを通じて顧客デプロイの送信接続を提供します。Azure provides outbound connectivity for customer deployments through several different mechanisms. この記事では、どのようなシナリオがあり、それらがいつ適用されるかについて説明するほか、それらのシナリオのしくみと管理方法について説明します。This article describes what the scenarios are, when they apply, how they work, and how to manage them.

注意

この記事は、Resource Manager デプロイメントのみを対象とします。This article covers Resource Manager deployments only. Azure のすべてのクラシック デプロイメント シナリオについては、「送信接続 (クラシック)」をご覧ください。Review Outbound connections (Classic) for all Classic deployment scenarios in Azure.

Azure のデプロイは、パブリック IP アドレス空間で Azure 外部のエンドポイントと通信できます。A deployment in Azure can communicate with endpoints outside Azure in the public IP address space. インスタンスがパブリック IP アドレス空間の宛先への送信フローを開始すると、Azure によってプライベート IP アドレスがパブリック IP アドレスに動的にマッピングされます。When an instance initiates an outbound flow to a destination in the public IP address space, Azure dynamically maps the private IP address to a public IP address. このマッピングが作成されると、この送信フローの戻りトラフィックも、フローの送信元であるプライベート IP アドレスに到達できます。After this mapping is created, return traffic for this outbound originated flow can also reach the private IP address where the flow originated.

Azure は送信元ネットワーク アドレス変換 (SNAT) を使用してこの機能を実行します。Azure uses source network address translation (SNAT) to perform this function. 複数のプライベート IP アドレスが単一のパブリック IP アドレスでマスカレードされている場合、Azure ではポート アドレス変換 (PAT) を使用してプライベート IP アドレスがマスカレードされます。When multiple private IP addresses are masquerading behind a single public IP address, Azure uses port address translation (PAT) to masquerade private IP addresses. エフェメラル ポートが PAT に使用され、プール サイズに基づいて事前に割り当てられます。Ephemeral ports are used for PAT and are preallocated based on pool size.

送信シナリオは複数あります。There are multiple outbound scenarios. 必要に応じて、これらのシナリオを組み合わせることができます。You can combine these scenarios as needed. これらを注意深く確認して、実際のデプロイメント モデルとアプリケーション シナリオに適用される際の機能、制約、パターンを把握してください。Review them carefully to understand the capabilities, constraints, and patterns as they apply to your deployment model and application scenario. また、これらのシナリオを管理するためのガイダンスを確認してください。Review guidance for managing these scenarios.

重要

Standard Load Balancer および Standard パブリック IP では、アウトバウンド接続に新しい機能とさまざまな動作が導入されています。Standard Load Balancer and Standard Public IP introduce new abilities and different behaviors to outbound connectivity. これらは Basic SKU と同じではありません。They are not the same as Basic SKUs. Standard SKU を操作するときにアウトバウンド接続が必要な場合は、Standard パブリック IP アドレスまたは Standard パブリック Load Balancer で明示的に定義する必要があります。If you want outbound connectivity when working with Standard SKUs, you must explicitly define it either with Standard Public IP addresses or Standard public Load Balancer. これには、内部 Standard Load Balancer を使用する場合のアウトバウンド接続の作成が含まれます。This includes creating outbound connectivity when using an internal Standard Load Balancer. Standard パブリック Load Balancer では常にアウトバウンド規則を使用することをお勧めします。We recommend you always use outbound rules on a Standard public Load Balancer. シナリオ 3 は、Standard SKU では利用できません。Scenario 3 is not available with Standard SKU. つまり、内部 Standard Load Balancer が使用されているときに、アウトバウンド接続が必要な場合、バックエンド プール内の VM に対してアウトバウンド接続を作成する手順を行う必要があります。That means when an internal Standard Load Balancer is used, you need to take steps to create outbound connectivity for the VMs in the backend pool if outbound connectivity is desired. アウトバウンド接続のコンテキストでは、単一スタンドアロン VM、可用性セット内のすべての VM、VMSS のすべてのインスタンスがグループとして動作します。In the context of outbound connectivity, a single standalone VM, all the VM's in an Availability Set, all the instances in a VMSS behave as a group. つまり、可用性セット内の単一 VM が Standard SKU に関連付けられている場合、この可用性セット内のすべての VM インスタンスが、Standard SKU に関連付けられている場合と同じ規則に従って動作するようになります。個々のインスタンスが直接関連付けられていない場合でも同様です。This means, if a single VM in an Availability Set is associated with a Standard SKU, all VM instances within this Availability Set now behave by the same rules as if they are associated with Standard SKU, even if an individual instance is not directly associated with it. このドキュメント全体をよく読み、全体的な概念を理解し、SKU 間の違いについて Standard Load Balancer を確認し、アウトバウンド規則を確認してください。Carefully review this entire document to understand the overall concepts, review Standard Load Balancer for differences between SKUs, and review outbound rules. アウトバウンド規則を使用することで、アウトバウンド接続のすべての側面を細かく制御できます。Using outbound rules allows you fine grained control over all aspects of outbound connectivity.

シナリオの概要Scenario overview

Azure Resource Manager を使用している場合、Azure Load Balancer と関連するリソースは明示的に定義されます。Azure Load Balancer and related resources are explicitly defined when you're using Azure Resource Manager. 現在 Azure には、Azure Resource Manager リソースの送信接続を実現するのに 3 つの異なる方法があります。Azure currently provides three different methods to achieve outbound connectivity for Azure Resource Manager resources.

SKUSKUs シナリオScenario MethodMethod IP プロトコルIP protocols 説明Description
Standard、BasicStandard, Basic 1.インスタンス レベル パブリック IP アドレスを含む VM (ロード バランサーあり、またはなし)1. VM with an Instance Level Public IP address (with or without Load Balancer) SNAT (ポート マスカレードは不使用)SNAT, port masquerading not used TCP、UDP、ICMP、ESPTCP, UDP, ICMP, ESP インスタンスの NIC の IP 構成に割り当てられたパブリック IP が Azure によって使用されます。Azure uses the public IP assigned to the IP configuration of the instance's NIC. インスタンスには、使用可能なすべてのエフェメラル ポートがあります。The instance has all ephemeral ports available. Standard Load Balancer を使用する場合は、アウトバウンド規則を使って、アウトバウンド接続を明示的に定義する必要がありますWhen using Standard Load Balancer, you should use outbound rules to explicitly define outbound connectivity
Standard、BasicStandard, Basic 2.VM に関連付けられたパブリック ロード バランサー (インスタンスにインスタンス レベルのパブリック IP アドレスなし)2. Public Load Balancer associated with a VM (no Instance Level Public IP address on the instance) ロード バランサー フロントエンドを使用したポート マスカレード (PAT) による SNATSNAT with port masquerading (PAT) using the Load Balancer frontends TCP、UDPTCP, UDP Azure によってパブリック ロード バランサー フロントエンドのパブリック IP アドレスが複数のプライベート IP アドレスと共有されます。Azure shares the public IP address of the public Load Balancer frontends with multiple private IP addresses. Azure では、フロントエンドのエフェメラル ポートが PAT に使用されます。Azure uses ephemeral ports of the frontends to PAT.
なし、または Basicnone or Basic 3.スタンドアロン VM (ロード バランサーなし、インスタンス レベルのパブリック IP アドレスなし)3. Standalone VM (no Load Balancer, no Instance Level Public IP address) ポート マスカレード (PAT) による SNATSNAT with port masquerading (PAT) TCP、UDPTCP, UDP Azure によって自動的に SNAT 用のパブリック IP アドレスが指定され、このパブリック IP アドレスが可用性セットの複数のプライベート IP アドレスと共有されてから、このパブリック IP アドレスのエフェメラル ポートが使用されます。Azure automatically designates a public IP address for SNAT, shares this public IP address with multiple private IP addresses of the availability set, and uses ephemeral ports of this public IP address. このシナリオは、前のシナリオのフォールバックです。This scenario is a fallback for the preceding scenarios. 可視性と制御が必要は場合は推奨されません。We don't recommend it if you need visibility and control.

VM がパブリック IP アドレス空間で Azure の外部のエンドポイントと通信しないようにする場合、必要に応じてネットワーク セキュリティ グループ (NSG) を使用してアクセスをブロックできます。If you don't want a VM to communicate with endpoints outside Azure in public IP address space, you can use network security groups (NSGs) to block access as needed. NSG の使用の詳細については、「送信接続の防止」で説明します。The section Preventing outbound connectivity discusses NSGs in more detail. 送信アクセスがない仮想ネットワークの設計、実装、および管理のガイダンスについては、この記事の範囲外です。Guidance on designing, implementing, and managing a virtual network without any outbound access is outside the scope of this article.

シナリオ 1:インスタンス レベルのパブリック IP アドレスがある VMScenario 1: VM with an Instance Level Public IP address

このシナリオでは、VM にはインスタンス レベルのパブリック IP (ILPIP) が割り当てられています。In this scenario, the VM has an Instance Level Public IP (ILPIP) assigned to it. 送信接続に関する限り、VM が負荷分散されているかどうかは関係ありません。As far as outbound connections are concerned, it doesn't matter whether the VM is load balanced or not. このシナリオは他のシナリオよりも優先されます。This scenario takes precedence over the others. ILPIP が使用される場合、すべての送信フローで VM によって ILPIP が使用されます。When an ILPIP is used, the VM uses the ILPIP for all outbound flows.

VM に割り当てられたパブリック IP は (1 対多ではなく) 1 対 1 の関係であり、1 対 1 のステートレス NAT として実装されます。A public IP assigned to a VM is a 1:1 relationship (rather than 1: many) and implemented as a stateless 1:1 NAT. ポート マスカレード (PAT) は使用されず、VM は使用可能なすべてのエフェメラル ポートを備えます。Port masquerading (PAT) is not used, and the VM has all ephemeral ports available for use.

アプリケーションが多数の送信フローを開始したために SNAT ポート不足が発生した場合は、SNAT の制約を軽減するために ILPIP を割り当てることを検討してください。If your application initiates many outbound flows and you experience SNAT port exhaustion, consider assigning an ILPIP to mitigate SNAT constraints. その全体像については、SNAT 不足の管理に関するセクションを確認してください。Review Managing SNAT exhaustion in its entirety.

シナリオ 2:インスタンス レベルのパブリック IP アドレスがない負荷分散 VMScenario 2: Load-balanced VM without an Instance Level Public IP address

このシナリオでは、VM はパブリック Load Balancer バックエンド プールに含まれます。In this scenario, the VM is part of a public Load Balancer backend pool. VM にパブリック IP アドレスは割り当てられていません。The VM does not have a public IP address assigned to it. パブリック IP フロントエンドとバックエンド プール間にリンクを作成するには、ロード バランサー リソースをロード バランサー規則で構成する必要があります。The Load Balancer resource must be configured with a load balancer rule to create a link between the public IP frontend with the backend pool.

この規則の構成を完了しないと、インスタンス レベルのパブリック IP アドレスがないスタンドアロン VM のシナリオで説明される動作になります。If you do not complete this rule configuration, the behavior is as described in the scenario for Standalone VM with no Instance Level Public IP. 成功するために正常性プローブのバックエンド プールの作業リスナーを規則に含める必要はありません。It is not necessary for the rule to have a working listener in the backend pool for the health probe to succeed.

負荷分散 VM が送信フローを作成すると、Azure が、送信フローのプライベート ソース IP アドレスをパブリック ロード バランサー フロントエンドのパブリック IP アドレスに変換します。When the load-balanced VM creates an outbound flow, Azure translates the private source IP address of the outbound flow to the public IP address of the public Load Balancer frontend. Azure は、SNAT を使用してこの機能を実行します。Azure uses SNAT to perform this function. また、Azure は、PAT を使用して、複数のプライベート IP アドレスをパブリック IP アドレスでマスカレードします。Azure also uses PAT to masquerade multiple private IP addresses behind a public IP address.

ロード バランサーのパブリック IP アドレス フロントエンドのエフェメラル ポートを使用して、VM から送信される個々のフローが区別されます。Ephemeral ports of the load balancer's public IP address frontend are used to distinguish individual flows originated by the VM. 送信フローが作成されると、事前に割り当てられたエフェメラル ポートが SNAT によって動的に使用されます。SNAT dynamically uses preallocated ephemeral ports when outbound flows are created. ここでは、SNAT で使用されるエフェメラル ポートを SNAT ポートと呼びます。In this context, the ephemeral ports used for SNAT are called SNAT ports.

SNAT ポートは、「SNAT と PAT の理解」の説明のとおり事前に割り当てられます。SNAT ports are pre-allocated as described in the Understanding SNAT and PAT section. これは有限のリソースであり、不足する可能性があります。They're a finite resource that can be exhausted. これらがどのように消費されるのかを理解することが重要です。It's important to understand how they are consumed. この消費のための設計と移行を必要に応じて行う方法については、SNAT 不足の管理に関するセクションを確認してください。To understand how to design for this consumption and mitigate as necessary, review Managing SNAT exhaustion.

複数のパブリック IP アドレスが Load Balancer Basic に関連付けられている場合、それらのパブリック IP アドレスはどれもアウトバウンド フローの候補になり、その 1 つがランダムに選択されます。When multiple public IP addresses are associated with Load Balancer Basic, any of these public IP addresses are a candidate for outbound flows, and one is selected at random.

Load Balancer Basic でアウトバウンド接続の正常性を監視するために、Load Balancer 用の Azure Monitor ログと、SNAT ポート不足メッセージを監視するためのアラート イベント ログを使用できます。To monitor the health of outbound connections with Load Balancer Basic, you can use Azure Monitor logs for Load Balancer and alert event logs to monitor for SNAT port exhaustion messages.

シナリオ 3:インスタンス レベルのパブリック IP アドレスがないスタンドアロン VMScenario 3: Standalone VM without an Instance Level Public IP address

このシナリオでは、VM はパブリック Load Balancer プールの一部ではなく (また、内部 Standard Load Balancer プールの一部ではなく)、ILPIP アドレスが割り当てられていません。In this scenario, the VM is not part of a public Load Balancer pool (and not part of an internal Standard Load Balancer pool) and does not have an ILPIP address assigned to it. VM が送信フローを作成すると、Azure が、送信フローのプライベート ソース IP アドレスをパブリック ソース IP アドレスに変換します。When the VM creates an outbound flow, Azure translates the private source IP address of the outbound flow to a public source IP address. この送信フローで使用されるパブリック IP アドレスは構成不可能であり、サブスクリプションのパブリック IP リソースの制限に対してカウントされません。The public IP address used for this outbound flow is not configurable and does not count against the subscription's public IP resource limit. このパブリック IP アドレスはユーザーのものではなく、予約することはできません。This public IP address does not belong to you and cannot be reserved. VM、可用性セット、または仮想マシン スケール セットを再デプロイすると、このパブリック IP アドレスは解放され、新しいパブリック IP アドレスが要求されます。If you redeploy the VM or Availability Set or virtual machine scale set, this public IP address will be released and a new public IP address requested. IP アドレスをホワイトリストに登録する場合は、このシナリオを使用しないでください。Do not use this scenario for whitelisting IP addresses. 代わりに、送信シナリオと、送信接続で使用されるパブリック IP アドレスを明示的に宣言する他の 2 つのシナリオのいずれかを使用します。Instead, use one of the other two scenarios where you explicitly declare the outbound scenario and the public IP address to be used for outbound connectivity.

重要

このシナリオは、内部 Basic Load Balancer が接続されている場合に のみ 適用されます。This scenario also applies when only an internal Basic Load Balancer is attached. 内部 Standard Load Balancer が VM に接続されている場合、シナリオ 3 は 利用できませんScenario 3 is not available when an internal Standard Load Balancer is attached to a VM. 内部 Standard Load Balancer を使用することに加え、シナリオ 1 またはシナリオ 2 を明示的に作成する必要があります。You must explicitly create scenario 1 or scenario 2 in addition to using an internal Standard Load Balancer.

Azure は、SNAT とポート マスカレード (PAT) を使用してこの機能を実行します。Azure uses SNAT with port masquerading (PAT) to perform this function. このシナリオは、使用される IP アドレスに対するコントロールがない点を除いて、シナリオ 2 に類似しています。This scenario is similar to scenario 2, except there is no control over the IP address used. これは、シナリオ 1 および 2 がない場合のフォールバック シナリオです。This is a fallback scenario for when scenarios 1 and 2 do not exist. このシナリオは、送信アドレスに対するコントロールが必要な場合は推奨されません。We don't recommend this scenario if you want control over the outbound address. 送信接続がアプリケーションの重要な部分である場合は、別のシナリオを選ぶ必要があります。If outbound connections are a critical part of your application, you should choose another scenario.

SNAT ポートは、「SNAT と PAT の理解」の説明のとおり事前に割り当てられます。SNAT ports are preallocated as described in the Understanding SNAT and PAT section. 可用性セットを共有している VM の数によって、適用される事前割り当ての階層が決まります。The number of VMs sharing an Availability Set determines which preallocation tier applies. 事前割り当て (1024 SNAT ポート) を決定する目的の場合、可用性セットのないスタンドアロン VM は、事実上 1 のプールです。A standalone VM without an Availability Set is effectively a pool of 1 for the purposes of determining preallocation (1024 SNAT ports). SNAT ポートは有限のリソースであり、不足する可能性があります。SNAT ports are a finite resource that can be exhausted. これらがどのように消費されるのかを理解することが重要です。It's important to understand how they are consumed. この消費のための設計と移行を必要に応じて行う方法については、SNAT 不足の管理に関するセクションを確認してください。To understand how to design for this consumption and mitigate as necessary, review Managing SNAT exhaustion.

組み合わされた複数のシナリオMultiple, combined scenarios

これまでのセクションで説明したシナリオを組み合わせることで、特定の結果を実現することができます。You can combine the scenarios described in the preceding sections to achieve a particular outcome. 複数のシナリオがある場合は、次の優先順位が適用されます。シナリオ 1 は、シナリオ 2シナリオ 3 に優先します。When multiple scenarios are present, an order of precedence applies: scenario 1 takes precedence over scenario 2 and 3. シナリオ 2シナリオ 3 をオーバーライドします。Scenario 2 overrides scenario 3.

たとえば、アプリケーションが限られた数の宛先への送信接続に大きく依存している一方で、ロード バランサー フロントエンド経由で受信フローも受け取っている Azure Resource Manager デプロイがあります。An example is an Azure Resource Manager deployment where the application relies heavily on outbound connections to a limited number of destinations but also receives inbound flows over a Load Balancer frontend. この場合、シナリオ 1 と 2 を組み合わせて軽減を行えます。In this case, you can combine scenarios 1 and 2 for relief. その他のパターンについては、SNAT 不足の管理に関するセクションを確認してください。For additional patterns, review Managing SNAT exhaustion.

送信フローの複数のフロントエンドMultiple frontends for outbound flows

Standard Load BalancerStandard Load Balancer

複数の (パブリック) IP フロントエンドが存在する場合、Standard Load Balancer では、発信フローのすべての候補が同時に使用されます。Standard Load Balancer uses all candidates for outbound flows at the same time when multiple (public) IP frontends is present. 発信接続に対して負荷分散ルールが有効になっている場合、各フロントエンドは使用できる事前割当 SNAT ポートの数を増やします。Each frontend multiplies the number of available preallocated SNAT ports if a load balancing rule is enabled for outbound connections.

新しい負荷分散ルール オプションを使用して、発信接続にフロントエンド IP アドレスが使用されないようにすることができます。You can choose to suppress a frontend IP address from being used for outbound connections with a new load balancing rule option:

      "loadBalancingRules": [
        {
          "disableOutboundSnat": false
        }
      ]

通常、disableOutboundSnat オプションは既定で false になり、このルールによって負荷分散ルールのバックエンド プール内の関連付けられた VM の送信 SNAT がプログラムされることを示します。Normally, the disableOutboundSnat option defaults to false and signifies that this rule programs outbound SNAT for the associated VMs in the backend pool of the load balancing rule. disableOutboundSnattrue に変更すると、Load Balancer がこの負荷分散ルールのバックエンド プール内の VM の送信接続に、関連付けられたフロントエンド IP アドレスを使用しないようにすることができます。The disableOutboundSnat can be changed to true to prevent Load Balancer from using the associated frontend IP address for outbound connections for the VMs in the backend pool of this load balancing rule. また、「組み合わされた複数のシナリオ」で説明されているとおり、送信フローに特定の IP アドレスを指定することもできます。And you can also still designate a specific IP address for outbound flows as described in Multiple, combined scenarios as well.

Load Balancer BasicLoad Balancer Basic

複数の (パブリック) IP フロントエンドが送信フローの候補である場合、送信フローに使用される 1 つのフロントエンドが Load Balancer Basic によって選択されます。Load Balancer Basic chooses a single frontend to be used for outbound flows when multiple (public) IP frontends are candidates for outbound flows. この選択は構成することができません。選択アルゴリズムはランダムであると考える必要があります。This selection is not configurable, and you should consider the selection algorithm to be random. 組み合わされた複数のシナリオ」で説明されているとおり、送信フローに特定の IP アドレスを指定できます。You can designate a specific IP address for outbound flows as described in Multiple, combined scenarios.

可用性ゾーンAvailability Zones

可用性ゾーンありの Standard Load Balancer を使用する場合、ゾーン冗長フロントエンドでゾーン冗長発信 SNAT 接続を提供できます。また、ゾーン エラーが発生しても SNAT プログラミングは継続されます。When using Standard Load Balancer with Availability Zones, zone-redundant frontends can provide zone-redundant outbound SNAT connections and SNAT programming survives zone failure. ゾーンのフロントエンドを使用する場合、発信 SNAT 接続の有効期間は属するゾーンと同じです。When zonal frontends are used, outbound SNAT connections share fate with the zone they belong to.

SNAT と PAT の理解Understanding SNAT and PAT

ポート マスカレード SNAT (PAT)Port masquerading SNAT (PAT)

パブリック ロード バランサー リソースが VM インスタンスに関連付けられている場合、各送信接続のソースは書き換えられます。When a public Load Balancer resource is associated with VM instances, each outbound connection source is rewritten. ソースは、仮想ネットワークのプライベート IP アドレス空間からロード バランサー フロントエンドのパブリック IP アドレスに書き換えられます。The source is rewritten from the virtual network private IP address space to the frontend Public IP address of the load balancer. パブリック IP アドレス空間では、フローの 5 タプル (ソース IP アドレス、ソース ポート、IP 転送プロトコル、宛先 IP アドレス、宛先ポート) は一意である必要があります。In the public IP address space, the 5-tuple of the flow (source IP address, source port, IP transport protocol, destination IP address, destination port) must be unique. ポート マスカレード SNAT は、TCP または UDP IP プロトコルで使用できます。Port masquerading SNAT can be used with either TCP or UDP IP protocols.

これを実現するために、プライベート ソース IP アドレスの書き換え後にエフェメラル ポート (SNAT ポート) が使用されます。これは複数のフローが単一のパブリック IP アドレスから送信されるためです。Ephemeral ports (SNAT ports) are used to achieve this after rewriting the private source IP address, because multiple flows originate from a single public IP address. SNAT アルゴリズムをマスカレードしているポートは、UDP 対 TCP とは異なる方法で SNAT ポートを割り当てます。The port masquerading SNAT algorithm allocates SNAT ports differently for UDP versus TCP.

TCP SNAT ポートTCP SNAT Ports

1 つの SNAT ポートは、単一の宛先 IP アドレス、ポートへのフローごとに使用されます。One SNAT port is consumed per flow to a single destination IP address, port. 同じ宛先 IP アドレス、ポート、およびプロトコルへの複数の TCP フローでは、各 TCP フローが単一の SNAT ポートを使用します。For multiple TCP flows to the same destination IP address, port, and protocol, each TCP flow consumes a single SNAT port. これにより、同じパブリック IP アドレスから送信されて同じ宛先 IP アドレス、ポート、プロトコルに移動する複数のフローが、一意であることが保証されます。This ensures that the flows are unique when they originate from the same public IP address and go to the same destination IP address, port, and protocol.

別の宛先 IP アドレス、ポート、プロトコルへの複数のフローは、宛先ごとに 1 つの SNAT ポートを共有します。Multiple flows, each to a different destination IP address, port, and protocol, share a single SNAT port. 宛先 IP アドレス、ポート、プロトコルによってフローは一意になります。パブリック IP アドレス空間でフローを区別するための追加のソース ポートは必要ありません。The destination IP address, port, and protocol make flows unique without the need for additional source ports to distinguish flows in the public IP address space.

UDP SNAT ポートUDP SNAT Ports

UDP SNAT ポートは、TCP SNAT ポートではなく、別のアルゴリズムによって管理されます。UDP SNAT ports are managed by a different algorithm than TCP SNAT ports. ロード バランサーは、UDP の "ポート制限された Cone NAT" と呼ばれるアルゴリズムを使用します。Load Balancer uses an algorithm known as "port-restricted cone NAT" for UDP. 1 つの SNAT ポートは、宛先 IP アドレス、ポートに関係なく、各フローに対して使用されます。One SNAT port is consumed for each flow, irrespective of destination IP address, port.

ポート不足Exhaustion

SNAT ポート リソースがなくなると、既存のフローによって SNAT ポートが解放されない限り、送信フローは失敗します。When SNAT port resources are exhausted, outbound flows fail until existing flows release SNAT ports. Load Balancer はフローが終了すると SNAT ポートを回収します。また、4 分間のアイドル タイムアウトを使用して、アイドル フローからの SNAT ポートを回収します。Load Balancer reclaims SNAT ports when the flow closes and uses a 4-minute idle timeout for reclaiming SNAT ports from idle flows.

一般的に UDP SNAT ポートは、使用されるアルゴリズムの違いが原因で、TCP SNAT ポートと比べてかなり迅速に使い果たされてしまいます。UDP SNAT ports generally exhaust much faster than TCP SNAT ports due to the difference in algorithm used. この違いを念頭に置いて、テストの設計とスケーリングを行う必要があります。You must design and scale test with this difference in mind.

SNAT ポート不足を引き起こしやすい状態を軽減するパターンについては、SNAT の管理に関するセクションを確認してください。For patterns to mitigate conditions that commonly lead to SNAT port exhaustion, review the Managing SNAT section.

ポート マスカレード SNAT (PAT) 用のエフェメラル ポートの事前割り当てEphemeral port preallocation for port masquerading SNAT (PAT)

Azure では、アルゴリズムを使用して、割り当てられる利用可能な SNAT ポートの数が決定されます。これは、ポート マスカレード SNAT (PAT) を使用する際のバックエンド プールのサイズに基づきます。Azure uses an algorithm to determine the number of preallocated SNAT ports available based on the size of the backend pool when using port masquerading SNAT (PAT). SNAT ポートは、特定のパブリック IP ソース アドレスについて使用可能なエフェメラル ポートです。SNAT ports are ephemeral ports available for a particular public IP source address.

同じ数の SNAT ポートが UDP と TCP にそれぞれ事前に割り当てられ、IP トランスポート プロトコルに従って個別に使用されます。The same number of SNAT ports are preallocated for UDP and TCP respectively and consumed independently per IP transport protocol. ただし、SNAT ポートの使用方法は、フローが UDP または TCP のどちらかに応じて異なります。However, the SNAT port usage is different depending on whether the flow is UDP or TCP.

重要

Standard SKU の SNAT プログラミングは、IP トランスポート プロトコルに従い、負荷分散規則から派生します。Standard SKU SNAT programming is per IP transport protocol and derived from the load balancing rule. TCP 負荷分散規則だけが存在する場合、SNAT は TCP でのみ使用できます。If only a TCP load balancing rule exists, SNAT is only available for TCP. TCP 負荷分散規則しかないときに、UDP の送信 SNAT が必要な場合は、同じフロントエンドから同じバックエンド プールへの UDP 負荷分散規則を作成します。If you have only a TCP load balancing rule and need outbound SNAT for UDP, create a UDP load balancing rule from the same frontend to the same backend pool. これにより、UDP の SNAT プログラミングがトリガーされます。This will trigger SNAT programming for UDP. 動作規則や正常性プローブは不要です。A working rule or health probe is not required. Basic SKU の SNAT では、負荷分散規則で指定されたトランスポート プロトコルに関係なく、常に両方の IP トランスポート プロトコルに対して SNAT がプログラムされます。Basic SKU SNAT always programs SNAT for both IP transport protocol, irrespective of the transport protocol specified in the load balancing rule.

SNAT ポートは Azure によって各 VM の NIC の IP 構成に事前に割り当てられます。Azure preallocates SNAT ports to the IP configuration of the NIC of each VM. IP 構成がプールに追加されると、バックエンド プール サイズに基づいて SNAT ポートがこの IP 構成に事前割り当てされます。When an IP configuration is added to the pool, the SNAT ports are preallocated for this IP configuration based on the backend pool size. 送信フローが作成されると、これらのポートは (事前に割り当てられた上限に達するまで) PAT によって動的に消費されます。そして、フローが終了するかアイドル タイムアウトが発生すると解放されます。When outbound flows are created, PAT dynamically consumes (up to the preallocated limit) and releases these ports when the flow closes or idle timeouts happen.

次の表は、バックエンド プール サイズのレベルに対する SNAT ポートの事前割り当てを示しています。The following table shows the SNAT port preallocations for tiers of backend pool sizes:

プール サイズ (VM インスタンス)Pool size (VM instances) IP 構成あたりの事前に割り当てられる SNAT ポートPreallocated SNAT ports per IP configuration
1-501-50 1,0241,024
51-10051-100 512512
101-200101-200 256256
201-400201-400 128128
401-800401-800 6464
801-1,000801-1,000 3232

注意

複数フロントエンドで Standard Load Balancer を使用する場合、フロントエンド IP アドレスごとに、前の表に記載されている使用可能な SNAT ポート数を増やします。When using Standard Load Balancer with multiple frontends, each frontend IP address multiplies the number of available SNAT ports in the previous table. たとえば、それぞれ個別のフロントエンド IP アドレスを使用する 2 つの負荷分散規則を持つ、50 個の VM のバックエンド プールでは、IP 構成ごとに 2048 (2x 1024) 個の SNAT ポートが使用されます。For example, a backend pool of 50 VM's with 2 load balancing rules, each with a separate frontend IP address, will use 2048 (2x 1024) SNAT ports per IP configuration. 詳細については、複数のフロントエンドに関するセクションを参照してください。See details for multiple frontends.

利用できる SNAT ポートの数が、そのままフローの数に変換されるわけではないことに注意してください。Remember that the number of SNAT ports available does not translate directly to number of flows. 複数の一意の送信先に単一の SNAT ポートを再利用できます。A single SNAT port can be reused for multiple unique destinations. ポートは、フローを一意にするために必要な場合にのみ消費されます。Ports are consumed only if it's necessary to make flows unique. 設計と軽減策のガイダンスについて、この有限のリソースを管理する方法に関するセクション、および PAT について説明しているセクションを参照してください。For design and mitigation guidance, refer to the section about how to manage this exhaustible resource and the section that describes PAT.

パックエンド プールのサイズを変更すると、確立されたフローの一部に影響が及ぶ可能性があります。Changing the size of your backend pool might affect some of your established flows. バックエンド プール サイズが増加し、次のレベルに移行すると、1 つ大きいバックエンド プール レベルに移行する間に、事前に割り当てられた SNAT ポートの半分が回収されます。If the backend pool size increases and transitions into the next tier, half of your preallocated SNAT ports are reclaimed during the transition to the next larger backend pool tier. 回収された SNAT ポートに関連付けられているフローはタイムアウトになるので、再確立する必要があります。Flows that are associated with a reclaimed SNAT port will time out and must be reestablished. 新しいフローを試みると、事前に割り当てられたポートが使用可能な限り、フローはすぐに成功します。If a new flow is attempted, the flow will succeed immediately as long as preallocated ports are available.

バックエンド プールのサイズが減少し、1 つ小さいレベルに移行すると、使用できる SNAT ポートが増えます。If the backend pool size decreases and transitions into a lower tier, the number of available SNAT ports increases. この場合、割り当てられている既存の SNAT ポートと各フローに影響はありません。In this case, existing allocated SNAT ports and their respective flows are not affected.

SNAT ポートの割り当ては、IP トランスポート プロトコル固有であり (TCP と UDP は別々に管理されます)、次の条件下で解放されます。SNAT ports allocations are IP transport protocol specific (TCP and UDP are maintained separately) and are released under the following conditions:

TCP SNAT ポートの解放TCP SNAT port release

  • サーバー/クライアントのどちらかが FINACK を送信すると、SNAT ポートは 240 秒後に解放されます。If either server/client sends FINACK, SNAT port will be released after 240 seconds.
  • RST が送信されると、SNAT ポートは 15 秒後に解放されます。If a RST is seen, SNAT port will be released after 15 seconds.
  • アイドル タイムアウトに達すると、ポートは解放されます。If idle timeout has been reached, port is released.

UDP SNAT ポートの解放UDP SNAT port release

  • アイドル タイムアウトに達すると、ポートは解放されます。If idle timeout has been reached, port is released.

問題の解決Problem solving

このセクションは、Azure での送信接続で発生する可能性のある SNAT の枯渇の緩和に役立つことを目的にしています。This section is intended to help mitigate SNAT exhaustion and that can occur with outbound connections in Azure.

SNAT (PAT) ポート不足の管理Managing SNAT (PAT) port exhaustion

PAT に使用されるエフェメラル ポートは、「インスタンス レベルのパブリック IP アドレスがないスタンドアロン VM」および「インスタンス レベルのパブリック IP アドレスがない負荷分散 VM」で説明されているように有限のリソースです。Ephemeral ports used for PAT are an exhaustible resource, as described in Standalone VM without an Instance Level Public IP address and Load-balanced VM without an Instance Level Public IP address.

同じ宛先 IP アドレスとポートに対して多数の TCP 送信接続または UDP 送信接続が開始されることがわかっている場合、送信接続エラーが出る場合、または SNAT ポート (PAT によって使用される事前割り当て済みのエフェメラル ポート) が不足しているとサポートから指摘された場合、いくつかの一般的な軽減策の選択肢があります。If you know that you're initiating many outbound TCP or UDP connections to the same destination IP address and port, and you observe failing outbound connections or are advised by support that you're exhausting SNAT ports (preallocated ephemeral ports used by PAT), you have several general mitigation options. これらのオプションを確認し、使用可能であり、実際のシナリオに最適な選択肢を判断してください。Review these options and decide what is available and best for your scenario. それらを 1 つまたは複数組み合わせることが状況改善に役立つ場合もあります。It's possible that one or more can help manage this scenario.

送信接続の動作の理解が難しい場合は、IP スタック統計 (netstat) を使用できます。If you are having trouble understanding the outbound connection behavior, you can use IP stack statistics (netstat). また、パケット キャプチャを使用した接続動作を観察することも効果的です。Or it can be helpful to observe connection behaviors by using packet captures. これらのパケット キャプチャはインスタンスのゲスト OS で実行できます。また、パケット キャプチャには Network Watcher も使用できます。You can perform these packet captures in the guest OS of your instance or use Network Watcher for packet capture.

接続を再利用するようにアプリケーションを変更するModify the application to reuse connections

SNAT に使用される一時ポートの需要は、アプリケーションで接続を再利用することで減らすことができます。You can reduce demand for ephemeral ports that are used for SNAT by reusing connections in your application. これには、既定で接続が再利用される HTTP/1.1 などのプロトコルが特に有効です。This is especially true for protocols like HTTP/1.1, where connection reuse is the default. また、HTTP が転送に使用されるその他のプロトコル (REST など) も活用できます。And other protocols that use HTTP as their transport (for example, REST) can benefit in turn.

要求ごとに個別にアトミック TCP 接続するよりも、再利用するほうが常に効果的です。Reuse is always better than individual, atomic TCP connections for each request. 再利用は、TCP トランザクションのパフォーマンス向上と大幅な効率化につながります。Reuse results in more performant, very efficient TCP transactions.

接続プーリングを使用するようにアプリケーションを変更するModify the application to use connection pooling

アプリケーションでは接続プーリング スキームを利用できます。この場合、接続の固定セットに対して要求が内部的に分散されます (各要求で利用可能な接続が再利用されます)。You can employ a connection pooling scheme in your application, where requests are internally distributed across a fixed set of connections (each reusing where possible). このスキームにより、使用される一時ポートの数が制限され、環境の予測可能性が高まります。This scheme constrains the number of ephemeral ports in use and creates a more predictable environment. さらに、このスキームを使用すると、ある操作の応答で 1 つの接続がブロックされている際に同時に複数の操作を行えるようにして、要求のスループットを向上させることもできます。This scheme can also increase the throughput of requests by allowing multiple simultaneous operations when a single connection is blocking on the reply of an operation.

接続プーリングは既に、アプリケーションの開発に使用しているフレームワーク、またはアプリケーションの構成設定の中に存在している可能性があります。Connection pooling might already exist within the framework that you're using to develop your application or the configuration settings for your application. 接続プーリングは接続の再利用と組み合わせることができます。You can combine connection pooling with connection reuse. 同じ宛先 IP アドレスとポートに対する複数の要求で、固定された予測可能な数のポートを消費します。Your multiple requests then consume a fixed, predictable number of ports to the same destination IP address and port. これらの要求で、TCP トランザクションを非常に効率的に使用して、待ち時間とリソース使用率を減らすこともできます。The requests also benefit from efficient use of TCP transactions reducing latency and resource utilization. また、UDP フローの数を管理すると不足状態を回避して SNAT ポートの使用率を管理できるので、UDP トランザクションにもメリットがあります。UDP transactions can also benefit, because managing the number of UDP flows can in turn avoid exhaust conditions and manage the SNAT port utilization.

再試行の頻度を抑えるようにアプリケーションのロジックを変更するModify the application to use less aggressive retry logic

PAT に使用される事前割り当て済みのエフェメラル ポートが不足している場合、またはアプリケーションのエラーが発生している場合、減退やバックオフ ロジックを使わず単純に再試行を繰り返すと、ポート不足が発生したり持続したりします。When preallocated ephemeral ports used for PAT are exhausted or application failures occur, aggressive or brute force retries without decay and backoff logic cause exhaustion to occur or persist. エフェメラル ポートの需要は、再試行の頻度を抑えたロジックを使用することで減らすことができます。You can reduce demand for ephemeral ports by using a less aggressive retry logic.

エフェメラル ポートには 4 分間のアイドル タイムアウトが設定されています (調整不可)。Ephemeral ports have a 4-minute idle timeout (not adjustable). 再試行の頻度が高すぎた場合、不足が自動的に解消されることはありません。If the retries are too aggressive, the exhaustion has no opportunity to clear up on its own. そのため、アプリケーションがトランザクションを再試行する方法と頻度を考慮することは、設計において非常に重要です。Therefore, considering how--and how often--your application retries transactions is a critical part of the design.

インスタンスレベル パブリック IP を個々の VM に割り当てるAssign an Instance Level Public IP to each VM

ILPIP を割り当てることで、インスタンスレベル パブリック IP を VM に割り当てるシナリオに移行します。Assigning an ILPIP changes your scenario to Instance Level Public IP to a VM. この VM で、VM ごとに使用されるパブリック IP のすべてのエフェメラル ポートを使用できます。All ephemeral ports of the public IP that are used for each VM are available to the VM. (パブリック IP のエフェメラル ポートが、それぞれのバックエンド プールに関連付けられているすべての VM で共有されるシナリオとは対照的です。)パブリック IP アドレスの追加コストや、大量の IP アドレスを個別にホワイトリスト登録することの潜在的な影響など、考慮すべきトレードオフがあります。(As opposed to scenarios where ephemeral ports of a public IP are shared with all the VMs associated with the respective backend pool.) There are trade-offs to consider, such as the additional cost of public IP addresses and the potential impact of whitelisting a large number of individual IP addresses.

注意

このオプションは、worker ロールでは使用できません。This option is not available for web worker roles.

複数のフロントエンドを使用するUse multiple frontends

パブリック Standard Load Balancer を使用する場合は、発信接続用に複数のフロントエンド IP アドレスを割り当て、使用可能な SNAT ポートの数を増やしますWhen using public Standard Load Balancer, you assign multiple frontend IP addresses for outbound connections and multiply the number of SNAT ports available. フロントエンドのパブリック IP への SNAT のプログラミングをトリガーするには、フロントエンド IP の構成、ルール、およびバックエンド プールを作成します。Create a frontend IP configuration, rule, and backend pool to trigger the programming of SNAT to the public IP of the frontend. このルールが機能する必要はなく、正常性プローブが成功する必要はありません。The rule does not need to function and a health probe does not need to succeed. (送信だけでなく) 受信にも複数のフロントエンドを使用する場合は、カスタム正常性プローブを適切に使用して信頼性を確保する必要があります。If you do use multiple frontends for inbound as well (rather than just for outbound), you should use custom health probes well to ensure reliability.

注意

ほとんどの場合、SNAT ポートの枯渇は設計に問題があることを示します。In most cases, exhaustion of SNAT ports is a sign of bad design. より多くのフロントエンドを使用して SNAT ポートを追加する前に、ポートが枯渇している理由を把握してください。Make sure you understand why you are exhausting ports before using more frontends to add SNAT ports. 後で障害につながる可能性のある問題が隠れている可能性があります。You may be masking a problem which can lead to failure later.

スケールアウトScale out

事前割り当てポートは、バックエンド プール サイズに基づいて割り当てられ、ポートの一部を再割り当てして 1 つ大きいバックエンド プール サイズ レベルに対応する必要があるときに中断を最小限に抑えるために、複数のレベルにグループ化されます。Preallocated ports are assigned based on the backend pool size and grouped into tiers to minimize disruption when some of the ports have to be reallocated to accommodate the next larger backend pool size tier. バックエンド プールを特定のレベルの最大サイズにスケーリングすることで、特定のフロントエンドの SNAT ポート使用率を向上させることもできます。You may have an option to increase the intensity of SNAT port utilization for a given frontend by scaling your backend pool to the maximum size for a given tier. この場合、アプリケーションが効率的にスケール アウトする必要があります。This requires for the application to scale out efficiently.

たとえば、バックエンド プール内の 2 つの仮想マシンでは IP 構成あたり 1024 個の SNAT ポートを使用できるため、デプロイには合計 2048 個の SNAT ポートを使用できます。For example, two virtual machines in the backend pool would have 1024 SNAT ports available per IP configuration, allowing a total of 2048 SNAT ports for the deployment. デプロイを 50 個の仮想マシンに増やした場合、事前割り当てポートの数が仮想マシンごとに一定のままであっても、合計 51,200 (50 × 1024) 個の SNAT ポートをデプロイで使用できます。If the deployment were to be increased to 50 virtual machines, even though the number of preallocated ports remains constant per virtual machine, a total of 51,200 (50 x 1024) SNAT ports can be used by the deployment. デプロイをスケールアウトする場合は、レベルごとの事前割り当てポートの数を確認して、スケールアウトをそれぞれのレベルの最大数に必ず合わせます。If you wish to scale out your deployment, check the number of preallocated ports per tier to make sure you shape your scale out to the maximum for the respective tier. 前の例で、50 個のインスタンスではなく、51 個にスケールアウトすることにした場合、次のレベルに進むと、VM ごとの SNAT ポート数と合計が減ることになります。In the preceding example, if you had chosen to scale out to 51 instead of 50 instances, you would progress to the next tier and end up with fewer SNAT ports per VM as well as in total.

割り当てられたポートを再割り当てする必要がある場合に、次に大きなバックエンド プール サイズ レベルにスケールアウトすると、送信接続の一部がタイムアウトする可能性があります。If you scale out to the next larger backend pool size tier, there is potential for some of your outbound connections to time out if allocated ports have to be reallocated. SNAT ポートの一部しか使用していない場合は、次に大きなバックエンド プール サイズにスケールアウトすることは重要ではありません。If you are only using some of your SNAT ports, scaling out across the next larger backend pool size is inconsequential. 既存のポートの半分は、次のバックエンド プール レベルに移行するたびに再割り当てされます。Half the existing ports will be reallocated each time you move to the next backend pool tier. これを行わない場合は、デプロイをそのレベルのサイズに合わせる必要があります。If you don't want this to take place, you need to shape your deployment to the tier size. または、必要に応じてアプリケーションが検出し、再試行できる必要があります。Or make sure your application can detect and retry as necessary. TCP キープアライブは、再割り当てによって SNAT ポートが機能しなくなったときの検出に役立ちます。TCP keepalives can assist in detect when SNAT ports no longer function due to being reallocated.

キープアライブを使用して送信アイドル タイムアウトをリセットするUse keepalives to reset the outbound idle timeout

送信接続には、4 分間のアイドル タイムアウトが設けられています。Outbound connections have a 4-minute idle timeout. このタイムアウトは調整できません。This timeout is not adjustable. ただし、必要に応じて、転送 (TCP キープアライブなど) またはアプリケーション レイヤー キープアライブを使用して、アイドル フローを更新したりこのアイドル タイムアウトをリセットしたりできます。However, you can use transport (for example, TCP keepalives) or application-layer keepalives to refresh an idle flow and reset this idle timeout if necessary.

TCP キープアライブを使用するときは、接続の一方で有効にすれば十分です。When using TCP keepalives, it is sufficient to enable them on one side of the connection. たとえば、フローのアイドル タイマーをリセットするときは、サーバー側でのみ有効にすれば十分であり、両側が TCP キープアライブを開始する必要はありません。For example, it is sufficient to enable them on the server side only to reset the idle timer of the flow and it is not necessary for both sides to initiated TCP keepalives. データベースのクライアント/サーバー構成など、アプリケーション レイヤーにも同様の概念があります。Similar concepts exist for application layer, including database client-server configurations. サーバー側で、アプリケーション固有のキープアライブのどのようなオプションが存在するかを確認します。Check the server side for what options exist for application specific keepalives.

VM で使用されるパブリック IP の検出Discovering the public IP that a VM uses

送信接続のパブリック ソース IP アドレスを判別する方法は多数あります。There are many ways to determine the public source IP address of an outbound connection. OpenDNS によって提供されるサービスで、VM のパブリック IP アドレスを表示できます。OpenDNS provides a service that can show you the public IP address of your VM.

nslookup コマンドを使用することで、名前 myip.opendns.com に関する DNS クエリを OpenDNS Resolver に送信できます。By using the nslookup command, you can send a DNS query for the name myip.opendns.com to the OpenDNS resolver. このサービスは、クエリの送信に使用されたソース IP アドレスを返します。The service returns the source IP address that was used to send the query. VM から次のクエリを実行すると、その VM で使用されるパブリック IP が応答として返されます。When you run the following query from your VM, the response is the public IP used for that VM:

nslookup myip.opendns.com resolver1.opendns.com

送信接続の防止Preventing outbound connectivity

場合によっては、VM で送信フローを作成できるのは望ましくない場合があります。Sometimes it's undesirable for a VM to be allowed to create an outbound flow. また、送信フローで接続できる宛先や受信フローを開始できる宛先を管理するための要件がある場合もあります。Or there might be a requirement to manage which destinations can be reached with outbound flows, or which destinations can begin inbound flows. このような場合は、ネットワーク セキュリティ グループ を使用すると、VM が接続できる宛先を管理できます。In this case, you can use network security groups to manage the destinations that the VM can reach. また、NSG を使用して、受信フローを開始できるパブリックの宛先を管理することもできます。You can also use NSGs to manage which public destination can initiate inbound flows.

負荷分散された VM に NSG を適用するときは、サービス タグ既定のセキュリティ規則に注意してください。When you apply an NSG to a load-balanced VM, pay attention to the service tags and default security rules. VM が Azure Load Balancer からのヘルス プローブ要求を受け取ることができるようにしておいてください。You must ensure that the VM can receive health probe requests from Azure Load Balancer.

NSG が AZURE_LOADBALANCER 既定タグからのヘルス プローブ要求をブロックすると、VM のヘルス プローブが失敗して VM が停止しているとマークされます。If an NSG blocks health probe requests from the AZURE_LOADBALANCER default tag, your VM health probe fails and the VM is marked down. ロード バランサーはその VM への新しいフローの送信を停止します。Load Balancer stops sending new flows to that VM.

制限事項Limitations

  • DisableOutboundSnat は、ポータルで負荷分散規則を構成するときにはオプションとして使用できません。DisableOutboundSnat is not available as an option when configuring a load balancing rule in the portal. 代わりに、REST、テンプレート、またはクライアント ツールを使用してください。Use REST, template, or client tools instead.
  • VNet およびその他の Microsoft プラットフォーム サービスなしの Web Worker ロールにアクセスできるのは、事前 VNet サービスおよびその他のプラットフォーム サービスの動作の副作用により、内部の Standard Load Balancer が使用される場合のみです。Web Worker Roles without a VNet and other Microsoft platform services can be accessible when only an internal Standard Load Balancer is used due to a side effect from how pre-VNet services and other platform services function. それぞれのサービス自体、または基になるプラットフォームは予告なく変更されることがあるため、この副作用に依存しないでください。Do not rely on this side effect as the respective service itself or the underlying platform may change without notice. 内部の Standard Load Balancer のみを使用する場合は、必要に応じて、明示的に送信接続を作成する必要があることを常に想定する必要があります。You must always assume you need to create outbound connectivity explicitly if desired when using an internal Standard Load Balancer only. この記事で説明されている既定の SNAT のシナリオ 3 を使用することはできません。The default SNAT scenario 3 described in this article is not available.

次の手順Next steps