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 和標準公用 IP 引進新功能以及不同的輸出連線行為。Standard Load Balancer and Standard Public IP introduce new abilities and different behaviors to outbound connectivity. 這些與基本 SKU 不同。They are not the same as Basic SKUs. 如果您想要在使用標準 SKU 時輸出連線,您必須使用標準公用 IP 位址或標準公用 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. 建議您一律使用標準公用 Load Balancer 的輸出規則。We recommend you always use outbound rules on a Standard public Load Balancer. 案例 3 不適用於標準 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 與標準 SKU 相關聯,則此時可用性設定組內的所有 VM 執行個體行為會遵循相同的規則,就如同與標準 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. 請仔細檢閱這整份文件了解整體概念,檢閱 Standard Load Balancer 了解 SKU 之間的差異,並檢閱輸出規則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 資源的輸出連線。Azure currently provides three different methods to achieve outbound connectivity for Azure Resource Manager resources.

SKUSKUs 狀況Scenario 方法Method IP 通訊協定IP protocols 描述Description
標準、基本Standard, Basic 1.具有執行個體層級公用 IP 位址的 VM (無論是否有 Load Balancer)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 Azure 會使用指派給執行個體 NIC 之 IP 設定的公用 IP。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, Basic 2.與 VM 關聯的公用 Load Balancer (執行個體上沒有執行個體層級公用 IP 位址)2. Public Load Balancer associated with a VM (no Instance Level Public IP address on the instance) SNAT 搭配使用 Load Balancer 前端的連接埠偽裝 (PAT)SNAT with port masquerading (PAT) using the Load Balancer frontends TCP、UDPTCP, UDP Azure 會與多個私人 IP 位址共用公用 Load Balancer 前端的公用 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.
無或基本none or Basic 3.獨立 VM (無 Load Balancer、無執行個體層級公用 IP 位址)3. Standalone VM (no Load Balancer, no Instance Level Public IP address) SNAT 與連接埠偽裝 (PAT)SNAT 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.

指派給虛擬機器的公用 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 連接埠耗盡的情況,請考慮指派 ILPIP 來緩和 SNAT 限制的問題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 前端與後端集區之間的連結,從而設定 Load Balancer 資源。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 位址中的任一位址都是輸出流程的候選項目,且會隨機選取其中一個位址。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 監視輸出連線的健全狀況, 您可以使用Azure 監視器記錄檔進行 Load Balancer , 並警示事件記錄檔來監視 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 位址。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案例 2You 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. 這個案例類似於案例 2,差別在於沒有所使用 IP 位址的控制權。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. 在為沒有可用性設定組的獨立 VM 決定預先配置時,其實際上會屬於大小為 1 的集區 (1024 SNAT 連接埠)。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 優先順序高於案例 23When multiple scenarios are present, an order of precedence applies: scenario 1 takes precedence over scenario 2 and 3. 案例 2 會覆寫案例 3Scenario 2 overrides scenario 3.

範例是 Azure Resource Manager 部署,其中應用程式高度依賴與有限數目目的地的輸出連線,也會透過 Load Balancer 前端接收輸入流程。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. disableOutboundSnat 可以變更為 true,防止 Load Balancer 將相關聯前端 IP 位址用於此負載平衡規則之後端集區中 VM 的輸出連線。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 前端是輸出流程的候選項目時,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 和 PATUnderstanding SNAT and PAT

連接埠偽裝 SNAT (PAT)Port masquerading SNAT (PAT)

當公用 Load Balancer 資源與 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 tuple 流程 (來源 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

每個流程會取用一個 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 位址、連接埠及通訊協定的流程會共用單一 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. Load Balancer 會對 UDP 使用稱為 "Port-Restricted cone NAT" 的演算法。Load Balancer uses an algorithm known as "port-restricted cone NAT" for UDP. 每個流程都會取用一個 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. 當流程關閉並使用 4 分鐘閒置逾時來從閒置流程回收 SNAT 連接埠時,Load Balancer 會回收 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 (PAT) 時,根據後端集區的大小決定可用的預先配置 SNAT 連接埠數目。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.

分別針對 UDP 和 TCP 預先配置相同數目的 SNAT 連接埠,並且對每個 IP 傳輸通訊協定個別使用。The same number of SNAT ports are preallocated for UDP and TCP respectively and consumed independently per IP transport protocol. 不過,視流程為 UDP 或 TCP 而定,SNAT 連接埠的使用方式會有所不同。However, the SNAT port usage is different depending on whether the flow is UDP or TCP.

重要

標準 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. 不論是否已在負載平衡規則中指定傳輸通訊協定,基本 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.

Azure 會將 SNAT 連接埠預先配置到每個 VM 之 NIC 的 IP 設定。Azure preallocates SNAT ports to the IP configuration of the NIC of each VM. 當 IP 設定新增至集區時,會根據後端集區大小針對此 IP 設定預先配置 SNAT 連接埠。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. 例如,50 個 VM 的後端集區具有 2 個負載平衡規則 (分別具有個別前端 IP 位址),則在每個 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. 如果後端集區大小增加並轉換到下一層,在轉換至下一個較大後端集區層的期間,會回收您預先配置的一半 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.

如果後端集區大小縮減而轉換成較低的層級,可用的 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, 則會在240秒後釋放 SNAT 埠。If either server/client sends FINACK, SNAT port will be released after 240 seconds.
  • 如果看到 RST,則會在 15 秒之後釋出 SNAT 連接埠。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

無執行個體層級公用 IP 位址的獨立 VM無執行個體層級公用 IP 位址的負載平衡 VM 中所述,用於 PAT暫時連接埠是可耗盡的資源。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. 可能會有一或多個選項有助於管理此案例。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 中執行這些封包擷取,或使用網路監看員來進行封包擷取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. 這個配置也可在單一連線阻斷某個作業的回應時,藉由允許多個作業同時進行,來增加要求輸送量。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 交易也有幫助,因為管理 UDP 流程數目可接著避免發生耗盡狀況,並管理 SNAT 連接埠使用量。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 給每個 VMAssign an Instance Level Public IP to each VM

指派 ILPIP 會將您的案例變更為 VM 的執行個體層級公用 IPAssigning an ILPIP changes your scenario to Instance Level Public IP to a VM. 用於每個 VM 的所有公用 IP 暫時連接埠都可供 VM 使用。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.

注意

此選項不適用於 Web 背景工作角色。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

預先配置的連接埠會根據後端集區大小進行指派並分組到各層中,以在某些連接埠必須重新配置以便容納下一個較大後端集區大小層時,將中斷時間降至最低。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.

例如,後端集區中的兩部虛擬機器有 1024 個 SNAT 連接埠可供每個 IP 組態使用,總計允許 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 x 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. 在先前範例中,如果您已選擇相應放大到 51 個而不是 50 個執行個體,您會進到下一層且最終在每部虛擬機器及總計上具有較少的 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.

使用 Keepalive 來重設輸出閒置逾時Use keepalives to reset the outbound idle timeout

連出連線有 4 分鐘的閒置逾時。Outbound connections have a 4-minute idle timeout. 此逾時無法調整。This timeout is not adjustable. 不過,您可以使用傳輸 (例如 TCP Keepalive) 或應用程式層 Keepalive 來重新整理閒置流程,然後視需要重設此閒置逾時。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 使用的公用 IPDiscovering 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 解析程式。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.

當您將 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 服務和其他平台服務的運作方式產生副作用,而只使用內部標準 Load Balancer 時,才可存取沒有 VNet 和其他 Microsoft 平台服務的 Web 背景工作角色。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. 如果在只使用內部標準 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